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

    Connect two OpenVPNs

    OpenVPN
    3
    5
    3.0k
    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.
    • D
      decibel83
      last edited by

      Hi.

      I have two remote sites (site-A and site-B), and I connected them with a Site-To-Site OpenVPN with two pfSense systems: site-A can reach site-B and viceversa.
      I also created an OpenVPN server on site-A, and road-warrior clients can connect to it and reach its LAN network, but they cannot acces to the site-B network.

      I configured push "route 192.168.40.0 255.255.255.0"; in advanced configuration on the road-warrior OpenVPN server and I accepted all traffic from OpenVPN to any destination for any protocol in the firewall rules on site-A, but it doesn't work.

      Could you help me, please?

      Thank you very much!
      Bye.

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        You also need to tell site-B how to route back to the Road Warrior subnet.
        On  the OpenVPN end at site-B, in the OpenVPN link advanced box, something like:

        route 192.168.99.0 255.255.255.0

        (substitute your Road Warrior subnet for 192.168.99.0 of course)
        And you will need to allow traffic from the Road Warrior subnet into the OpenVPN on the site-B firewall (I guess you already have a broad rule there also).

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

        1 Reply Last reply Reply Quote 0
        • J
          jasond
          last edited by

          @phil.davis:

          You also need to tell site-B how to route back to the Road Warrior subnet.
          On  the OpenVPN end at site-B, in the OpenVPN link advanced box, something like:

          route 192.168.99.0 255.255.255.0

          (substitute your Road Warrior subnet for 192.168.99.0 of course)
          And you will need to allow traffic from the Road Warrior subnet into the OpenVPN on the site-B firewall (I guess you already have a broad rule there also).

          Hi Phil, I have an almost similar setup/problem but I'm unsure if your suggestion to decibel83 applies.

          Setup:
          Our office LAN (192.168.168.0/24) is connected to internet with pfsense2 machine on a pppoe link.
          Our datacenter DMZ (10.0.0.0/8)  is connected to internet with pfsense2 machine.

          Between these two site we run a site-site openvpn link, tunnelled on 172.42.42.0/24. LAN side runs as openvpn client.
          All LAN –> DMZ traffic is allowed, DMZ --> LAN traffic is blocked aside from the obvious replies to LAN initiated connections. This openvpn link works well, users within the LAN can ping and connect to hosts within the DMZ.

          Problem:
          Now we have an additional openvpn server running on office (LAN) pfsense2 machine tunnelled on 172.242.242.0/24. Remote clients are able to connect and can ping and connect to hosts within the LAN (192.168.168.0/24)  but no traffic seems to get to DMZ (10.0.0.0/8).

          The LAN openvpn server is configured to push "route 10.0.0.0 255.0.0.0"; and remote clients are respecting that setting i.e. routing 10.0.0.0/8 via tunnel gateway (as per LAN destined traffic).

          Packet capture shows traffic travelling from remote client to DMZ pfsense2 e.g.
          15:53:01.790333 IP 172.242.242.6 > 10.168.17.31: ICMP echo request, id 38735, seq 0, length 64
          15:53:20.062479 IP 172.242.242.6.49852 > 10.168.17.31.22: tcp 0

          But there are no response packet travelling in other direction and nothing show up in the firewall logs.

          I added a setting push "route 172.242.242.0/8"; to server config which had no effect. Given that the DMZ side of the site-site vpn is the server, how do I 'push' a route to allow response traffic to 172.242.242.0/8 ?

          Feel free to whack me with the clue stick!

          thanks

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            The DMZ OpenVPN Server end will need rules to allow traffic in from 172.242.242.0/24 - if the existing pass rules on OpenVPN are not wide enough already, then add one.
            In the DMS OpenVPN Server Advanced box, you can just tell it routes, no need to "push" them from the other end. e.g.

            route 172.242.242.0 255.255.255.0

            This tells the server end that the OpenVPN link is the next hop for reaching 172.242.242.0/24
            From your description, I think that is all that is needed - allow the packets into the DMZ pfSense from across the OpenVPN, then give the DMZ pfSense knowledge about how to route the responses back.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • J
              jasond
              last edited by

              @phil.davis:

              The DMZ OpenVPN Server end will need rules to allow traffic in from 172.242.242.0/24 - if the existing pass rules on OpenVPN are not wide enough already, then add one.
              In the DMS OpenVPN Server Advanced box, you can just tell it routes, no need to "push" them from the other end. e.g.

              route 172.242.242.0 255.255.255.0

              This tells the server end that the OpenVPN link is the next hop for reaching 172.242.242.0/24
              From your description, I think that is all that is needed - allow the packets into the DMZ pfSense from across the OpenVPN, then give the DMZ pfSense knowledge about how to route the responses back.

              That did the trick!

              thanks  ;D

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