LAN connection drops all the time
For a few days, I'm experiencing problems with the internetconnection.
At first I thought it was a provider issue since I found information on similar problems but today I looked a little bit further and it seems it's something else.
- from the console: pinging an internetaddress works flawless
- from the console: pinging a LAN address also without drops
- from the LAN: pinging the PF LAN ip returns a lot of errors
- accessing the webinterface: timeouts or a big delay
- internettraffic: troublesome
I replaced the NIC but that doesn't make any difference.
From the logs, I couldn't seem to find a possible cause for this but that might also because of my limited knowledge.
Any suggestions on how to tackle this?
PFsense 2.1 with squid3, squidguard & snort. System is idling all the time between 97-100% and rebooting didn't make a change.
Bad cable? Bad switch?
I checked that cables are plugged in firmly, the switch has been replaced recently.
On the LAN, there is no other problem and wouldn't that ping problem exist in both directions?
Yes, you would think it'd cause problems in both directions.
I just noticed you're running Snort. That would always be my first suspect in unexplained issue onset.
Finally, all LAN traffic has been blocked, even pings to all hosts also are being dropped.
By disconnecting the PF box it got restored so it seems like it's related.
Will look into it this evening.
Do you - or anybody else - know how/if it can be done to disable snort if I cannot access the webinterface?
Had a quick look but didn't find anything.
If Snort has blacklisted your LAN addresses then maybe:
You could try '/usr/local/etc/rc.d/snort.sh stop' but it might just restart again, I'm unsure.
If it's because of Snort and I stop the service, I will immediately know it since LAN traffic goes through and I should be able to enter the webinterface again to uninstall Snort.
Worst case, I'll do a reinstall and restore the settings which goes quite fast but I prefer to keep this as the last option because:
- I'm not sure it's solved
- it's not clear what the reason was
I'm no expert in Snort to be honest.
There should be something in the logs to suggest what have been blacklisted if it was.
If you shutdown Snort when there are rules blocking clients in place it may not necessarily remove them, you might still not be able to access the webgui.
Is it possible that, due to a problem with the switch, the PF box 'did go nuts' with this result as behavior or is this to far fetched?
Disabling Snort did not any change but it's clear that the switch has some ports that do not work properly and I had to move some cables to get everything working.
Now, I can ping all hosts on the LAN and they remain online.
Hard to say. If your switch is suspect then almost anything could be true.
Anything in the logs?
I cannot access the system via the webinterface.
The console works normally and I still can ping out on both WAN & LAN.
I reassigned the NIC's & addresses.
With a ping every 5 seconds, now and then there is a succeeded connection and most of them are timed out.
You can access the logs from the console using the clog command:
Not suggested on that page is using 'less' to view the long log files in the console. E.g.
[2.1.1-PRERELEASE][firstname.lastname@example.org]/var/log(6): clog /var/log/filter.log | less
Scroll through with the cursor keys, use 'q' to quit. Appologies if I'm patronizing you. ;)
Look in the sysem.log and the firewall log (filter.log) though it requires some interpreting. I'm not sure if the Snort logs are there too I've never looked. Try to check that too.
The other thing that can cause dropped packets is the system is too busy to reply. You've already stated that it's mostly idle which would appear to rule that out but try running 'top -SH' to check.
Steve, I finally went for a clean install - wasn't sure that I could interpret the log files on my own, in a reasonable time, and didn't want to occupy you/others to much.
On the other hand I'm still curious though how this could have been solved and what the reason was for this issue.
Hey man, don't worry about patronizing me: I'm very grateful that you stayed with me! ;-)
Thanks A LOT for your help.
I have the exact same problem… About a 50 user network, systems radomly cannot ping the outside network, perform a DNS flush / release /renew somtime will resolve the problem. Switches are Netgear 24 port Gigabit (which I may believe they are having an issue...but not 100% sure) I have never had this problem with other installs of pfsense.
I do not use snort or any other programs ... just a base install of pfsense.
One NIC is Broadcom (onboard) and other is an Intel Pro 1000.
It's probably an unrelated problem, though we never did get a definitive result so it could be. ;)
How much traffic are you pushing through the box? Does it start misbehaving under particularly high throughput?
With Broadcom and Intel NICs you should probably first try the recommended tweaks for each here:
I don't know if this is the case, I work on a university and a student brings his own wifi access point from home without us knowing he plugs it to the network on the same vlan with pfsense, where its default IP was the same as pfsense LAN IP address 192.168.1.1, both running dhcp, maybe not the same issue, but it causes almost the same symptom that you have due to ip conflict.
How we found out? Skip skip…. I ran DHCP Find program and discover a rouge dhcp server which was the wifi AP.
I know, we have a security issues, long story... :) and we fixed the problem...
Yes rogue dhcp servers can be a huge PIA! ;)
Another user here experienced a similar thing except that the rogue server turned out to be an mobile hotspot application running on an iPhone. The user who's phone it was didn't even realise it was running and of course it was only there during work hours when diagnosing stuff is most difficult.
Always worth remembering that story when things are looking really weird. Check the MAC of the DHCP server, you can see if it's the correct one instantly and if it's not you can find out the manufacturer which gives you something to look for. Of course that doesn't help if it's a malicious attack where the rogue server has spoofed your own MAC.