LAN connection drops all the time

Peter-Z

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

stephenw10

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.

Steve

Peter-Z

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.

stephenw10

Hard to say. If your switch is suspect then almost anything could be true.
Anything in the logs?

Steve

Peter-Z

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.

stephenw10

You can access the logs from the console using the clog command:
https://doc.pfsense.org/index.php/Why_can%27t_I_view_view_log_files_with_cat/grep/etc%3F_(clog)

Not suggested on that page is using 'less' to view the long log files in the console. E.g.

[2.1.1-PRERELEASE][root@pfsense.localdomain]/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

Peter-Z

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.
P.

kjemison

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.

Any ideas???

stephenw10

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:
https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards

Steve

jswj

Hi,

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...

stephenw10

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.

Steve