LAN IPv4 access Blocked
-
Hi,
I upgraded my pfSense 2.3.2 box to 2.3.3 last night and when it came back it seemed to completely block all traffic (from the LAN side).I couldn't even access the web or ssh interfaces. I managed to get in eventually by turning off the firewall (pfctl -d)
Looking in the logs, I can see it is being blocked by:
1000000103 default deny rule ipv4
My topology looks like this:
igb0 –> pppoe (WAN)
igb1 --> LAN (192.168.6.0/24)
igb1 VLAN40 --> REG (81.187.18.xx/29)
igb1 VLAN11 --> GFC (192.168.185.0/24)They do also have IPv6 addresses and I can ssh over that without any issues.
Any idea how I can get my IPv4 working again?
Thanks
James -
well post up your lan rules.. There is an antilock rule that should always allow you access from lan to the http/https and ssh ports on the lan interface.
-
Anti-Lockout rule is indeed there and there's nothing special about the rest of the rules, which is why I'm asking.
See rules attached
![2017-02-22 (2).png](/public/imported_attachments/1/2017-02-22 (2).png)
![2017-02-22 (2).png_thumb](/public/imported_attachments/1/2017-02-22 (2).png_thumb) -
well those rules don't show any hits on the anti lockout rule - so you sure you actually were hitting the pfsense lan IP?
-
Yes, this is with a laptop plugged directly into the pfsense's LAN (nothing else connected)
Laptop has 192.168.6.2 pfSense has 192.168.6.1
-
well makes zero sense.. Could you ping pfsense ip in lan? Did you see its mac in your arp table? Maybe you just had no connectivity at all?
-
Yes can always ping it and it is definitely the firewall that is blocking it, as soon as I do pfctl -d I can access the webgui / ssh, as soon as I do pfctl -e I can't.
And this happened following the reboot after upgrading to 2.3.3 - has been working for months without any issues prior to this.
-
if it's relevant, this is nanobsd running on a repurposed HP thin client
-
Should really have included the log entries before too… See attached
![2017-02-22 (4).png](/public/imported_attachments/1/2017-02-22 (4).png)
![2017-02-22 (4).png_thumb](/public/imported_attachments/1/2017-02-22 (4).png_thumb) -
all of those blocks are out of state.. You see the flags on them are PA.. So that is an ACK - where is the SYN?? Yes the firewall should block those with the default rule since they are out of state.
-
Very strange, I've just come back to do a fresh log from scratch and it's working ok again now! Not quite sure what is going on here, but thank you for your help!
-
Ok, I think I've figured out what's causing it, but can't see why. It seems to be related to the attached NAT rules being enabled.
![2017-02-22 (5).png](/public/imported_attachments/1/2017-02-22 (5).png)
![2017-02-22 (5).png_thumb](/public/imported_attachments/1/2017-02-22 (5).png_thumb) -
Why would you forward traffic hitting your lan interface with a dest on your wan IP to a IP on your lan network?? But yeah that could cause issues..
-
Just for consistency of DNS records.
In this case, 443 on my wan IP nats to 443 on my exchange server. The A record for owa.mydomain.com goes to my wan address. If a device (say my phone) wants to connect to my owa server, it looks up owa.mydomain.com and gets my WAN address - if the NAT rule isn't there it can't get to it.
I could get around this with ACL's in bind, but these rules did work previously and they're only setup for specific ports, which was why it was a bit of a sod to find!
-
why do you not just put in a override for owa.mydomain.com to point to the rfc1918 address directly..
-
Yeah, this is what I will do.
Thanks again