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

    OpenVPN SSL/TLS with WAN routing to other site

    OpenVPN
    2
    5
    688
    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
      depam
      last edited by

      Hi,

      Since the announcement of shared key deprecation of OpenVPN, I am trying to move away and set SSL/TLS for my other tunnels (creating new SSL/TLS and slowly decommissioning the old shared key). I am having difficulty setting it up now. My understanding is only the security is affected having more secure PKI approach method but it seems to me the functionality isn't the same when i tried it.

      My goal:

      1.) Establish a SSL/TLS OpenVPN between server and clients but the main purpose is to be able for Site A networks (Server) to route WAN traffic to client connected tunnel OpenVPN. This works seamlessly on Shared-key mode. With my current setup not specfying remote and local networks and using Policy routing Site A side and allowing tunnel address on client side to WAN.
      2.) If my client side wants to reach network on the server side, I have setup a wireguard (outside of PFSense) and natted it to one of my servers where I control access via policy routing.

      I have followed the instruction from https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html
      However, it seems not as easy as the Shared key approach that i have now. The problem I am getting on SSL/TLS setup is that I don't get to have a gateway address and thus even if i add the interface and gateway around it, it would not let me do policy routing of WAN connections thru the gateway.

      Appreciate if someone have any idea. Thanks in advance.

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

        @depam said in OpenVPN SSL/TLS with WAN routing to other site:

        1.) Establish a SSL/TLS OpenVPN between server and clients but the main purpose is to be able for Site A networks (Server) to route WAN traffic to client connected tunnel OpenVPN. This works seamlessly on Shared-key mode. With my current setup not specfying remote and local networks and using Policy routing Site A side and allowing tunnel address on client side to WAN.

        Are you talking about IPv6 traffic? Otherwise policy routing of WAN traffic to the remote site makes no sense.

        2.) If my client side wants to reach network on the server side, I have setup a wireguard (outside of PFSense) and natted it to one of my servers where I control access via policy routing.

        Why not on pfSense?
        Why don't you pass the traffic over the existing VPN?

        D 1 Reply Last reply Reply Quote 0
        • D
          depam @viragomann
          last edited by

          @viragomann Thanks for your inputs
          We need to pass traffic to remote site cause some endpoints the client is trying to access is whitelisted on that geographical location. We need to have an ability for site to use the outbound NAT on the other side to reach a specific endpoint

          We are working on moving those wireguard tunnels on pfsense since PFsense initially did not support wireguard from the start, we already created such on other appliance and we are just NATting it there.

          For this purpose, i think wireguard could only route an allowed-ip for all from server side but i can't find a way to be able to do that the other way around which is working for me in OVPN

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

            @depam said in OpenVPN SSL/TLS with WAN routing to other site:

            We need to pass traffic to remote site cause some endpoints the client is trying to access is whitelisted on that geographical location. We need to have an ability for site to use the outbound NAT on the other side to reach a specific endpoint

            Should work if you obey some things below:

            On the server

            • Give the tunnel network a /30 mask.

            • Enter the client side LAN or even the subnet of the destination server into the "Remote Networks" box.

            • Forward the traffic you want normally by stating the IP of the destination host on clients side as redirect target.

            On the client

            • Enter the server side LANs into the "Remote Networks" box.

            • Assign an interface to the OpenVPN client instance (e.g. ovpnc1) and enable it if you didn't this already.

            • Ensure that there is no pass rule on the OpenVPN tab and also no floating pass rule matching the forwarded traffic from the remote site. Remove the default pass any to any rule.
              Add a pass rule for this to the clients VPN interface instead.
              If you're running multiple OpenVPN instances on the client site, it would be easier to assign an interface to each for the respective rule and leave the OpenVPN tab blank.

            If you also want to policy route traffic from the server site to the client, assign an interface to the server instance as well. So you get a gateway, which you can use for policy routing.

            D 1 Reply Last reply Reply Quote 0
            • D
              depam @viragomann
              last edited by

              @viragomann Thanks for the advise. It worked finally. I just have a bit of doubt. After I created /30 and not added any remote networks, the server could not get an IP. It was fixed by adding remote IP on both ends which is strange cause if I only want to allow outbound IP without any inter-private routing, i don't need to specify it. This worked for shared-key setup but not on SSL/TLS.

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