LAN interface goes down randomly
-
@pfsjap curious, what logs do you see on the QNAP?
-
@michmoor It's an unmanaged switch, so no logs.
-
@pfsjap A bad cable can cause instability in a network link. Try swapping the cable.
If you are still having link drops then i recommend switching the ports used on the switch first. If that doesnt work switch the port used on the Netgate.
If that doesnt work swap out the switch.
All else fails you narrow the problem down to the Netgate appliance.
I think you will find out the problem well before all of that anyway but lets first swap out the cable. -
@michmoor and @rcoleman-netgate I realized that "LAN interface goes down" was not an accurate way to describe the problem, because when the access problem (while processing HTTP/2 connection) starts in one of the two devices connected to this LAN segment and ping to that device fails in pfSense (Permission denied), I can still ping the other device successfully. So the interface itself is certainly not down..
This is not to say, that there couldn't be a failing cable somewhere in the chain, but it's probably not the one connected from the LAN port to the switch.
-
@pfsjap so to clarify, on the main pfsense dashboard landing page the interface is up and shows with a green arrow?
This is sniffing of a permissions error due to attempting to change/disable the login accounts under system-usermanager-users.
-
@skogs When the problem is "on", I can't get to the pfSense dashboard, I can only access the console, so don't know what the dashboard shows. This is by design, I don't want the dashboard to be accessible in other LAN segments.
I should have been more clear about the topology. The LAN port in 6100 is connected to Qnap unmanaged switch. The failing device connected to the switch is a Windows PC (.100), the other device connected to the switch is a NAS (.20).
Because pinging the PC fails from console, but pinging the NAS succeeds, interface has to be up. Also the cable between 6100 and switch should be OK. I didn't try to ping NAS from PC, but will do that if/when the problem occurs again.
-
@michmoor It happened again and while the PC had no connection to pfSense or internet, pinging NAS succeeded. From pfSense console pinging PC also failed and pinging NAS succeeded. It seems that just one IP is affected, not the interface.
Cable problem seems a bit strange and unlikely to me, because the NAS is accessible from the PC and from the pfSense. But I guess there's nothing more I can do, but follow your advice.
CE edition is public source? Maybe I could have a look in the source...
-
@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.