Access remote networks with a site to site VPN – Part 2

In part 1, we setup the infrastructure to get our VPN tunnel going. Now, we’ll go through actually setting up the tunnel itself.

OpenVPN setup – Server

Although the tunnel will be bidirectional, we still need to setup a server <-> type setup. If you ever need to add a new network in the future, you just need to do the client setup again, not the server. The only thing on the server you’ll need to adjust are the routes

Using the top menu, navigate to VPN -> OpenVPN. Then select the “servers” tab. Click the green “Add+” button. You should end up on a page similar to the one below:

A lot of the settings can be left at their default values. You’ll want to go through and make sure the following are as follows:

Server mode: “Peer to Peer (SSL/TLS)

Device mode: “tun – Layer 3 Tunnel Mode”

Interface: “Wan”

Description: “If you have multiple VPN servers, you may want to put a description here”

TLS Configuration: “Checked – Use a TLS Key”

Automatically generate a TLS key: Checked

If you want to change the cipher settings, feel free to do so. You’ll need to make sure the settings match on both ends, however.

IPv4 Tunnel Network: This needs to be a subnet that is used solely by the VPN to hand out IP addresses to clients. Use a subnet that is not overlapped by either of your remote network subnets. I use 10.0.8.0/24.

IPv4 Remote network(s): This should be a comma delimited list of the subnets that are on remote networks. For example, if you’re setting up the server on the 10.0.2.0/24 network, the Remote networks would be 10.0.0.0/24 (at least for our example). Should you add more subnets or clients down the road, you will need to update this setting with the new information

Scroll down to the bottom of the page and click the blue “Save” button.

OpenVPN setup – client

We’ll now setup a client. Log into the web interface of your 2nd virtual machine and navigate to VPN -> OpenVPN. Then select the “Clients” tab and the green “Add+” button.

Most of the settings will be the same as the server setup, with a few exceptions.

Server mode: “Peer to Peer (SSL/TLS)

Device mode: “tun – Layer 3 Tunnel Mode”

Interface: “Wan”

Server or host address: This will be the IP address or DNS hostname of your OPENVPN server. Make sure this is an IP address we can ping and reach. If both pfsense installations are behind NAT, you’ll need to forward UDP traffic for port 1194 through the router and to the OpenVPN server virtual machine

Automatically generate a shared key: Unchecked

Shared Key: Open up your OpenVPN server again and edit the config. If you scroll down to the same part of the page, you’ll see the auto generated shared key. Copy and paste this into the clients “Shared Key” box. These need to match exactly

Ensure that all the cryptographic settings match if you changed any previously.

IPv4 Tunnel Network: This needs to match what you used for the server. I used 10.0.8.0/24

IPv4 Remote Networks: This is flip flopped from before. Input the subnet of the remote network. In our example, it’ll be either 10.0.2.0/24 or 10.0.0.0/24.

Scroll all the way down and hit the blue “Save” button.

Test the connection

Let’s make sure that the two pfsense installations can ping each other over the tunnel. You can use the pfsense tools to ping the LAN IP of the remote server:

Looks good. If you cant ping the other end of the VPN, you’ll want to double check your OpenVPN settings. Also check to see if there are any firewalls that may be sitting in your way.

The nice part about pfsense is that it’ll automatically setup the required routes on the VM itself. However, other clients on either network need to be aware of the tunnel, as they probably have another gateway for most traffic.

In my lab, I have an EdgeRouter Lite acting as the default gateway, so we need to setup a route there. Something like the following should work:

Make sure that the Destination network is the subnet of the remote network, and that the Next hop address is the non-DHCP IP address of the local pfsense installation. Consult the documentation for your particular router if needed.

After setting up routes on both networks as needed, other clients on those networks should be able to travel through. Test from any computer or machine:

[root]@[ce6test]-15:37-~ : ping -c 1 10.0.2.1
PING 10.0.2.1 (10.0.2.1) 56(84) bytes of data.
64 bytes from 10.0.2.1: icmp_seq=1 ttl=64 time=4.97 ms

--- 10.0.2.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 4.979/4.979/4.979/0.000 ms

Awesome. Now, can we ping a host on the remote network, past the gateway? 10.0.2.2 is a virtual machine on the other subnet:

[root]@[ce6test]-15:37-~ : ping -c 1 10.0.2.2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=62 time=33.1 ms

--- 10.0.2.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 33ms
rtt min/avg/max/mdev = 33.112/33.112/33.112/0.000 ms

Now lets make sure we can go back the other direction:

[root]@[web2]-15:42-~ : ping -c 1 10.0.0.200
PING 10.0.0.200 (10.0.0.200) 56(84) bytes of data.
64 bytes from 10.0.0.200: icmp_seq=1 ttl=61 time=25.5 ms

--- 10.0.0.200 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 25.593/25.593/25.593/0.000 ms

If you’re able to go one direction but not the other, you’ll want to double check on the static routes you setup.

Gotchas

A couple things can catch you off guard. Below are a few things I have ran into setting this up.

  • If you’re able to go one direction but not the other, you’ll want to double check on the static routes you setup.
  • If you use the router to resolve DNS for DHCP hostnames, you wont be able to do this for machines on the remote subnets. You’ll either need to do some fancy DNS server magic, or setup a zone file for your local network and setup DNS names there.
  • If you’re not sure whether or not traffic is actually going through the tunnel, check the RTA. The pings will be significantly higher if they’re properly reaching hosts on the remote networks than if you were to ping something within the same LAN.

Conclusion

Now that you’ve got two remote networks connected, you can access both as if they were one. Albeit, latency to the remote network will be higher.

If you have data you want to transmit securely across them (logging pipe lines, unsecured http requests, etc) You can use this vpn to make sure they are encrypted as they are transmitted between the two networks.

Another thing to note is that DHCP by default will not reach across to other networks for offers or requests. This should prevent remote machines from picking up an IP address on a different subnet.

Did this setup work for you? If not, feel free to leave a comment below letting me know where you’re stuck.

Leave a Reply

Your email address will not be published. Required fields are marked *