If problems are encountered when trying to use OpenVPN, consult this section for information on troubleshooting common issues.
Check OpenVPN Status¶
The first place to look is Status > OpenVPN. The connection status for each VPN is shown there. If a VPN is connected, waiting, reconnecting, etc, it would be indicated on that screen. For more information, see Checking the Status of OpenVPN Clients and Servers.
Check Firewall Log¶
If a VPN connection does not establish, or does establish 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 to allow traffic there.
Some hosts work, but not all¶
If traffic between some hosts over the VPN functions properly, but some hosts do not, this is commonly one of four things.
- Missing, incorrect or ignored default gateway
If the device does not have a default gateway, or has one pointing to something other than pfSense®, it does not know how to properly get back to the remote network on the VPN. 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 some printers. There isn’t anything that can be done about that other than getting the software on the device fixed. This can be verified by running a packet capture on the inside interface of the firewall connected to the network containing the device. Troubleshooting with tcpdump is covered in Using tcpdump from the command line. If traffic is observed leaving the inside interface on the firewall, but no replies come back, the device is not properly routing its reply traffic or potentially blocking it via local firewall on the device.
- Incorrect subnet mask
If the subnet in use on one end is
10.0.0.0/24and the other is
10.254.0.0/24, and a host has an incorrect subnet mask of
/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.
- Host firewall
If there is a firewall on the target host, it may not be allowing the connections.
- Firewall rules on pfSense
Ensure the rules on both ends allow the desired network traffic.
Check the OpenVPN logs¶
Browse to Status > System Logs and click the OpenVPN tab to view the OpenVPN logs. Upon connecting, OpenVPN will log messages similar to the following example:
openvpn: UDPv4 link remote: 188.8.131.52:1194 openvpn: Peer Connection Initiated with 192.168.110.2:1194 openvpn: Initialization Sequence Completed
The number following
openvpn will differ, it is the process ID of
the OpenVPN process making 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.
Ensure no overlapping IPsec connections¶
Because of the way IPsec ties into the FreeBSD kernel, any enabled IPsec connection matching the local and remote subnets that exists when IPsec is enabled (even if it is not up) will cause that traffic to never be routed across the OpenVPN connection. Any IPsec connections specifying the same local and remote networks must be disabled. If an IPsec tunnel has been recently disabled or removed, check that its SPD entries have been removed by looking at Status > IPsec on the SPD tab. If they are present, remove them from that screen.
Check the system routing table¶
Browse to Diagnostics > Routes and review the routes known by the firewall. 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 shared key setup is in use and not PKI, ensure that “push” commands are not being used.
Test from different vantage points¶
If the connection appears to be up according to the logs, but it doesn’t work from the LAN, try it from the firewall itself. These tests may be easily performed using the Diagnostics > Ping page on the firewall.
First test using the inside interface being used for OpenVPN internal traffic connections (typically LAN) as the ping source. If that doesn’t work, try again using the default source address so that the firewall will source the ping from the OpenVPN interface itself.
If the default 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 where the traffic is or isn’t flowing is one of the most helpful troubleshooting techniques. Start with the internal interface (commonly LAN) on the side where the traffic is being initiated, progress to the tun interface on that firewall, then the tun interface on the remote firewall, and finally the inside interface on the remote firewall. Determining where the traffic is seen and where it isn’t can help greatly in narrowing down where the problem is located. Packet capturing is covered in detail in Packet Capturing.
Routes will not push to a client¶
When attempting to use the Local Network setting or a
push statement to
push routes to a client, and the client isn’t receiving them properly, a couple
things could be happening:
Check that an SSL/TLS server setup is used with a Tunnel Network larger than a
servermode in OpenVPN only takes effect when using a subnet large enough to contain multiple clients, such as a
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.
When using a shared key setup, pushing routes will not work. Use the Remote Network boxes or
routestatements on each side (both client and server) to direct traffic to subnets on the other end of the tunnel.
Why can’t I ping some OpenVPN adapter addresses?¶
In SSL/TLS server mode using a net30 style Topology, OpenVPN will not respond to ping on certain virtual addresses used solely for routing endpoints. Do not rely on pinging the OpenVPN endpoint addresses as a means of determining if the tunnel is passing traffic properly. Instead, ping something in the remote subnet, such as the LAN IP address of the server.
This is not relevant when using a subnet style Topology
According to the `OpenVPN FAQ`_, in the section titled Why does OpenVPN’s “ifconfig-pool” option use a /30 subnet (4 private IP addresses per client) when used in TUN mode?:
As 192.168.1.5 is only a virtual IP address inside the OpenVPN server, used as an endpoint for routes, OpenVPN doesn’t bother to answer pings on this address, while the 192.168.1.1 is a real IP address in the servers O/S, so it will reply to pings.
This may seem a little counter-intuitive, since on the server the
output looks similar to:
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 inet6 fe80::202:b3ff:fe03:8028%tun0 prefixlen 64 scopeid 0xc inet 192.168.100.1 --> 192.168.100.2 netmask 0xffffffff Opened by PID 27841
While the client shows:
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 inet6 fe80::202:b3ff:fe24:978c%tun0 prefixlen 64 scopeid 0xa inet 192.168.100.6 --> 192.168.100.5 netmask 0xffffffff Opened by PID 1949
In this case, .5 or .1. likely will not respond to ping. The .5 address will not respond because it is a virtual address, and .1 because there is no route to reach it directly. The .5 and .6 addresses are part of a /30 that goes from .4 to .7, and trying to ping .1 would go out the default route instead.
There are many cases where the far side of an OpenVPN tunnel will respond to
ping, but not the local. This is also counter-intuitive, but works especially in
cases where a site-to-site link is present. If the server shows its tun
x.x.x.1 -> x.x.x.2 and the client shows the reverse -
-> x.x.x.1, then the far will respond to ping from both ends.
Cannot route to clients on an SSL/TLS site-to-site tunnel¶
If an SSL/TLS site-to-site tunnel is used and all of the routes appear correct
but traffic still cannot flow properly, check the tunnel network size. If this
is a site-to-site setup between only two locations, the tunnel network should be
/30 so that it does not require
iroute statements to reach client
networks. See the note at IPv4/IPv6 Tunnel Network for more
information. When connecting multiple sites to a single server instance, check
the setup against Site-to-Site Example Configuration (SSL/TLS),
especially the client-specific overrides and
Client Specific Override iroute entry seems to have no effect¶
When configuring a site-to-site PKI OpenVPN setup, an
iroute statement must
be configured using the Remote Network fields on the Client Specific
Overrides entry set for the common name of the client certificate.
First, ensure that the common name matches the certificate and that the internal route is being learned/added as it expected. The log verbosity in OpenVPN may need increased (i.e. verb 10 in the custom options) to see if this is working.
Also, for each network used in a Client Specific Override Remote Network
iroute), a Remote Network (
route) is required in the server
as well. The Remote Network (
route) definitions on the server settings
are for the firewall operating system to know that the networks will be routed
to OpenVPN from everywhere else. The Remote Network (
iroute) options on
the Client Specific Override entry are internal to OpenVPN so it knows which
networks are routed to a specific certificate.
Why do OpenVPN clients all get the same IP address?¶
If the same certificate is used for all clients, which we strongly discourage, then the clients are all assigned the same IP address when they connect. To work around this, check Duplicate Connections on the server configuration.
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.
To put it simply, the DH parameters are some extra bits of randomness that help out during the key exchange process. They do not have to match on both sides of the tunnel, and new ones can be made at any time. There is no need to import an existing set of DH parameters.
By default, pfSense uses a set of pre-generated DH parameters. A new set may be generated manually if desired, see DH Parameters Length for details.