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

    Site to Site OpenVPN Setup with a Debian System (as VPN Gateway)

    OpenVPN
    3
    12
    537
    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.
    • V
      viragomann @Bambos
      last edited by

      @Bambos said in Site to Site OpenVPN Setup with a Debian System (as VPN Gateway):

      What is the difference on pfSense for OpenVPN clients site to site and remote access clients ?

      There are no differences as far as I know, it's generally all just OpenVPN. Just the pfSense web GUI gives you different option to set.
      If you need to access a network behind a client you have to choose the peer to peer mode to get the option to state the remote networks.
      Additionally you have to configure a Client Specific Override for the respective client.

      What if we set a static IP through Radius Server for the OpenVPN client, and then create a network routing over the established tunnel ? Can the client IP be set as gateway for the remote network ?

      No, don't set static routes for remote networks you're accessing via VPN.

      The static IP can also be achieved with the CSO.

      The "remote networks" in the server setting add to routes to the pfSense routing table and point it to the VPN server. The CSO is needed then to set the routes inside OpenVPN.

      Can debian do both modes of OpenVPN Client ? site to site and remote access? or we have a limitation there ?
      Is there debian packages to support the needed functions ?? like OpenVPN Client site to site , or remote access, add virtual adapter, 1:1 translation from the virtual adapter to LAN (masquerade packets), add routing etc... ?

      Likewise in pfSense it's basically just OpenVPN in Debian. All differences are done in the configuration.

      In Debian you will have to enable routing to pass through the traffic.
      The masquerading is done in iptables then.

      P B 2 Replies Last reply Reply Quote 1
      • P
        Popolou @viragomann
        last edited by

        @viragomann said in Site to Site OpenVPN Setup with a Debian System (as VPN Gateway):

        If you need to access a network behind a client you have to choose the peer to peer mode to get the option to state the remote networks.

        Long ago we learnt this the hard way when we were troubleshooting why policy routing was failing to connect an external service through one network's WAN, across the tunnel to a server on another network and back again. The VPN server was originally set up for RA for its users. Changing modes to site-to-site allowed both roles to function as a workaround (but you obviously do not get access to openvpn-client-export anymore).

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

          @Popolou
          If you want to have the comfort of client export, as a workaround, I think, it should be possible to use the access server mode and assign an interface to it.
          Then you get the option to add static routes for client site networks and point it to the VPN server.
          CSOs are needed anyway in addition of course.

          1 Reply Last reply Reply Quote 1
          • B
            Bambos @viragomann
            last edited by Bambos

            @viragomann thanks a lot !
            i already have a site to site and routing up and running.

            now i'm messing with iptables (first time).

            what about client specific overrides ?? it seems that pfsense openvpn server has routing normally , the tunnel is ok, the gateway is ok.

            These settings below on client specific overrides, are also in the site to site vpn server config. What is the difference ?

            93aff973-0c7f-4326-82be-0e141ad71112-image.png

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

              @Bambos
              If you're using only a /30 tunnel network the CSO is superfluous.
              However, remember that this does not work with DCO and you can connect only a singe client to the server. Because of the former, it isn't recommended anymore, even for a peer to peer setup.

              B 2 Replies Last reply Reply Quote 0
              • B
                Bambos @viragomann
                last edited by

                @viragomann hello !! yes, a single client is ok, and is working like below:
                as i said the tunnel is ok and routing is ok, i can communicate with my client from pfsense openvpn server. (like a normal site to site). it doesn't seem that pfsense openvpn server configuration needs something more... my issue now is on the debian box to achieve routing and maybe masquerading to "device 30". final scope is to communicate with "device 30" over the tunnel and via debian box.
                i'm checking iptables, firewalld and nftables to see what is easier for my purpose. any guidance is much appreciated.

                This is what i have for now:

                49ad8297-0c5a-49cf-8316-24609a24096d-image.png

                1 Reply Last reply Reply Quote 0
                • B
                  Bambos @viragomann
                  last edited by

                  @viragomann Hello, and thank you for your useful comments as always. i had some progress with iptables gui on cockpit web gui management system on debian.

                  below i have a working setup on a pfsense openvpn client executing source NAT while outbounds any request to network 192.168.2.0/24 while having interface address 192.168.2.20/24.
                  like this is working, and this is what i need to replicate.

                  ca0e855e-338f-4a49-a2ce-41de9fe56cf2-image.png

                  what might be the iptables equivalent ? (ip tables man page is not noobie friendly at all)

                  There are 2 sections: Filter and NAT. Since i need to work on NAT, i have filter some rules to allow all, and setup the NAT.

                  On NAT there are Chains: input - output - prerouting - postrouting
                  do i need prerouting and postrouting ?
                  Masquerade seems to be accepted only on postrouting.
                  any suggestions on what might work there ?

                  possible options for NAT rules below:

                  6ee021c4-04f9-4934-9f92-b2c7fb864a3d-image.png

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

                    @Bambos
                    Why don't you ask a web search engine? I'm not as familiar with iptables, so I can't tell you.

                    But what you need, is called "masquerading" in iptables and it has to be done after the routing, hence it's a postrouting action.

                    Yes, it's the same as outbound NAT in pfSense, but iptables use other terms for it.

                    B 1 Reply Last reply Reply Quote 0
                    • B
                      Bambos @viragomann
                      last edited by

                      @viragomann thank you very much, i will dig into it.
                      i ask a web search engine for the last week, saw many tutorials, ask any linux support channel i could find... (forum, discord etc...) still without finding the exact suitable commands for this task.

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

                        @Bambos
                        The first hit:
                        Masquerading Made Simple HOWTO

                        Something like this should do the job.

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