-
@pfsjap Sounds like the switch is the problem.
Try putting the pc on a different switchport. -
@pfsjap So if i am understanding you correctly, your client machine connects to an unmanaged switch. That switch connects to one port on the 6100. When the PFsense becomes inaccessible you are still able to ping/access other devices that are connected to the switch. You are not able to access pfsense during this time? Also during this time while pfsense is inaccessible, other devices connected to the switch are able to get to the Internet? Can you verify this?
-
@michmoor Yes, that is right. Except for last point (other devices connected to the switch are able to get to the Internet), which I just assume is right, too.
That's because I did not connect to the NAS gui and verify internet connection. NAS event log has some NTP synchronization error messages, but then again, I have rebooted pfSense quite a few times and have also disconnected WAN cable from pfSense several times while operating the console. I'll check this next time.
-
@jarhead PC is now in another switch port, haven't yet done anything other with cabling.
-
@pfsjap said in LAN interface goes down randomly:
Yes, that is right. Except for last point (other devices connected to the switch are able to get to the Internet), which I just assume is right, too.
the next time connectivity is lost on your client machine, check to see if other devices such as your NAS is able to access the internet. Do not reboot the pfsense until you validate that piece.
-
@michmoor Well, it turned out I was wrong in my assumption, NAS is not able to connect to the internet. However, DNS resolver answers queries. Other LAN segments can connect to the internet.
This is from the NAS:
$ nslookup google.com 192.168.1.1 Server: 192.168.1.1 Address: 192.168.1.1#53 Non-authoritative answer: Name: google.com Address: 142.250.186.46 $ sudo ping 142.250.186.46 PING 142.250.186.46 (142.250.186.46): 56 data bytes ping: sendto: Network is unreachable $I don't know if it is just a coincidence, but visiting this web page has triggered the problem several times: link
-
@pfsjap Is the NAS and your client machine on the same VLAN?
Is your DNS Resolver PFsense or another server?
Do you have Suricata/Snort enabled on the interface? -
@michmoor No VLANs in configuration, PC and NAS are just in the same LAN,
pfSense DNS Resolver is in use,
Snort is enabled with Subscriber Rules.It seems, that a simple picture hosted by i.postimg.cc triggers the problem, for example this.
Since you asked about Snort being enabled, you may want me to disable it, so I will try that next. If it works with Snort being disabled, then there's obviously a bug in Snort or in the rules. If the problem persists, I'll block i.postimg.cc in DNSBL for the time being. I will block it anyway, as I do want to continue using Snort.
-
@michmoor It was Snort, I get the picture ok with Snort being disabled.
I was wondering, if pfBlockerNG gets the domain first, or is it Snort? If Snort, then I have to keep Snort disabled?
-
@pfsjap said in LAN interface goes down randomly:
then there's obviously a bug in Snort or in the rules. I
that's incorrect. Snort rules block things. Snort is not a trivial tool to use. It takes experience and an understanding of networking security to fine-tune. If you see Snort triggered then you need to investigate the rule. Finally, if Snort is enabled my recommendation would be to turn off blocking. Monitor the alerts for some time and understand whats going on.
PFblockerNG would not prevent you from accessing the internet. It will sinkhole sites according to whats in the feeds you selected.
-
There is a simple default snort/suricata rule for the .cc top level domain.
alert dns $HOME_NET any -> any any (msg:"ET DNS Query for .cc TLD"; dns.query; content:".cc"; endswith; fast_pattern; classtype:bad-unknown; sid:2027758; rev:5; metadata:affected_product Any, attack_target Client_Endpoint, created_at 2019_07_26, deployment Perimeter, former_category DNS, signature_severity Minor, updated_at 2020_09_17;)If you keep the system running in block/IPS mode you will have a lot of things like this. Like mentioned above, start out in alert/monitor/IDS to see what triggers. Most likely you will have to turn off a lot of the ET INFO rules .. because they're annoyingly common.
-
@skogs nice! good find. This seems like a case of turning on all rules and then turning on blocking.
For future reference, where did you go to search? I assume in the CLI -
@michmoor Additionally I'd bet the default allow LAN to any rule was also disabled. Snort/Suricata will try to block both side of the conversation, but if the allow LAN rule is still on, that sus LAN machine will still be able to do everything else just fine. If that rule is disabled, then both sides really do get blocked, and it looks like the entire machine or LAN interface ate it when it really is functioning perfectly as designed.
-
@skogs I found it this way..But im assuming you had a better method on locating this rule?
/usr/local/etc/snort/rules: cat *.rules | grep ".cc TLD" alert udp $HOME_NET any -> any 53 (msg:"ET DNS Query for .cc TLD"; content:"|01|"; offset:2; depth:1; content:"|00 01 00 00 00 00 00|"; distance:1; within:7; content:"|02|cc|00|"; distance:0; fast_pattern; classtype:bad-unknown; sid:2027758; rev:2; metadata:affected_product Any, attack_target Client_Endpoint, created_at 2019_07_26, deployment Perimeter, former_category DNS, signature_severity Minor, updated_at 2020_09_17;) -
@skogs I have had 6100 for 14 months now and Snort has been running at least 12 months without trouble with IPS Policy Selection as Security and blocking enabled.
You are right, LAN to any rule is disabled. Remove Blocked Hosts Interval in Snort is set to 3 hours, so after that normal traffic should have continued.
Thank you for explaining what happened and also thanks for @michmoor. This has been very enlightening.
-
@skogs I have been wondering this still, because Snort has always been set to block both IPs and there has been many blocking incidents without any trouble accessing pfSense or internet from the PC.
Also, this interface has default pass list configured. This list includes 192.168.1.0/24, so the PC's access to pfSense should never get blocked by Snort.
-
@pfsjap I got nothing on that. Perhaps you just run an exceptionally clean environment with zero packet anomalies.
for @michmoor pfsense does have an exceptionally good interface for managing snort rules. I used to hate it...but then have dealt with a few others...now I appreciate pfsense's setup.
I don't have a snort instance handy, but it exceptionally similar iirc.
Services - Suricata - Under interfaces click the pencil on an interface
WAN (or LAN) Rules sub tab
The 'available rule categories' section gives you the basic list...for this instance pick the emerging-dns rules list. Find all the rules and enable/disable individually with gui on each individual interface. -
@pfsjap said in LAN interface goes down randomly:
Also, this interface has default pass list configured. This list includes 192.168.1.0/24, so the PC's access to pfSense should never get blocked by Snort.
This is true for any Snort deployment. Traffic passing between HOMENETs wouldnt be subject to snort rules i believe.
There may be more in play here but without knowing how you are set up we are just guessing.
It seems you have blocking enabled. Legacy mode? If so you should be able to see Blocked Hosts. If not using Legacy mode, then individual packets will be dropped matching the rule but not the hosts from communicating. -
@michmoor Legacy mode, yes.
Today 2022-12-12 I set up access to pfSense for iPad in another LAN to be able to see what is going on. Snort had been shutdown since it was clear, that it was the cause.
Started Snot and sent browser to the problem URL and PC's IP came up right away in Snort blocked list. It is in the Home net and Pass list, so why was it blocked? It is also strange, that the dates in the screenshot are from last week, not from today.
Edit: There is also one from today.
-
@michmoor I would prefer inline mode, but have not applied it, because default action of the rules would have to be manually changed from ALERT to DROP.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.