Hi to the OPNsense community,
I am using OPNsense as a home lab, in the following basic setting :
Internet access ===> OPNsense 25.1 ==> LAN
After upgrading to OPNsense 25.1, there were some connectivity issues on the LAN interface (instability), which some other users experienced and this made me have a closer look at the LAN interface.
This is how I noticed connections going from the firewall to port 22 on the LAN. Theses connections - or rather attempts,allowed by automatic rules ('let anything out from firewall host itself'), suggest use of SSH as the protocol was TCP.
Please see attached screenshot from the live view in firewall logs : the connections are leaving the LAN interface, from OPNsense to the computer on the LAN.
I tried to find out if there is any legitimate service on OPNsense 25.1 that could be make this kind of activity, could anyone share any thoughts or advice please ?
Many thanks.
Those are likely going through it not from it. See the label, it is the rule that allows traffic from the firewall to the LAN.
There should be another leg of this traffic coming into the firewall, unless of course your are ssh'ing from it (the console).
Many thanks for the swift reply.
Well, unfortunately no, I wasn't SSH'ing from the console :-/ ..so what can be done please to find that other part corresponding to this traffic?
To expand on that, if you have logging enabled on your rules as well as the default/automatic rules, you'll get a log pair like these:
JAIL <- 2025-03-11T10:00:44-05:00 10.101.11.160 192.168.99.160 icmp let out anything from firewall host itself
TRUST -> 2025-03-11T10:00:44-05:00 10.101.11.160 192.168.99.160 icmp TRUST: Pass Ping_v4 from TRUST net to Local_v4
TRUST <- 2025-03-11T10:04:41-05:00 192.168.99.160 10.101.11.160 icmp let out anything from firewall host itself
JAIL -> 2025-03-11T10:04:41-05:00 192.168.99.160 10.101.11.160 icmp JAIL: Pass Ping_v4 from JAIL net to Trusted_v4
EDGE <- 2025-03-11T10:16:01-05:00 47.190.83.202 47.190.83.197 icmp let out anything from firewall host itself
TRUST -> 2025-03-11T10:16:01-05:00 10.101.11.160 47.190.83.197 icmp TRUST: Pass Ping_v4 from TRUST net to Local_v4
...so it's a bit tough to filter them together unless you know what you're looking for. I usually don't bother; I grabbed these by expanding (to 100 lines) and stopping the (very active, on my firewall) live view.
Many thanks for your message.
Logging is indeed enabled on some of the rules, but not on the automatic ones :/... I'll implement that step, thanks again for mentioning this.
In such case, is there something else that I can dig into to learn about this event, eg in /var/log or elsewhere?
I would also like to know if there is a way to assess whether that happened through traffic only or does it imply the OPNsense system is compromised (not sure if both conditions can apply).
Do you have backup to git enabled?
Quote from: alex_62450 on March 11, 2025, 05:30:16 PM[...]
In such case, is there something else that I can dig into to learn about this event, eg in /var/log or elsewhere?
Well, there's "Firewall: Log Files: Plain View", but searching it can be a bit cumbersome. For instance, my system logs ~10-20 messages per second. And the pf logs are pretty limited (e.g. no MAC addresses). If I really want to know what's going on, I run a few (filtered) packet captures ("Interfaces: Diagnostics: Packet Capture"). I used those quite a bit early on to get a handle on some of the details of OPNsense operation.
QuoteI would also like to know if there is a way to assess whether that happened through traffic only or does it imply the OPNsense system is compromised (not sure if both conditions can apply).
Using rule logs? Hm. Singular "let out anything from firewall host itself" logs (vs. paired entries) with the source (IP) being the firewall, perhaps, but those would be tough to spot (vs. NAT, if used). A simple script could pick them out, but then there's the issue of where you'd want to implement something like that. Limitations of the FreeBSD stack and pf. Also, my configuration is a bit unusual (something that could probably be said about almost anyone's OPNsense config), so logging on my firewall may be unusual, too.
Thank you very much again for your messages.
QuoteDo you have backup to git enabled?
Well, I am not using that feature for the moment. It looks great and can be very helpful, but at the same time, it is not making your configuration public, is it? Until now, I have been doing back-ups and restores using config files, and use #diff to spot any changes. Can you share a bit about your experience with git please? I'd like to know more about it for sure.
QuoteWell, there's "Firewall: Log Files: Plain View", but searching it can be a bit cumbersome.
Indeed :-/ I have tried some basic steps, using simple #grep filters and #less but I am not sure what are the best log filters to look at to identify this kind of event in traffic - ie. the entry point on WAN - and in the system.
By the way, OPNsense was updated today to 25.1.3, which I welcomed as a chance to re-baseline the system but the same attempt was spotted again on LAN, so any thoughts and advice to track this kind of event would be please really, really welcome.
Many thanks.
Make it simple.
Firewall > Settings > Advanced > Logging: Tick to log default block, default pass and outbound NAT <=don't forget to change it all back.
Go back to Firewall > Log Files > Live View: Change the drop down for the number of entries from the default 25 to say 100.
Now stop the capture when you get the hit you're interested in but don't forget that if you still have those filters in place, you need to remove them to see the other legs of traffic.
Quote from: alex_62450 on March 12, 2025, 08:42:57 PMThank you very much again for your messages.
QuoteDo you have backup to git enabled?
Well, I am not using that feature for the moment. It looks great and can be very helpful, but at the same time, it is not making your configuration public, is it?
It can be a git server in your own network, it doesn't have to be a public one like GitHub.
But that's not the point. Git uses SSH to connect to the server which could explain the outgoing connections.
he's already said he's not using that feature ;)
Quote from: cookiemonster on March 12, 2025, 10:23:28 PMhe's already said he's not using that feature ;)
I was just explaining why I asked that question.
fair enough. I thought you had missed that message.
Back to the forum and thanks for contributions - there were some persistent stability issues on WAN today, hence a bit of delay to respond.
QuoteIt can be a git server in your own network, it doesn't have to be a public one like GitHub.
That's cool: if it's possible not to go on a public git, then I'll explore this further - thanks for bringing this forward.
QuoteFirewall > Settings > Advanced > Logging: Tick to log default block, default pass and outbound NAT <=don't forget to change it all back.
Go back to Firewall > Log Files > Live View: Change the drop down for the number of entries from the default 25 to say 100.
Done, many thanks for the hint :) And now, in practice, as this happens at unexpected moments (as always...), is there a way to automate an alert when this kind of condition is met? I had a look at the OPNsense manual and plugin list but not sure what could help.
Many thanks
automate alerting to what condition, sorry? All this so far is how to use the live view.
Well, in the present case, that automation would be trigger an alert when OPNsense probes LAN on port 22. Is there a way to do so please ?
This type of events continue to happen, and I wonder if some services on OPNsense could automatically start TCP port probes, as in addition to port 22, the OPNsense box contacts port 80.
I also noticed an enormous amount of IDS alerts on WAN, which I am going to mention in another post.
I fail to understand. OPN does not probe. It is a routing firewall when in standard setup, so it receives traffic and routes it, like a border police. Allows or rejects the passing between two networks. Only traffic initiating from itself is any specific setting or service enabled by the user.
Therefore you are probably more interested in knowing what is the traffic that is going to LAN on port 22. Where is it coming from, and is it allowed.
By default SSH traffic from WAN to LAN will be blocked. So if it is coming in, someone has created a rule on the firewall to allow it. So if it is allowed, you probably don't want to be alerted every time. But if you are, then that's a conversation to have.
So back to the very start. Have you identified the originating traffic?
Many thanks again for your follow up, much appreciated !
QuoteHave you identified the originating traffic?
Not yet but I don't see something on WAN that could match. That's why I was asking if OPNsense can "probe", that might not be the right word but what I mean is to find out if there are some services/processes running in OPNsense or in one of its services (eg IPS or Ntop) that may be, for valid reasons, making this kind of attempts. But, it keeps happening and I can't find what it could be :-/
QuoteBy default SSH traffic from WAN to LAN will be blocked. So if it is coming in, someone has created a rule on the firewall to allow it. So if it is allowed, you probably don't want to be alerted every time. But if you are, then that's a conversation to have.
As far as I get it, these specific connection attempts are allowed by automatic rules which, if I am correct, a user can not modify. Attaching the subset of automatic rules that cover among other DHCP, SSH and HTTPS. Could it help to check if these automated rules are ok ?
I would also wonder if that is really a SSH packet or a TCP packet sent to port 22, and will get a look at the IDS alerts that were flooded by an abnormal high number of events a few days ago.
probe is the right word, I get what you are saying but no, OPN as in the OS does not.
These rules are the default ones to be able to manage it so is not that https://docs.opnsense.org/manual/firewall_settings.html#disable-anti-lockout
Do you have any port forwards on WAN ?
I don't think it can be port forwarding.
In the screenshot of the first post you say that the source IP is the IP of the firewall itself. That means that the traffic has to come from OPNsense. Port forwarding does not change the source address of the packet, only the destination.
Hi there,
Well, I haven't configured port forwarding between LAN and WAN but managed to see something : I previously mentioned that the unexpected TCP packets from OPNsense hit port 22 and also 80. In a few cases, it happened in the following sequence : port 22, port 80 and port 22 again.
I could see a similar connection going to WAN but now I managed to see that the same sequence happens on the WAN side : connections from OPNsense to the ISP box on port 22, then 80 and port 22 again. Also got traces of that in /var/log/filter.
A "block all" rule has been added, so these packets are not left out anymore, but still I would like to learn what it may be. Any thoughts please to dig into the root cause or source of this ?
Just a quick update : in addition to what's in this thread, I noticed that the IPS was most probably not functional on some days, which was unnoticed for some days as the "df" command doesn't seem to work fine (or maybe very differently than on Linux?)
https://forum.opnsense.org/index.php?topic=46382.0
So any thoughts please to dig into the root cause or potential sources of this thread would be really welcome :-/
Many thanks