Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    TCP Traffic over GRE over IPSEC tunnel gets blocked

    Firewalling
    3
    6
    7.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      sili
      last edited by

      Hello

      I cannot resolve a problem with a gre tunnels between 2 pfsense boxes. First i set up two IPSEC tunnels in tunnel mode between the WAN IP's.
      Then i created 2 GRE Tunnels between the 2 public IPs with the Network 172.16.0.0/30 and 172.16.0.4/30.

      GRE_11_21:172.16.0.1/30<–----------------------------------->GRE_21_11:172.16.0.2/30
                                                /-WAN1<-------------IPSEC Tunnel------------>WAN1-
      10.64.0.0/16<-[pfSense2.0RC1]                                                                          [pfSense2.0RC1]->10.80.0.0/16
                                                -WAN2<–-----------IPSEC Tunnel------------>WAN2-/
                      GRE_10_20:172.16.0.5/30<------------------------------------->GRE_20_10:172.16.0.6/30

      So far all good, pinging GRE Endpoints from each router works.
      Then activated RIP Routing Protocol on both boxes on the GRE Interface. Routes are exchanged and i can ping from both networks.
      But TCP traffic is all blocked. In the firewall rules i opened everything on the GRE interfaces. See picture:

      http://img17.imageshack.us/i/grefirewallsettings.png/

      Here is the output from the firewall log:

      http://img52.imageshack.us/i/grefirewallsettings.png/

      When clicked on a blocked entry the reason is:

      The rule that triggered this action is:
      @2 block drop out log all label "Default deny rule"

      I think i have already opened everythin on the firewall and I just can't find this rule in the FW settings.
      Or are the GRE Tunnels wrong configured?

      Thank you for any of your time, I am just getting frustrated! I tried now for days all kind of different settings but I always come to the same error.

      Thanks!

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        The blocked entries are the "return" traffic from the request - so you have some asymmetric routing going on.

        For example on the first line, what happened was:

        10.80.32.1 sent (somehow) a connection attempt (TCP SYN) to 10.64.32.3:5723
        10.64.32.3:5723 responded with a TCP SYN/ACK to open the connection – this part went over the GRE tunnel

        Because the firewall didn't see the SYN over the GRE tunnel, only the SYN/ACK, it dropped the packet because it was not part of an existing state, and it was not creating a new connection.

        Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • S
          sili
          last edited by

          Hi

          Okay, i didn't take this in account. That's why ping work but not TCP. I tried now to figure out what could be wrong in my routing. The conclusion is that blocks do not not happen anymore if i do not run the traffic between the wan endpoints over ipsec. I tried tunnel mode in phase 2 from wan endpoint to wan endpoint and even transport mode.
          For some reason the Traffic is then no routed back to the GRE interface if IPSEC enabled. Is my concept wrong or what's the mistake?

          Thanks a lot!

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            Normally if you are using GIF/GRE you have IPsec in transport mode only, not tunnel mode. And the GIF/GRE tunnel is built between WAN IPs, just like the IPsec tunnel normally would.

            If you had gif/gre and IPsec in tunnel mode both at the same time, it might explain some inconsistent behavior.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • _
              _igor_
              last edited by

              @sili:
              Are you willing to share your GRE / IPSEC-config? I'm having similar probs and thinking that i made some config-errors. My counterpart is a cisco and i don't have access to the logs there.

              Second is that my GRE over IPSEC-knowledge is somewhat low.

              1 Reply Last reply Reply Quote 0
              • S
                sili
                last edited by

                Hello igor

                I am very sorry for my late reply. Somehow i didn't get a notification about your Post .
                And as I had other projects to finish I wasn't in the forum for some days now.

                Perhaps you have already solved your problems in the meantime.

                Because of these other projects I have purged the ospf/gre over ipsec setup. At the moment we have just one ipsec tunnel to each of our remote sites and we do manual failover in the case of an outate of one line. But I would be very happy to get this issue solved and to do ospf routing over VPN.

                As jimp has written the stateful packet inspection firewall of pfSense blocks the traffic because the TCP packets do not come back on the same interface as they were sent on. But i couldn't figure out what was wrong in the routing. Somehow I think that ipsec does not route traffic back to the gre interface. Do you/Did you have the same errors in the firewall log?

                Well, I try to set up a testing environment in the next days and hope to find an error. It would be very cool to get this working. If you wish i can send you my config then.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.