How to troubleshoot Duplicate OpenVPN on Netgate router

Authored by: Support.com Tech Pro Team

1. Introduction

How to troubleshoot Duplicate OpenVPN on Netgate router

2. Resolution

This guide describes several troubleshooting techniques for OpenVPN, as well as common issues users encounter with OpenVPN along with their solutions.

Check OpenVPN Status

The first place to check is Status > OpenVPN, which displays the connection status for each OpenVPN instance.

If a VPN is connected, waiting, reconnecting, etc, it is indicated on that screen.

Check Firewall Log

If a VPN connection does not establish, or establishes but does not pass traffic, check the firewall logs under Status > System Logs on the Firewall tab.

If traffic for the tunnel itself is being blocked, such as traffic to the WAN IP address on port 1194, then adjust the WAN firewall rules accordingly.

If traffic is blocked on the OpenVPN interface, add rules to the OpenVPN tab (or assigned OpenVPN interface tab, if present) to allow traffic there.

Some hosts work, but not all

If traffic between some hosts functions over OpenVPN, but some hosts do not, this is commonly one of four things:

Firewall rules

Ensure the rules in the firewall GUI on both sides allow the desired network traffic. This may be on the OpenVPN tab in Firewall > Rules or an assigned OpenVPN interface tab.

Missing, incorrect, or ignored default gateway

If the host that cannot be reached across the VPN does not have a default gateway or has one pointing to something other than the firewall running OpenVPN, the host does not know how to properly get back to the remote network on the VPN.

Additionally, some devices, even with a default gateway specified, do not use that gateway. This has been seen on various embedded devices, including IP cameras and printers. In this case, there is no proper firewall-based solution. The software on the device must be fixed.

This behavior can be verified by running a packet capture on the inside interface of the firewall connected to the network containing the host. If the packet capture contains traffic leaving the inside interface on the firewall, but not replies to that traffic, the device is not properly routing its reply traffic or potentially blocking it via the local firewall on the device.

Incorrect subnet mask

If the subnet in use on one end is 10.0.0.0/24 and the other is 10.254.0.0/24, and a host has an incorrect subnet mask of 255.0.0.0 or /8, it will never be able to communicate across the VPN because it thinks the remote VPN subnet is part of the local network, and hence routing will not function properly.

Fix the incorrect subnet mask and then two-way communication is possible.

Host firewall

If there is a firewall on the target host, it may not be allowing the connections. The Windows firewall, for example, will not allow connections from outside of its local subnet in certain configurations.

Check the OpenVPN logs

The OpenVPN logs contain details about the OpenVPN processes, including log messages relating to connection attempts, remote access login records, and other related messages. These logs are in the GUI under Status > System Logs, OpenVPN tab.

When an OpenVPN instance connects it will log messages similar to the following:

openvpn[32194]: UDPv4 link remote: 1.2.3.4:1194openvpn[32194]: Peer Connection Initiated with 192.168.110.2:1194openvpn[32194]: Initialization Sequence Completed

The number following openvpn will differ, it is the process ID of the OpenVPN process handling the connection. 

If the link remote and Peer Connection Initialized messages are not shown when trying to connect, the cause is likely either incorrect client configuration, so the client is not attempting to connect to the correct server, or incorrect firewall rules blocking the client’s connection.

Overlapping IPsec connections

The way IPsec configures security policies in the kernel, any enabled IPsec connection matching the local and remote subnet pairs will restrict the firewall to only passing traffic for that pair through IPsec. The traffic will not pass through any other interface, including OpenVPN. Disable any IPsec connections which specify the same local and remote networks as another VPN.

If an IPsec tunnel has been recently disabled or removed, check if the security policy database (SPD) entries are still present at Status > IPsec on the SPD tab.

If the SPD entries for a disabled tunnel are still active, stop the IPsec daemon and then start it again.

Check the system routing table

Browse to Diagnostics > Routes and review the contents of the routing table. For site-to-site VPNs, routes will be present for the remote network(s) to the appropriate tun or tap interface. If the routes are missing or incorrect, the Local Network, Remote Network, or custom options are not configured correctly.

If a peer-to-peer setup is in use (shared key or SSL/TLS with /30 tunnel network) and not client/server, ensure that the custom options do not contain any “push” commands. In a peer-to-peer setup, the peers cannot push settings to each other. Both sides must contain appropriate remote network configurations.

Test from different vantage points

If the connection appears to be up according to the logs, but it does not work from a host on the LAN, try it from the firewall itself. These tests may be easily performed by the Diagnostics > Ping page in the GUI.

The first test using the inside interface involved handling OpenVPN internal traffic as the ping source. This is typically the LAN interface. If that does not work, try again using the default source address so that the firewall will source the ping from the OpenVPN interface itself.

If the default source ping works but the internal network ping does not check the firewall rules and routes on the far side.

Trace the traffic with packet captures

Using packet captures to determine traffic flow is one of the most helpful troubleshooting techniques.

Start with the internal interface (commonly LAN) on the side where hosts initiate the traffic. Next, progress to the tun interface on that firewall, then the tun interface on the remote firewall. Finally, check the inside interface on the remote firewall. Determining which interfaces contain the traffic and which do not can help greatly in narrowing down the location of the problem.

Routes will not push a client

If a client does not receive routes for networks from the Local Network settings or a push the statement, a couple of things could be happening:

• Check that an SSL/TLS server setup is used with a Tunnel Network larger than a /30. The server the mode in OpenVPN only takes effect when using a subnet large enough to contain multiple clients, such as a /24.
• If the client is running on Windows 10 or similar, try running the client as Administrator. Some versions of the OpenVPN client require Administrator mode to apply routes to the client PC routing table.
• This should not be a factor on modern versions of the OpenVPN client for Windows, so another step is to uninstall the OpenVPN client on the end-user device and install the most current available client. 
• Peer-to-peer setups (shared key, SSL/TLS with a /30 tunnel network) are not capable of pushing routes. Use the Remote Network boxes or route statements on each side (both client and server) to direct traffic to subnets on the far end of the tunnel.

Why do multiple OpenVPN clients get the same IP address?

If all clients use the same certificate then OpenVPN will assign all clients the same IP address when they connect. To work around this, create separate certificates for each client, which is the best practice.

Another workaround is to check Duplicate Connections on the server configuration. This is a bad practice, however, as it is less secure than using unique certificates for each client.

Importing OpenVPN DH Parameters

When importing an existing OpenVPN setup into pfSense, there is no need to import DH Parameters. DH parameters are not specific to a given setup in the way that certificates or keys are.