Struggling with OpenVPN Site-to-Site Routes



  • I have two sites running pfSense routers:

    HQ: subnet 10.0.0.1/24

    Remote: subnet 10.0.3.1/24

    I am trying to setup an OpenVPN site-to-site tunnel between them which will allow clients at Remote to access the HQ network, and clients at HQ to access the Remote network. Traffic not meant for the local subnets should go out over each site's normal WAN connection, not the VPN.

    I have followed this guide: https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site

    I have successfully setup the OpenVPN tunnel. HQ is the server, Remote is the client. I am using 10.0.16.0/24 as the tunnel network. If I visit Status > OpenVPN at either end I can see the connection is up with a small amount of traffic passing between them.

    However, the guide ends at this point. It seems to imply that as soon as the connection is established, all outbound traffic from the client (Remote) will automatically pass through the VPN to the server (HQ). A traceroute performed on a machine connected to the Remote LAN shows that is clearly not the case.

    Here is a screenshot of the OpenVPN server config at HQ: https://i.imgur.com/v35CxdI.png

    Here is a screenshot of the OpenVPN client config at Remote: https://i.imgur.com/G0uwfve.png

    Here is a screenshot of the OpenVPN status from Remote: https://i.imgur.com/ZXi2xrp.png

    (I have removed the key and remote host IP from the screenshots.)

    On the server at HQ I have setup a rule at Firewall > Rules > WAN to allow IPv4 UDP traffic destined for the WAN address on port 1190. On the server at HQ at Firewall > Rules > OpenVPN I have a rule to allow all IPv4 traffic (any protocol, any source, any destination, any port).

    On the client at Remote I have setup a rule at Firewall > Rules > OpenVPN to allow all IPv4 traffic (any protocol, any source, any destination, any port).

    I thought to keep things simple I would first try to route all traffic from the client Remote to the server HQ. On the client at Remote I assigned the new ovpnc1 port to an interface and enabled it. This created a gateway for the connection. Then on the client at Firewall > Rules > LAN I created a new rule at the top to catch all IPv4 traffic (any protocol, any source, any destination, any port) and route it through the gateway created by the VPN interface. After applying that rule, machines that were connected to the LAN at Remote were unable to access the internet. I saw packets being caught by the rule, but apparently the gateway is not functional.

    So I am unsure how I can get any traffic to go over the VPN connection. I need to know what comes after the above linked OpenVPN Site To Site guide to actually use the established connection.



  • One of the machines connected to the LAN at HQ is 10.0.0.15.

    On pfSense at Remote, I can try to ping 10.0.0.15 at Diagnostics > Ping. This is successful if I set the source address to either the VPN interface or the OpenVPN Client. However, it fails if I set the source address to the LAN interface.

    So it seems like the VPN is fine, but it just does not know how to route traffic to the HQ subnet from the LAN.

    Here is a screenshot of Diagnostics > Routes on the Remote pfSense: https://i.imgur.com/BpOG1fD.png

    I have blacked out public IPs and the IPv6 stuff.



  • @tblesmrts:

    This created a gateway for the connection. Then on the client at Firewall > Rules > LAN I created a new rule at the top to catch all IPv4 traffic (any protocol, any source, any destination, any port) and route it through the gateway created by the VPN interface. After applying that rule, machines that were connected to the LAN at Remote were unable to access the internet. I saw packets being caught by the rule, but apparently the gateway is not functional.

    With that rule you force any traffic from LAN to the vpn server. For your intention there is no policy routing necessary.

    Both pfSense boxes, server and client, have to be the default gateways in their networks.

    In the servers OpenVPN settings change the tunnel network to a /30. Since it is a site to site, that's sufficient.
    In the client settings delete the tunnel subnet. It's set by the server.


  • Netgate

    On the client at Remote I assigned the new ovpnc1 port to an interface and enabled it. This created a gateway for the connection. Then on the client at Firewall > Rules > LAN I created a new rule at the top to catch all IPv4 traffic (any protocol, any source, any destination, any port) and route it through the gateway created by the VPN interface.

    This is completely unnecessary and only serves to introduce policy routing into your environment, causing other effects and complexity that are fine if you understand them, but you do not (yet).

    I would delete any assigned interfaces to OpenVPN servers/clients, put the pass any any any rules on the OpenVPN tabs, and stop/start OpenVPN on both sides.

    Another thing that I see is networks are not 10.0.0.1/24 or 10.0.3.1/24. They are 10.0.0.0/24 or 10.0.3.0/24. It looks like the proper routes are being added by OpenVPN but when I look at it I tweak a little.

    Work one hop at a time. For instance, from host 10.0.0.X can you ping the pfsense interface address on the other side? Presuming 10.0.3.1. If you can, all the routing is in place.
    After that, can 10.0.0.X ping something on the 10.0.3.0/24 LAN? Be sure the target of the pings:
        Has pfSense set as its default gateway
        Will actually respond to pings
        Does not have some local firewall (think windows firewall) preventing it from accepting traffic from foreign subnets

    Then do the reverse:

    Work one hop at a time. For instance, from host 10.0.3.X can you ping the pfsense interface address on the other side? Presuming 10.0.0.1. If you can, all the routing is in place.
    After that, can 10.0.3.X ping something on the 10.0.0.0/24 LAN? Be sure the target of the pings:
        Has pfSense set as its default gateway
        Will actually respond to pings
        Does not have some local firewall (think windows firewall) preventing it from accepting traffic from foreign subnets

    ETA: Since it is shared-key the tunnel network will be treated as a /30 anyway….