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

    Problem with TCP and GRE tunnel

    Scheduled Pinned Locked Moved General pfSense Questions
    64 Posts 3 Posters 6.4k Views
    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
      StomperG @stephenw10
      last edited by

      @stephenw10 In local PFsense there is a firewall rule specifying that each IP provided by the isp has the gre tunnel gateway and we do not nat those IPs which means they are leaving through the tunnel how they are. In the remote PFsense there is a static router for each IP address to go through the gre tunnel and I disabled nat in the remote PFsense for these IPs. I did pcap on the wan and gre on both pfsenses and the traffic is being sent and received on the local pfsense lan as well. The ping goes perfectly both from the outside to the inside and from the inside to the outside.I also did a traceroute from my PC to an IP and it is correct and a traceroute from a host with an IP from my isp to 1.1.1.1 and I see both going through the gre and reaching the destination.The dns on the host with an IP from my isp are 1.1.1.1 and 8.8.8.8 but when I ping a dns or curl a dns it takes a long time.However, I can see the response from 1.1.1.1 to the dns I want in the pcap in the local pfsense on the lan, the dns and the IP address of the requested dns. But on the host it takes a long time.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        So those public IP addresses are globally routed to the VPC? You purchased them from the VPC provider?

        If they are routed to the local pf by your ISP that then creates an asymmetric route.

        S 1 Reply Last reply Reply Quote 0
        • S
          StomperG @stephenw10
          last edited by StomperG

          @stephenw10 But the ISP is not making a static route, it's proxy arp. And yes the IPs are bought from the VPC provider

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Ok, if the IPs are purchased from the VPC then they are presumably routed to the public IP there. So that should avoid any asymmetric routing.

            So I would run a pcap on the WAN interface at the VPC end and see what's happening there for an ICMP and TCP connection.

            S 1 Reply Last reply Reply Quote 0
            • S
              StomperG @stephenw10
              last edited by

              @stephenw10
              There's the pcap -> (WAN) on the VPC with "ping google.com" and "curl ifconfig.me"
              1bb6b829-9a8d-45b3-b640-3b99dc8d6160-image.png

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by stephenw10

                Can you upload the actual pcap file here? https://nc.netgate.com/nextcloud/s/BynTbfz33wrToAm

                I assume the curl fails?

                S 2 Replies Last reply Reply Quote 0
                • S
                  StomperG @stephenw10
                  last edited by

                  @stephenw10 I'll do it in a sec, no the curl works but with a lot of delay

                  1 Reply Last reply Reply Quote 0
                  • S
                    StomperG @stephenw10
                    last edited by

                    @stephenw10 Uploaded the pcap from VPC, WAN while doing a curl ifconfig.me

                    1 Reply Last reply Reply Quote 0
                    • stephenw10S
                      stephenw10 Netgate Administrator
                      last edited by

                      Hmm, weird there's a 30s gap between the initial syn/ack handshake and the http get request.

                      Does that same delay appear at local pf in a pcap there? It seems unlikely it would actually just wait which implies the initial request is being lost. Perhaps an MTU issue?

                      Is there any reason you chose to use GRE for this instead of something encrypted?

                      S 1 Reply Last reply Reply Quote 0
                      • S
                        StomperG @stephenw10
                        last edited by

                        @stephenw10 Do you want a pcap on the local pf? If yes which interface? GRE?
                        An there's no reason to chose GRE, I just heard about it and decided to give it a try.

                        1 Reply Last reply Reply Quote 0
                        • stephenw10S
                          stephenw10 Netgate Administrator
                          last edited by

                          The pcap should be identical on the local GRE and LAN interfaces. If it isn't that's probably where the problem is.

                          GRE has a few quirks that OpenVPN or route-mode IPSec do not. Since you're not NATing or encrypting though you shouldn't be hitting any of them.

                          S 1 Reply Last reply Reply Quote 0
                          • S
                            StomperG @stephenw10
                            last edited by

                            @stephenw10 I think they are but maybe i miss something, do you want me to upload the pcap on the same URL?

                            1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              Yes please.

                              S 1 Reply Last reply Reply Quote 0
                              • S
                                StomperG @stephenw10
                                last edited by

                                @stephenw10 Done

                                1 Reply Last reply Reply Quote 0
                                • stephenw10S
                                  stephenw10 Netgate Administrator
                                  last edited by

                                  Ok well the delay is a lot longer there but you can see the local host sends the http request almost immediately after the handshake. So packets are being lost somewhere.

                                  Try running pcaps on both ends of the GRE tunnel at the same time. Run the curl command and see how they compare.

                                  S 1 Reply Last reply Reply Quote 0
                                  • S
                                    StomperG @stephenw10
                                    last edited by

                                    @stephenw10 Just upload them. Also how can I open the pcap files to compare them?

                                    1 Reply Last reply Reply Quote 0
                                    • stephenw10S
                                      stephenw10 Netgate Administrator
                                      last edited by

                                      Using Wireshark is easiest. Though you can also just set the view to high or full in the pfSense webgui and see the timing info etc.

                                      S 1 Reply Last reply Reply Quote 0
                                      • S
                                        StomperG @stephenw10
                                        last edited by

                                        @stephenw10 But are you able to see any difference between them now?

                                        1 Reply Last reply Reply Quote 0
                                        • stephenw10S
                                          stephenw10 Netgate Administrator
                                          last edited by

                                          Yes, you can see the local end sees the initial http request at 0.02 but no reply. It retransmits that request 10 times until it finally sees a reply at 114s.

                                          At the remote end it never sees any requests arrive until 114s.

                                          Something is dropping those packets in the route. They are not large packets so not an MTU issue that might be caused by encapsulation.

                                          I assume you gateways setup for the GRE tunnel, do you see packet loss logged on them?

                                          Just to confirm; are you using encryption here? GRE over IPSe transport?

                                          S 1 Reply Last reply Reply Quote 0
                                          • S
                                            StomperG @stephenw10
                                            last edited by

                                            @stephenw10 On both sides pf say 0.0% packet loss while using curl. Also no, im not using encryption or GRE over IPSe

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