LAN IPv4 access Blocked

[JamesMcBride]

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

[johnpoz]

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.

[JamesMcBride]

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

.png)
.png_thumb)

[johnpoz]

well those rules don't show any hits on the anti lockout rule - so you sure you actually were hitting the pfsense lan IP?

[JamesMcBride]

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

[johnpoz]

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?

[JamesMcBride]

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.

[JamesMcBride]

if it's relevant, this is nanobsd running on a repurposed HP thin client

[JamesMcBride]

Should really have included the log entries before too… See attached

.png)
.png_thumb)

[johnpoz]

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.

[JamesMcBride]

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!

[JamesMcBride]

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.

.png)
.png_thumb)

[johnpoz]

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

[JamesMcBride]

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!

[johnpoz]

why do you not just put in a override for owa.mydomain.com to point to the rfc1918 address directly..

[JamesMcBride]

Yeah, this is what I will do.

Thanks again