OpenVPN Site-to-Site not working (routes not being set up?)
-
When I try to connect to the VPN server from the client (both running pfsense), I get these errors on the client:
May 23 20:28:13 openvpn 55415 /sbin/ifconfig ovpnc1 10.3.0.2 10.3.0.1 mtu 1500 netmask 255.255.255.0 up May 23 20:28:13 openvpn 55415 ERROR: FreeBSD route add command failed: external program exited with error status: 1 May 23 20:28:13 openvpn 55415 /usr/local/sbin/ovpn-linkup ovpnc1 1500 1589 10.3.0.2 255.255.255.0 init May 23 20:28:13 openvpn 55415 ERROR: FreeBSD route add command failed: external program exited with error status: 1
I'm pretty sure we don't have any conflicting subnets, but here are the settings we have for the client and server:
Client:
-
Server mode: Peer to Peer (SSL/TLS)
-
Device mode: tun
-
Interface: WAN
-
Encryption algorithm: AES-256-CBC
-
Auth digest algorithm: SHA1
-
IPv4 Tunnel Network: 10.3.0.0/24
-
IPv4 Remote Network: 10.0.0.0/24
Server:
-
Server mode: Peer to Peer (SSL/TLS)
-
Device mode: tun
-
Interface: WAN
-
Encryption algorithm: AES-256-CBC
-
Auth digest algorithm: SHA1
-
IPv4 Tunnel Network: 10.3.0.0/24
-
IPv4 Local Network: 10.0.0.0/24
-
IPv4 Remote networks: 10.2.0.0/24
Also, on the client, the LAN interface uses 10.2.0.0/24. What could we do to fix this issue?
-
-
Post your server1.conf and client1.conf
-
The routes look like they already exist in the routing table. Disable that OpenVPN client instance and check Diagnostics > Routes. Is anything that would contain 10.3.0.2 already there?
-
Sorry for the late reply. I just uploaded my .conf files at https://screenshits.nofla.me/client1.txt and https://screenshits.nofla.me/server1.txt. In Diagnostics -> Routes, nothing that would contain 10.3.0.2 is there with OpenVPN stopped.
-
As we progress, it looks like we need you to define for us what "not working" means in your case. Is the tunnel connecting, but you can't communicate with any remote devices? Or is the tunnel not coming up at all?
A few things I see right off the bat:
-
In a routed tunnel, all subnets on both sides need to be unique and it looks like there may be either some overlap, a typo or possibly a misunderstanding. In your OP, you stated the client's LAN was 10.2.0.0/24, but per the client's config, the client's WAN has an address of 10.2.0.1, which tells me the client's PFsense box is double NAT'd behind another edge device (not recommended), which may need to be addressed first depending on what's "not working".
-
On the server side, the server is routing 10.2.0.0/24 down the tunnel, but that is the LAN behind the client's current edge device… that's not the LAN behind PFsense. You will need to acquire the LAN subnet behind PFsense and adjust the "IPv4 Remote network(s)" line accordingly.
-
The two sites have mismatched device modes. The client is using device mode "TAP" while the server is using device mode "TUN". In a routed solution, the device mode needs to be "TUN".
-
-
And instead of saying "nothing that would contain 10.3.0.2 is there with OpenVPN stopped" just post your routes and we will decide that for ourselves.
-
In a routed tunnel, all subnets on both sides need to be unique and it looks like there may be either some overlap, a typo or possibly a misunderstanding. In your OP, you stated the client's LAN was 10.2.0.0/24, but per the client's config, the client's WAN has an address of 10.2.0.1, which tells me the client's PFsense box is double NAT'd behind another edge device (not recommended), which may need to be addressed first depending on what's "not working".
Just fixed that, accidentally selected the LAN interface for it instead of WAN.
On the server side, the server is routing 10.2.0.0/24 down the tunnel, but that is the LAN behind the client's current edge device… that's not the LAN behind PFsense. You will need to acquire the LAN subnet behind PFsense and adjust the "IPv4 Remote network(s)" line accordingly.
Guessing that was fixed by fixing the interface issue?
The two sites have mismatched device modes. The client is using device mode "TAP" while the server is using device mode "TUN". In a routed solution, the device mode needs to be "TUN".
Just fixed that on the client, didn't fix anything
Here's my routes without the VPN connected:
Destination Gateway Flags Use Mtu Netif Expire
default 66.229.104.1 UGS 913103 1500 bge0
10.2.0.0/24 link#2 U 2468145 1500 bge1
10.2.0.1 link#2 UHS 0 16384 lo0
66.229.104.0/21 link#1 U 5409 1500 bge0
66.229.107.166 link#1 UHS 0 16384 lo0
127.0.0.1 link#6 UH 0 16384 lo0