OpenVPN Routing Issue? (FreeBSD route add command failed)
-
the tunnel network should be identical on the server & client
-
Ahh sorry, that's just a typo. I corrected it. Tunnel network is identical…
-
When you were doing pings, were you using the tunnel IP addresses? In a site-to-site tunnel scenario like this they are probably 10.0.121.1 and 10.0.121.2 for the server and client respectively. Both devices should be able to ping both addresses.
If it's being dumb you can try formatting the ping command like this (assuming from the console, server to client version):
ping -S 10.0.121.1 10.0.121.2and respectively on the client:
ping -S 10.0.121.2 10.0.121.1Should be able to do that much without routing being involved, maybe rule out a problem with traffic on the tunnel itself…
-
Hey cool, thank you so much for this hint!
I just discovered that it is possible to ping from Client Site (10.1.100.1) to Main Site (10.2.100.1).
From Client Site, I tried to ping the Main Site Router itself (10.2.100.1) as well as one computer in it's Network (10.2.100.10). The ping was returned! Cool! :)
However, that's all what I achieved! Accessing for example the web configuration of the Main Site Router (from the Client Site) is not working. Hmm… I don't get this... How can it be, that a ping works but accessing the webpanel of the Main Site Router doesn't?
I attached screenshots from my current settings...
Remark: On the Client Site, there is a VPN Road Warrior Server running. I hope this doesn't interfere with Site-to-Site Connection. The Road Warrior is using the default tunnel 10.0.0.8 (as can be seen on the screenshot).
EDIT:
I just tried a packet capture.
When pinging from Mainsite pfsense shell (10.2.100.1) to Remote Site pfSense (10.1.100.1) I receive the following packet capture:10:53:18.833129 IP 10.0.121.1 > 10.1.100.1: ICMP echo request, id 56155, seq 0, length 64 10:53:19.842638 IP 10.0.121.1 > 10.1.100.1: ICMP echo request, id 56155, seq 1, length 64 10:53:20.852518 IP 10.0.121.1 > 10.1.100.1: ICMP echo request, id 56155, seq 2, length 64
When doing a ping from Remote-Site pfsense (10.1.100.1) to Main Site pfSense (10.2.100.1), packet capture shows the following:
10:56:56.971346 IP 10.0.121.2 > 10.2.100.1: ICMP echo request, id 32190, seq 0, length 64 10:56:56.981851 IP 10.2.100.1 > 10.0.121.2: ICMP echo reply, id 32190, seq 0, length 64 10:56:57.972220 IP 10.0.121.2 > 10.2.100.1: ICMP echo request, id 32190, seq 1, length 64 10:56:57.982162 IP 10.2.100.1 > 10.0.121.2: ICMP echo reply, id 32190, seq 1, length 64 10:56:59.035098 IP 10.0.121.2 > 10.2.100.1: ICMP echo request, id 32190, seq 2, length 64 10:56:59.065843 IP 10.2.100.1 > 10.0.121.2: ICMP echo reply, id 32190, seq 2, length 64
Furthermore, I just entered …
route 10.1.100.0 255.255.255.0; push "route 10.2.100.0 255.255.255.0"
… into the Advanced Configuration of the OpenVPN Server on the Main Site... However, in exactly that moment the error...
ERROR: FreeBSD route add command failed: external program exited with error status: 1
… gets triggered on the Main Site. So I deleted again - regarding pinging from the Remote Site, this makes no difference!
-
Okay I got it working now…
For anyone who might get into the same trouble as me, I did two things:
- check, if there are VPN Connections referring to the same subnet as your Site-to-Site connection! => I deleted my Road Warrior Setup on the Client Site! It was referring to the same subnet (10.1.100.1) as the Site-to-Site Connection between Main Site and Remote Site.
- I switched from PKI to shared key Site-to-Site
and it's running :D However, one problem occured:
When switching from PKI to shared Key, on the Server, I am missing the option "Supply DNS servers to the client"... So, Hostname Resolution of the Clients of the remote VPN network does not work. Is it possible to provide hostname resolution also with shared key OpenVPN?
-
I have been having the exact same problem that you have had and I fixed it the exact same way, by switching from PKI over Shared-Key.
I would REALLY rather use PKI as my planned design is hub and spoke, as well as the ease of configuration for many clients. If anyone has any ideas as to what caused it to suddenly break free and start working when it was changed over to Shared Key, I'd love to hear those ideas.
-
Hi hobbes,
I haven't tried it yet, but I think hub-and-spoke should also work with shared key, shouldn't it? (-> Client Specific Overrides?)
I like shared key, because every openvpn server is running in it's own instance / process :)
-
Hey Scampicfx–
I fixed my problem yesterday. For me, the issue was a couple fold:
-
I was assuming that each client override had to specify their individual /30 range. The reality is that the client override just uses the same as the primary, it just needs to be big enough for the number of clients. So a /24 would break out into about 64 client networks. This is in the documentation I somehow just didn't understand it the first 8 times I read it.
-
I was assuming that by specifying the individual client networks in the override, it would insert all needed routes. This was a wrong assumption. I needed to insert all my individual client networks in the server config (separated by commas), and then use the client config to specify which client got which route... so instead of the override saying "use this instead" it was saying "of the ones you know, this client = this network"
-
My client and the server were not negotiating compression with each other. When I disabled compression on both sides after fixing bullets 1 and 2, I suddenly started seeing pings.
-
Patience. All of the routes took anywhere from 30 seconds to 2 mins to fully propagate after the VPN was "up". So instead of waiting that time, I was pinging, seeing no response, then making a change and restarting the wait time. It is likely I had the correct configuration a few times before I realized it was working because of this lack of patience.
I didn't like shared key because it meant I had to manage a whole bunch of server processes and a whole slew of open ports. By using SSL I could have just one instance, just one port, and then I can deploy a standard configuration to all my sites with the exception to the client certificate.... but to each their own.
-
-
Dear hobbes80,
thank you for your posting.
I appreciate it when people share their knowledge! It might help other users out there!
I haven't tried yet the client specific override, but when I got it correctly from your posting, a hub-and-spoke setup does only work when doing a VPN setup like you did?
I just had a look to the client specific override page and at the beginning I'm requested to enter the client's X.509 common name. However, this name doesn't exist when doing a shared key setup, does it?I'm wondering if it is possible to setup hub and spoke when using shared key method as well…?
-
Hub and spoke from the perspective of one running OpenVPN server and a bunch of clients only works with SSL.
Hub and spoke from the perspective of many external places connecting back to one datacenter can be configured with shared, but you'd need to set it a different OpenVPN server for every client. Which is why I didn't want to go down that path.
The client override only applies to certificates that exist in the certificate manager, whether imported from somewhere else or created internally.