Pfsense DHCP working but nothing else will
-
I have been having this issue once in a while with pfsense. I have the latest version loaded up on a watchguard x500 and it will work great for a couple of days (maybe 4-5 sometimes) and then all of a sudden quit working. Whats weird is that with my computer hooked up to the LAN interface I will get an IP via the DHCP enabled in the firewall. I use persistent IP address (my computer 10.0.0.10) and it will see my MAC and give me the appropriate IP with the correct gateway (10.0.0.254) and DNS (10.0.0.254). However if I try to ping the gateway (10.0.0.254) I get nothing and the webgui (https://10.0.0.254) I get nothing. I try to telnet into it or SSH and it will fail. I have done this previously multiple times to confirm ssh does work. The last time this happened to me I reloaded the OS and had to deal with it that way but that is obviously rather inconvenient. The last time the happened I also enabled another interface for an internal network using the subnet (192.168.1.0/24) I thought if this happened again I could try that interface also, but its the same results. I will get a DHCP (non-persistent, not setup on this subnet) response and correct IP info but again cant login to the PFsense interface anyway. Please let me know if there is anything I can do to cure this problem, thank you!
-
Is there something that I am not thinking to try? I dont know why this wont work fine for me. If you have any ideas please let me know so I can keep my network up and running thanks!
-
Nothing in the logs? Interfaces locking up is a common problem on the x-core boxes but dhcp does not work in that case. Have you added appropriate firewall rules to the new interface?
Dhcp working but nothing else is usually a firewall rule problem.Steve
-
Which firewall rules would I need to add for that? is there any logs in particular that I can post for some help?
-
If you look in the firewall rules for LAN you will see there is a default rule that allows out all traffic. LAN is the only interface that is given such a default rule you will need to replicate that rule on the OPT1 interface.
If you look in the firewall logs you will see lots of hits from your client on the OPT1 subnet if an appropriate rule is not in place.That doesn't explain why the traffic stops on LAN though. If it is the known fault then if you look in the system log you will see entries like: 're0 watchog timeout' or similar to that.
Are you running and packages? Specifically Snort? That can cause unexplained disconnects.
Steve
-
hmmm interesting, I would check out the firewall rules but unfortunetly I cant even get that far. I can however communicate on the COM port and I can do anything from there. I was running openvpn on there and snort. Is there anyway to disable this from the COM menu or anything else I can try from here?
-
If it is a firewall issue you can temporarily disable the firewall entirely from the console with:
pfctl -dGo in and disable or uninstall Snort, or whatever is causing the problem, then re-enable the firewall:
pfctl -eDuring this time you will have no firewall or course!
You can also look at the logs from the console, for example:
clog /var/log/system.log | grep timeoutThe firewall logs are stored as raw pf filter logs which are more difficult to read at the console but you can look:
clog /var/log/filter.log | lessYou can also try to stop Snort frm the console but in my experience (which was admittedly a while ago) it has a habit of leaving the block rules behind after it's been stopped:
/usr/local/etc/rc.d/snort.sh stopSteve
