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

    Site to Site and Hair-Pin

    Scheduled Pinned Locked Moved IPsec
    12 Posts 3 Posters 1.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.
    • P
      photomankc
      last edited by photomankc

      I'm working on a plan to add a small NG1100 to a friend's network on the other side of the state to setup a site-2-site. The primary purpose will be to setup a small NAS on his side that stores some of our important data as off-site backup. Pictures / Documents ect. The remote NAS will be behind the 1100 which will be just on his general inside network and I'll set it up so that it does keep-alive to establish the tunnel. I think this use is pretty bog-standard VPN use and it'll work fine.

      A secondary objective would be to create a way for us to use resources on each other's network via the tunnel. For that the situation is a little less standard. Packets that went from my network to his would enter the 1100 as tunneled traffic on the WAN port and then need to exit in the clear to either a host or the gateway on the WAN subnet. Traffic from his network to mine would enter in the clear on the WAN port after being either routed or redirected to the WAN interface and then encrypted and passed back out the WAN over the VPN tunnel.

      My goal is to prevent him needing to tinker much with his own gear to make this work. With a couple of port-forwards setup I can manage the 1100 remotely and setup and maintain the VPN without the need to coordinate every detail with him. On his end the only router is his gateway box which I believe is the Unifi Dream Machine Pro. That handles all his inter-VLAN routing. There is a server also I think he has setup as a sort of home Amazon virtual server cloud. I'm a little hazy now on the details of that but it's beside the point.

      172.18.0.0/15 is my world
      172.16.0.0/15 is his world

      There is a typo on the "Static routes" lable. Should be 172.19.0.0/16 not 172.16.0.0/16

      Here is the flow I'd expect for an internal device on my side to an internal device on his side (172.19.N.100 to 172.16.X.100). Blue is clear and pink is encrypted.
      Site-2-Stie-L2R.png

      Here is the flow Id expect to see for an internal device on his end to one on my side (172.16.X.100 to 172.19.N.100).
      Site-2-Stie-R2L.png

      Now, his FW may send an ICMP redirect to 172.16.X.100 to send it to the 1100 for that host or network but that really won't change the hairpin nature of the traffic.

      So, long winded way to ask, is that going to be something that will work? Getting VPN traffic to hair-pin on the NG1100's WAN interface to connect our regular networks as well as the remote backup network?

      J V 2 Replies Last reply Reply Quote 0
      • J
        Jarhead @photomankc
        last edited by

        @photomankc Would he need to access anything on the backup network?
        If not, you're better off just setting up a separate VPN for each.
        One for lan access and one for backup.

        P 1 Reply Last reply Reply Quote 0
        • P
          photomankc @Jarhead
          last edited by

          @jarhead said in Site to Site and Hair-Pin:

          @photomankc Would he need to access anything on the backup network?
          If not, you're better off just setting up a separate VPN for each.
          One for lan access and one for backup.

          No. There would not really be any cause for him (while on his side) to need to ride the VPN to get to the backup network. That would be just done via the normal firewall if it all.

          So create one IPSEC VPN that carries only 172.18.R.0/24 -> 172.19.0.0/16

          Then create another one that carries only 172.16.0.0/16 -> 172.19.0.0/16

          That's cool so long as the hair-pin for 172.16 to 172.19 is not going to be a problem.

          J 1 Reply Last reply Reply Quote 0
          • J
            Jarhead @photomankc
            last edited by

            @photomankc
            No need for the hairpin.
            Create the vpn to his network for the lan access.
            Create the backup vpn to your stuff.

            Would be a lot better if you just use the pfSense as the gateway for both networks but he may not like that.

            P 1 Reply Last reply Reply Quote 0
            • V
              viragomann @photomankc
              last edited by

              @photomankc
              TCP traffic doesn't work this way with the static route on the UDM. You would run into asymmetric routing issues.

              To go around this, set up a transit network between the UDM and the NG1100.
              If it's not possible to connect the 1100 directly to the UDM configure a separate VLAN, where you put both into.
              Then point the static routes to the new IP of the 1100.

              P 1 Reply Last reply Reply Quote 0
              • P
                photomankc @Jarhead
                last edited by

                @jarhead

                Are you saying create the VPN to his firewall (UDM Pro) for our LAN to LAN traffic? Otherwise I can't see any way to avoid the hairpin.

                Correct, it would be easier, but as I mention he's not really interested in messing around much in his gateway and certainly won't want me to replace his with mine. He's got a remote-office setup and a passing knowledge of networking but when issues crop up it's far too much bother to have to sit on the phone with us each working on our gateway to fix the tunnel.

                I want to deploy hardware that's pretty transparent to him. I configure it all from the 1100 and have access to troubleshoot and work both sides without much risk of messing anything up that he needs for work. I'm just wondering if it's feasible to hairpin the VPN traffic knowing it's not really completely ideal.

                J 1 Reply Last reply Reply Quote 0
                • P
                  photomankc @viragomann
                  last edited by

                  @viragomann said in Site to Site and Hair-Pin:

                  @photomankc

                  To go around this, set up a transit network between the UDM and the NG1100.

                  Yeah, that's an idea I was tossing around a bit. As long as he has a spare interface to get that done without a lot of headache. I think the IN / OUT VPN traffic to HIS LAN would still hairpin but that would keep the routing cleaner.

                  V 1 Reply Last reply Reply Quote 0
                  • V
                    viragomann @photomankc
                    last edited by

                    @photomankc said in Site to Site and Hair-Pin:

                    As long as he has a spare interface to get that done without a lot of headache.

                    This also requires that all involved devices are on the same place. If not create a VLAN on his LAN, as said. Normally VLAN tags passes non-VLAN switches without any issue.

                    I think the IN / OUT VPN traffic to HIS LAN would still hairpin but that would keep the routing cleaner.

                    No, if you have a transit network the traffic goes LAN > transite > NG 1100 > your site and the same route back.

                    1 Reply Last reply Reply Quote 0
                    • J
                      Jarhead @photomankc
                      last edited by

                      @photomankc said in Site to Site and Hair-Pin:

                      @jarhead

                      Are you saying create the VPN to his firewall (UDM Pro) for our LAN to LAN traffic? Otherwise I can't see any way to avoid the hairpin.

                      Yes, that would be the easiest solution.

                      P 1 Reply Last reply Reply Quote 0
                      • P
                        photomankc @Jarhead
                        last edited by

                        Okay, I believe he's using his UDM Pro as a router-on-a-stick and that it does ALL the routing in his network. If we setup two interfaces on the UDM Pro with a small point-to-point network /29 or /30 then I can have all the internet bound traffic and VPN tunnel go out the WAN. All remote backup network gear traffic goes to the LAN. All traffic to friend's internal home networks goes to OPT to his UDM Pro and gets routed as appropriate. No hair-pins. Could even do it with a single port with VLAN tagging and VIPs. Not as dead simple as I hoped but would mean that I have full admin control of both ends of the tunnel since I'm the one most likely to ever try and fix it if it breaks.

                        Site-2-Site Alt-Clean-Small.png

                        V 1 Reply Last reply Reply Quote 0
                        • V
                          viragomann @photomankc
                          last edited by

                          @photomankc
                          Isn't the UDM capable of managing multiple subnets or VLANs?
                          If so, what's the real benefit of the VPN? A VPN for transit within a transit network?

                          P 1 Reply Last reply Reply Quote 0
                          • P
                            photomankc @viragomann
                            last edited by

                            @viragomann

                            I'll just continue on from here. I'm not following your comments really. His UDM is managing VLANs and networks for his clients. I need a connection to his UDM to get my VPN and network routed to and from his UDM. The VPN is to get to discrete networks in two geographically dispersed locations to communicate directly. I have no idea how else it would be done.

                            Appreciate everyone's input. Although I'd still be interested to know if pfSense can handle a hair-pin situation with VPN or if it really needs to cross interfaces to operate at all.

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