PfSense blocks tcp connections after a few seconds



  • Hi,

    My pfSense for some unknown reason, is blocking my tcp connections after a few seconds to some hosts that are accessed throught a linux gateway that has vpnc connected to a VPN and then iptables making nat, i can connect for example to 172.19.44.185 via ssh, do some commands, and then after a few seconds connection gets blocked.

    In pfsense firewall logs i get this:

    block Jul 10 23:25:45 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA
    block Jul 10 23:25:45 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA
    block Jul 10 23:25:45 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA
    block Jul 10 23:25:46 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA
    block Jul 10 23:25:46 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA
    block Jul 10 23:25:46 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA
    block Jul 10 23:25:46 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA
    block Jul 10 23:25:47 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA
    block Jul 10 23:25:49 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA
    block Jul 10 23:25:50 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:FPA
    block Jul 10 23:25:53 LAN 192.168.2.152:34061 172.19.44.185:22 TCP:PA

    The rule that triggered this action is:

    @5 block drop in log inet all label "Default deny rule IPv4"

    I've got a rule on my LAN interface that accepts all traffic from LAN net to 172.19.44.0/24 net using gateway 192.168.2.151 (linux + vpnc + iptables)

    These are my rules on the LAN interface:

    IPv4 * LAN net * 172.19.44.0/24 * 192.168.2.151 none   LAN -> EXT_CLIENTS -> VPN-GW
    IPv4 * LAN net * * * WAN_LOADBALANCE none   LAN -> OUT LOADBALANCE

    IPTABLES rules on the vpn gateway linux machine:

    *nat
    :PREROUTING ACCEPT [1158:98142]
    :POSTROUTING ACCEPT [36:8644]
    :OUTPUT ACCEPT [19:970]
    -A POSTROUTING -s 192.168.2.0/24 -o tun0 -j MASQUERADE
    COMMIT
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
    -A INPUT -p icmp -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -m state --state NEW -s 192.168.2.0/24 -p tcp --dport 22 -j ACCEPT
    -A INPUT -j REJECT --reject-with icmp-host-prohibited
    -A FORWARD -i tun0 -j ACCEPT
    -A FORWARD -o tun0 -j ACCEPT
    -A FORWARD -j REJECT --reject-with icmp-host-prohibited
    COMMIT

    Anyone experienced this kind of problem before?

    This didn't happened with my previous firewall (Endian Firewall Community), probably will have to get back to Endian until i get this fix on pfsense :(


  • Rebel Alliance Developer Netgate

    You have asymmetric routing happening, e.g. packets flow:

    a->b->c
    c->a

    'b' being pfSense. Since it never sees the reply packets, it believes the TCP states are half open, not established, and thus it removes the states after a short time as it would for a failed connection.

    What you want to set to avoid this is System > Advanced, Firewall/NAT Tab: Check "Bypass firewall rules for traffic on the same interface"



  • How can we troubleshoot this problem?

    @jimp:

    You have asymmetric routing happening, e.g. packets flow:

    a->b->c
    c->a

    'b' being pfSense. Since it never sees the reply packets, it believes the TCP states are half open, not established, and thus it removes the states after a short time as it would for a failed connection.

    What you want to set to avoid this is System > Advanced, Firewall/NAT Tab: Check "Bypass firewall rules for traffic on the same interface"



  • @labasus:

    How can we troubleshoot this problem?

    @jimp:

    You have asymmetric routing happening, e.g. packets flow:

    a->b->c
    c->a

    'b' being pfSense. Since it never sees the reply packets, it believes the TCP states are half open, not established, and thus it removes the states after a short time as it would for a failed connection.

    What you want to set to avoid this is System > Advanced, Firewall/NAT Tab: Check "Bypass firewall rules for traffic on the same interface"

    Yes, with that option activated solves my problem. Thankx.