Firewall default deny rule blocks traffic, which is indeed allowed by another rule



  • Hello Forum,

    i've got a mess to come over, but i really doesn't understand what and why this ist happening.

    first of all what is this all about. I introduced a pfSense SG-3100 directly behind my ISP Router and worked the network configuration according my needs.

    within the firewall LAN is a separate VPN Gateway. The tunnel is up and working and everything through the tunnnel, seems to work fine.

    Now i have two NAS boxes. One is on this site of the tunnel, and the other is abroad.

    Box 1 is on 192.168.0.1
    Box 2 is on 192.168.1.1 (remote through the tunnel)

    Before introducing the SG-3100 i had a rsync from Box 2 to Box 1 running. This connection broke, since i introduced pfsense.

    And now the catch up get's weard.
    In the firewall logs i found:

    LAN 	Default deny rule IPv4 (1000000103) 	192.168.0.1:22		192.168.1.1:53703		TCP:SA
    

    Okay, why at all does this rule block traffic from pfsense LAN ?
    I would have understood, if this would be the way around, because the establishment of this connection is supposed to come from Box 2 (192.168.1.1, not inside pfsense LAN) but there is nothing at all in any logs i could find.

    And it get's even worse. If i add a rule, to explicit allow this kind of traffic, pfsense doesn't care about this rule and keeps blocking it.

    IPv4 TCP 192.168.0.1 22 192.168.1.1 * *
    

    The block entry in the logs keep showing up.

    So what the hell am i missing here ?
    Does anyone know were i took the wrong turn, or what i didn't consider yet ?

    Any help would be appreciated.



  • @I2e4per said in Firewall default deny rule blocks traffic, which is indeed allowed by another rule:

    In the firewall logs i found:
    LAN Default deny rule IPv4 (1000000103) 192.168.0.1:22 192.168.1.1:53703 TCP:SA

    Okay, why at all does this rule block traffic from pfsense LAN ?

    Because pfSense has no state for the connection. It's SYN-Ack packet, but pfSense obviosly did never see the corresponding SYN packet.

    @I2e4per said in Firewall default deny rule blocks traffic, which is indeed allowed by another rule:

    So what the hell am i missing here ?

    I assume the correct routes to the other site.

    But that have nothing to do with pfSense. Since your VPN gateway is inside your LAN (for whatever reason) you have to add routes to all devices which should be communicate with the remote site. The traffic doesn't pass pfSense.

    Better practice, however, is to put the VPN gateway into a separate subnet (transit network), so the packets can pass pfSense which is the default gateway without special routes on the devices, but you need routes on the VPN gateway and on pfSense.



  • Hello @viragomann, and thank you very much for coming back to me so fast.

    Yeah, your're right about the routes, and i already had them assigned correctly within pfsense acting as router instance for it's LAN behind. Also i had configured the IP for the VPN as an extra Gateway for this routes, so pfsense should use / know it.
    That was not the problem, cause i was able to ssh through the tunnel, ping, rdp worked, and also fileshares on the remote NAS.

    After writing my post, i found another setting in the advanced firewall settings. It is called "filter static routes". This was unchecked, so i checked it. And obviously, this seems to do the trick.
    It states, that the firewall won't take care about any traffic which is related to routes on pfsense if it is checked.

    Rsync directly worked after it.

    But as this is working now, i am not really satisfied with it. From my point of view, this doesn't explain why some kind of traffic was posible, and rsync wasn't.

    Maybe someone has an explanation, i would be interested in it.

    On the other hand i noticed your caveadd about dragging the vpn gateway to an extra net. I have never thought about that, but i think i see your point. This is a good advice. Thanks for that.

    Thank you so far.



  • I have a bout the same issue. In my case it is even crazier, since no routing is needed.
    It is in the same subnet (192.168.0/23)
    I assume you have 2 subnets



  • Hey Rob,

    you're right. I am on two different subnets. 192.168.0.0/24 and 192.168.1.0/24 so i need routes on both sides.


Log in to reply