Strange GRE issue - no inbound traffic blocked?

  • I have a few GRE tunnels that are exhibiting a strange issue:

    Rules on each interface are:
    UDP Src FarSubnet/* Dst ThisFirewall/123 (for NTP)
    TCP Src FarSubnet/179 Dst ThisFirewall/179 (for BGP)
    UDP Src FarSubnet/* Dst DnsServers/53 (for DNS)
    TCP Src FarSubnet/* Dst AppServers/AppPorts (for a specific application)

    There is also an outbound NAT rule for all RFC1918 subnets to NAT as our WAN CARP IP.

    Strangely, no traffic from the GRE tunnels is blocked at all - everything seems to pass to every destination (internal and external). In addition, the counters for the GRE tunnel rules (which traffic should be matching) are all at 0/0B.

    Another strange thing - I originally thought this was allowing external access only. That isn't the case after testing, but while going down that rabbit hole I noticed that in the states table, most outbound NAT stuff had a state for both the internal interface and the WAN interface between the internal host (and the NATted internal host, respectively) and the external host. For the GRE stuff, there is not internal interface entry in the state table.

  • Rebel Alliance Developer Netgate

    Is this with GRE on its own, or GRE inside a transport IPsec tunnel?

  • Inside IPSEC.

  • Rebel Alliance Developer Netgate

    What are you connecting to that needs GRE with transport IPsec? There may be a better solution soon. Routed IPsec (VTI) will be in 2.4.4.

  • Oh I know, I was debugging that with you a couple weeks ago :) Verizon private network tunnels "should" support VTI, so we'll probably move to that once 2.4.4 is gold.

    However, we do have a few IPsec connections that require GRE. Any idea why this might be happening?

  • Rebel Alliance Developer Netgate

    Ah, I didn't recognize the name, but I see it now. :-)

    See the issue referenced above. There is some odd state behavior with GRE combined with transport mode IPsec in general.

  • Ah crap :)

    Honestly it doesn't seem like that issue, but if states are just wonky (i.e. setting them when the traffic should in fact be blocked) perhaps I'll have to get 2.4.4 running in alpha on production - already doing it on our Netgate boxes, but really scared to do it on infrastructure I don't own :)

Log in to reply