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

    Tunnelling a Service Through Site-to-Site Out to Internet

    Scheduled Pinned Locked Moved Routing and Multi WAN
    17 Posts 3 Posters 975 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
      SeaMonkey
      last edited by

      I can't quite wrap my head around what forwarding and outbound NAT rules to set up for this, but here's what I want.

      Internet traffic on a given port comes in OVPN1 at SiteA and is forwarded through a site-to-site VPN to a server at SiteB. Server at SiteB sends its response back through the site-to-site VPN and out of OVPN1 at SiteA.

      Running tcpdump on the server at SiteB, and running a port test from yougetsignal.com, I can see the traffic hitting the server, but the return path isn't working, as the test still shows the port as closed.

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

        Did you assign an interface to the OpenVPN instance on site B?

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

          Yes.

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

            If I run tcpdump on the server, it shows both inbound and outbound traffic on the port. However, if I run tcpdump on the site-to-site interface at SiteB, it only sees inbound traffic from SiteA on the port.

            I set up a rule on the LAN tab for traffic from the server source ip and port to use the site-to-site as the gateway, but that doesn't seem to be working.

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

              So presumably there is something wrong with the VPN interface. However, if you don't provide more details of your settings like scrennshots, it's hard to say, what exactly you're missing.

              If you set no value on seeing the origin source IP addresses on the server you can do a workaround with NAT.

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

                vpns1.png vpns2.png vpns3.png vpns4.png vpns5.png

                1 Reply Last reply Reply Quote 0
                • DerelictD
                  Derelict LAYER 8 Netgate
                  last edited by

                  The firewall rules for the traffic going to the server at site B must not match the rules on the OpenVPN tab. They must be matched only by rules on the assigned interface tab.

                  Chattanooga, Tennessee, USA
                  A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                  DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                  Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

                    For testing purposes, I changed the allow any rule on the OpenVPN tab to include !192.168.0.3 to ensure that no traffic rules were being matched there.

                    sitebopenvpn.png

                    I created a rule on the LAN tab to forward traffic from the server on the relevant port number through the site to site gateway.

                    siteblan.png

                    I duplicated this rule on 'the SITE2SITE interface.

                    sitebsitetosite.png

                    Monitoring the LAN interface, the response traffic is making it there, but isn't seen by the SITE2SITE interface.

                    tcpdump.png

                    What do I need to change?

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

                      @SeaMonkey said in Tunnelling a Service Through Site-to-Site Out to Internet:

                      I created a rule on the LAN tab to forward traffic from the server on the relevant port number through the site to site gateway.

                      A firewall rule forwards nothing. It may only permit a traffic.
                      Furthermore, why on LAN? In your first post you wrote you want to forward internet traffic over the VPN. 🤔

                      @SeaMonkey said in Tunnelling a Service Through Site-to-Site Out to Internet:

                      I duplicated this rule on 'the SITE2SITE interface.

                      Guessing this is site 2, where the destination server resides.
                      The rule you set here can only direct traffic initiated by the server over the VPN, but not responses. So with the given port, it will make no sense at all.

                      @SeaMonkey said in Tunnelling a Service Through Site-to-Site Out to Internet:

                      Monitoring the LAN interface, the response traffic is making it there, but isn't seen by the SITE2SITE interface.

                      As mentioned above, that should work if your vpn interface is set correctly. The routing is controlled inside pfSense by the reply-to flag.

                      Post the Status > interfaces tab and the routing table of site 2. Maybe there is something wrong.

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by

                        The reply-to needs to be on the side with the server. Site B.

                        Policy routing out SITETOSITE is not going to accomplish anything because that is for connections being established out that way, not reply traffic for connections coming in.

                        Nobody said anything about setting up policy routing.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

                          Perhaps I've done a poor job of explaining what I'm trying to accomplish. Sorry about that and thank you for your patience and assistance.

                          Internet Traffic bound for PIAPORT on -> PIA_OVPN_PF address at SiteA -> SITE2SITE -> SiteB ->Server conected to SiteB LAN with service on PIAPORT

                          To get traffic successfully going to the server, all I had to do from my existing setup was create this port forward rule at SiteA.

                          portforward.png

                          Creating the appropriate rules to direct the return traffic back along the same path is where I'm getting mixed up.

                          1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate
                            last edited by Derelict

                            @SeaMonkey said in Tunnelling a Service Through Site-to-Site Out to Internet:

                            SITE2SITE -> SiteB ->Server conected to SiteB LAN with service on PIAPORT

                            The rules on The OpenVPN tab at Site B CANNOT pass traffic to destination 192.168.0.3:PIAport. Connections passed by rules on the openVPN tab WILL NOT get flagged with reply-to.

                            The traffic into Site B Must match rules on the assigned OpenVPN interface there. Connections passed by rules on an assigned interface WILL get flagged reply-to.

                            Really the best thing to do is delete or disable all the rules on the OpenVPN tab and place the rules passing traffic from openVPN into Site B on the assigned interface tab(s).

                            Chattanooga, Tennessee, USA
                            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

                            1 Reply Last reply Reply Quote 1
                            • S
                              SeaMonkey
                              last edited by

                              I'm nervous about removing the auto-created rule on the OpenVPN tab, as I'm worried I'll end up unintentionally breaking other VPN connectivity. Since the only rule currently on the OpenVPN tab at both sides was auto-generated by the OpenVPN Remote Access wizard, would a good/safe strategy be to assign an interface to the Remote Access VPN Server at each site (currently, neither one is) and create a similar 'allow all' rule on both? Can I reasonably assume that no other VPN traffic would be impacted by the removal of the auto-created rule on the OpenVPN tab?

                              1 Reply Last reply Reply Quote 0
                              • DerelictD
                                Derelict LAYER 8 Netgate
                                last edited by

                                Yes. If you assigned an interface to the remote access server and moved all of the rules on the OpenVPN tab to that interface you would be in good shape.

                                That is a solid strategy when you require special behavior of assigned interface rules.

                                Chattanooga, Tennessee, USA
                                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                1 Reply Last reply Reply Quote 1
                                • S
                                  SeaMonkey
                                  last edited by

                                  I had to add an allow all rule to the SITE2SITE interface on both sides to get traffic there working properly again after removing the rule from the OpenVPN tab. I'm testing the REMOTEACCESS VPN now and it establishes the connection, but no traffic is working even though I assigned it an interface and added an allow all rule. I'm going to do some more investigating when I get home.

                                  1 Reply Last reply Reply Quote 0
                                  • DerelictD
                                    Derelict LAYER 8 Netgate
                                    last edited by

                                    You MUST restart an OpenVPN instance after assigning an interface. If you do not, no traffic will pass.

                                    Chattanooga, Tennessee, USA
                                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

                                    1 Reply Last reply Reply Quote 1
                                    • S
                                      SeaMonkey
                                      last edited by

                                      Heh... I kinda thought that might be the case. At least that one's an easy fix. Thanks again for all of your help!

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