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


  • LAYER 8 Global Moderator

    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)


  • LAYER 8 Global Moderator

    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


  • LAYER 8 Global Moderator

    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)


  • LAYER 8 Global Moderator

    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)


  • LAYER 8 Global Moderator

    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!


  • LAYER 8 Global Moderator

    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


Log in to reply