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

    Shared NAT over OpenVPN

    Scheduled Pinned Locked Moved OpenVPN
    2 Posts 2 Posters 2.3k 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.
    • T
      toomeek
      last edited by

      Hello forum,

      I'm moving from old physical Debian i386-based server running @ IBM hardware to brand new HP Proliant with pfSense as KVM.
      I have such setup on another floor (running pfSense as KVM i386, shaping ~70Mbit very well). However, I have some problems to move OpenVPN configuration from old Debian to pfSense.
      I did it once with full success, so it's very strange why it isn't working this time.

      Schematics:

      • working config is:
        WAN -> HP Proliant G6 -> KVM i386 pfSense node1 (VPN client) -> encrypted channel over OpenVPN (ISP LAN) -> Debian i386 (VPN server) -> users
      • and I'm going to reach this:
        WAN -> HP Proliant G6 -> KVM i386 pfSense node1 (VPN client) -> encrypted channel over OpenVPN (ISP LAN) -> KVM pfSense node2 (VPN server) -> HP Proliant G7 -> users

      It failed with amd64 as second pfSense node (I was trying something new, since I never depoloyed amd64 pfSense yet).
      OpenVPN error messages said successfully connected, but I'm unable to add route via OpenVPN interfaces default gateway.

      So what I'm trying to do is:

      • set up OpenVPN server (pfSense node2)
      • add certificates from old server (node2)
      • set encryption same as client (node2)
      • add virtual interface interface in node2 (it doesn't bring up on boot! so it's failing here). Tried both: dynamic IP or static, both methods failed.
      • start the server (it's starting)
      • add default route via VPN (saying it's not reachable)
      • huge delay on boot node2 since default gateway is not reachable.

      Any ideas how to solve this? Right now I'm starting over again..

      UPDATE: ok, I've replaced /var/etc/openvpn/server1.conf file to match config I'm using, however it's overwritten on every boot and also doesn't match pfSense standard.

      Is there any how-to for WAN sharing over site-to-site VPN?

      UPDATE:
      ok I've compared both confings. In old config there are:

      local x.x.x.x
      remote x.x.x.x
      float
      ifconfig IP_VPN1 IP_VPN2
      route <remote_ip_network><local_netmask></local_netmask></remote_ip_network> 
      

      However, pfSense adds:

      [b]server x.x.x.x[/b]
      ifconfig IP_VPN1 IP_VPN2
      local x.x.x.x
      

      "server" statement, which is huge difference, since it sets OpenVPN server mode.

      How to remove "server" statement from there?
      dhcp.png
      dhcp.png_thumb
      gw-static.png
      gw-static.png_thumb

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

        Hi TooMeek,

        Unfortunately the "Tunnel Network" field cannot be left blank and will always result in the server directive. This directive expands into:

        **mode server
        tls-server
        push "topology [topology]"

        if dev tun AND (topology == net30 OR topology == p2p):
          ifconfig 10.8.0.1 10.8.0.2
          if !nopool:
            ifconfig-pool 10.8.0.4 10.8.0.251
          route 10.8.0.0 255.255.255.0
          if client-to-client:
            push "route 10.8.0.0 255.255.255.0"
          else if topology == net30:
            push "route 10.8.0.1"

        if dev tap OR (dev tun AND topology == subnet):
          ifconfig 10.8.0.1 255.255.255.0
          if !nopool:
            ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
          push "route-gateway 10.8.0.1"**

        Given your setup that would result in an ifconfig directive that wronly sets the ip address. As a workaround for p2p mode I have found the following solution:
        -Add the ifconfig-noexec directive to the advanced settings.
        -Assign your OpenVPN interface.
        -Manually give it the correct static configuration.

        Now, whenever OpenVPN starts, the wrongly generated ifconfig directive will no longer override your static settings. Et voila, you can configure it however you want. I do the same for routes. I remove any routes in OpenVPN itself, and just manually add routes to gateways set on the other side of my links. This also has the nice side effect of detecting a downed VPN by looking at the remote subnet's gateway status in the dashboard.

        However, what I have not tackled yet is how to get this working in Remote Access mode. Apparently OpenVPN wrongly routes the .1 of my "Tunnel Network" despite my configured interface values. My guess is this happens because, although the OS is set correctly, OpenVPN itself doesn't know that the automatically assigned .1 server address is no longer in use. In p2p (site2site) setups this is no problem. It just always sends everything to the other side. However, in Remote Access mode (in OpenVPN it's called "server mode") OpenVPN itself needs to know to which client to route what data. Hence all the new iroute directives. Obviously, overriding the server interface does not override OpenVPN its internal routing and thus keeps believing it's the .1 in the Tunnel Network.
        As the config file gets overridden on every reboot, I cannot see how we can currently use "topology mode" in combination with an alternative Tunnel Network server IP. Maybe someone knows how to use the field for extra directives to inhibit automatically configured directives? Or maybe we can prevent pfsense from overwriting a custom server1.conf file?
        If not, a nice feature request would be another OpenVPN server mode called "custom". With no fields other than the "Advanced config" field. This way we would be able to do any complex setup while interface adjustments (precious dev-time) remain minimal. Devs?

        Anyways, I hope this will help you. And let me know if you find other workarounds.
        Jori Huisman

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