Routing Internet Traffic Through A Site-To-Site OpenVPN Tunnel¶

This article shows how route Internet traffic from one site through a second site over OpenVPN on pfSense® software.

../_images/diagram-openvpn-s2s-route-internet.png

Design¶

In this scenario, the headquarters site will be the server and branch offices will be clients. The basic settings are identical to the Example Configuration Settings from the SSL/TLS recipe:

OpenVPN Endpoint Settings - Headquarters¶
Headquarters - Server
WAN Address	198.51.100.3
LAN Subnet	10.3.0.0/24
LAN Address	10.3.0.1
CA Name	S2SCA
Cert CN	serverA
Tunnel Net	10.3.101.0/24

OpenVPN Endpoint Settings - Branch Office¶
Branch Office - Client
Cert CN	clientB
WAN Address	203.0.113.5
LAN Subnet	10.5.0.0/24
LAN Address	10.5.0.1

OpenVPN Configuration¶

Setup the entire site-to-site VPN as detailed in OpenVPN Site-to-Site Configuration Example with SSL/TLS which will result in a usable base from which the remainder of the settings can be built. That example uses two remote offices, so only the first remote office is necessary here. Configure as many as the use case requires.

Configure outbound NAT¶

For clients at the remote office to reach the Internet through the headquarters, the headquarters site must perform outbound NAT on the traffic from the remote office LAN (10.5.0.0/24) as it leaves the WAN.

Note

While it is also possible to perform NAT on the client side firewall OpenVPN interface, that would negatively impact non-Internet VPN traffic and also results in double NAT for Internet traffic which can cause problems with certain protocols.

To setup outbound NAT on the headquarters firewall, first change the outbound NAT mode:

Navigate to Firewall > NAT, Outbound tab on the headquarters firewall
Set the Outbound NAT Mode to Hybrid Outbound NAT

Note

If the headquarters firewall is already on this mode or set to Manual, then do not change the mode.
Click Save

Using this mode allows the default automatic NAT rules to continue working without needing a full manual ruleset. Now add a custom rule to the top of the list which matches the remote office LAN:

Click Add
Set the following values:

Source:

Network, 10.5.0.0/24

Destination:

Any

Translation Address:

Interface Address

Description:

NAT for OpenVPN remote office
Click Save
Click Apply changes.

The new entry is now in the outbound NAT rule list.

Configure Client OpenVPN Gateway Behavior¶

The OpenVPN server can optionally instruct the client to send all of its Internet traffic over the VPN, including traffic from the client firewall itself. This can be convenient as it is less to configure, but it does not lend itself well to selective control over the traffic which crosses the VPN.

Note

If the use case only requires redirecting LAN client traffic via policy routing then skip this step.

To configure this:

Navigate to VPN > OpenVPN, Servers tab on the headquarters firewall
Edit the OpenVPN server instance
Check Redirect IPv4 Gateway
Click Save

Next time the client connects, OpenVPN will automatically set the default gateway for the firewall to the VPN server while it is connected.

Assign OpenVPN Interfaces¶

On the server and every client, assign this OpenVPN instance as an interface, following the procedure in Assigning OpenVPN Interfaces.

This will setup the necessary gateways and routing behavior which take care of some parts of the setup automatically. The gateways can be used for policy routing and failover to selectively handle client traffic in different ways.

Setup Gateway Groups¶

Note

This step is optional if the use case does not call for policy routing or failover.

Assigned OpenVPN interfaces automatically create gateways which can be used for gateway groups and policy routing. These are located under System > Routing.

Using one of these gateways a gateway group can enable several different types of scenarios:

Send client traffic over the VPN, allow it to exit the Internet directly if the VPN is down.
If there are multiple VPNs, client traffic could fail between them, or even load balance connections between them.
Failover between the VPN and other types of private circuits or higher cost connections if it fails.

Create a gateway group as described in Gateway Groups using whichever parameters best fit the use case.

OpenVPN Firewall Rules¶

Since this tunnel must pass traffic from the Internet, the firewall rules must be fairly lenient. The rules at the headquarters site will need to pass traffic from a source of the remote office LAN (10.5.0.0/24) to a destination of any.

These firewall rules should be placed on the assigned OpenVPN interface tab where possible, and not on the OpenVPN tab of the firewall rules. This helps ensure proper routing and return routing.

Tip

To prevent the remote office from reaching sensitive local resources at headquarters or sites connected to additional VPNs, place block rules for those sensitive destinations above the rule passing the Internet traffic.

The rules on the remote office firewall do not necessarily have to allow much traffic back through unless there are public resources at the remote office which must be reached across the tunnel (e.g. 1:1 NAT, port forwards).

Setup Policy Routing¶

Policy routing (Policy Routing Configuration) allows the firewall to selectively match and route client traffic over the VPN that otherwise would follow the default routing table when exiting the firewall. For example, firewall rules could match only HTTP and HTTPS traffic and send them across the VPN. The other traffic would exit the remote office Internet connection directly.

This gives firewall administrators fine-grained control over traffic flow, rather than directly all traffic over the VPN. The downside is that it doesn’t control traffic from the firewall itself, only traffic coming from other interfaces on the firewall.

Note

These policy routing rules go on the local interfaces which contain the clients that initiate traffic, such as LAN. They do not go on VPN interfaces.

In this example, the firewall will route all traffic from hosts on the LAN across the VPN:

Navigate to Firewall Rules, LAN tab on the remote office firewall
Edit the default rule which matches LAN traffic (e.g. Default allow LAN to any rule)
Click Display Advanced
Set the Gateway to the assigned OpenVPN interface gateway, or a suitable gateway group.
Click Save
Click Apply Changes

Note

If this rule is set to both IPv4 and IPv6, this change may not work. Duplicate the rule and set one to only IPv4 and one to only IPv6, then set appropriate gateways on each as needed.

Test the Configuration¶

From this point, new connections made from the remote office LAN will be sent over the VPN. Open a site to check the client IP address, such as doing a Google search for what is my ip address. The result should be the WAN IP address of the headquarters firewall.

If it is not, then check the LAN firewall rules, the headquarters OpenVPN firewall rules, and the headquarters outbound NAT rules.

Bonus Topics¶

Adding More Clients¶

The example in OpenVPN Site-to-Site Configuration Example with SSL/TLS already shows how to accommodate multiple clients, but for this type of setup it takes a couple more steps:

On the headquarters firewall, add more outbound NAT rules to cover the new client LAN subnets.
On the headquarters firewall, ensure the OpenVPN interface firewall rules allow traffic from the new client LAN subnets.
On the remote office firewall, assign the OpenVPN interface.

Since there is only one server, there is no need to do this again on the headquarters firewall.
On the remote office firewall, setup gateway groups and policy routing.

Note

This assumes the setup was based on SSL/TLS in client/server mode. If the setup used a /30 tunnel network, that will require an additional server and an additional interface assignment at headquarters.

Port Forwarding or 1:1 NAT to hosts at the Remote Office¶

It is possible to forward traffic initiated by hosts on the Internet to a server at the remote office in a couple different ways. This can be useful, for example, if a server was relocated but there are still outdated DNS records or links pointing to the old location.

This can work in one of two ways:

If the client gateway is redirected using the OpenVPN server option, there is no need for additional configuration. Add the port forwards or 1:1 NAT and it will work as-is.
If the OpenVPN interfaces are assigned, this can work by allowing the reply-to keyword in pf to handle return routing. The remainder of this section covers this process.

For the reply-to method to work, a few points must be followed:

The OpenVPN interface on the remote office must be assigned
The firewall rules on the OpenVPN tab at the remote office must not match this traffic
The firewall rules on the assigned OpenVPN interface tab must match this traffic

With the appropriate configuration in place on the remote office firewall, then port forwards or 1:1 NAT on the headquarters site can be set to a destination on the remote office LAN.