FreeBSD route add command failed: external program exited with error status: 1

[slugshell]

Hello,

I am using openvpn quite some time now, and I just love it!
But I am having trouble with openvpn and routing.
The vpn connection is built up and working as far as the tunnel endpoint in this case 10.1.0.1, there I even could log into the pfsense firewall.
But I can't reach any LAN networks behind the tunnel, also I have the right firewall rules in place, I can be sure they are, because there is no problem logging in and reaching the lan networks from my windows desktop if i connect to my remote server through viscosity openvpn client software. I think it has to do with the error message ERROR: FreeBSD route add command failed: external program exited with error status: 1 because the route could no be added..
Here my setup:

Network:

Local:
VMWare ESXI 5.5 u1
Wan = direct isp ip (datamodem only)
LAN = 192.168.1.0/24
OpenVPN IP: 10.1.0.0/24

Remote Server:
VMware ESXI 5.5 u1
WAN = Direct ISP IP
LAN1 = 10.0.0.0/24
LAN2 = 10.0.1.0/24

Software:

Local:
2.1.4-RELEASE (amd64)
built on Fri Jun 20 12:59:50 EDT 2014
FreeBSD 8.3-RELEASE-p16

Remote:
2.1.4-RELEASE (amd64)
built on Fri Jun 20 12:59:50 EDT 2014
FreeBSD 8.3-RELEASE-p16
Openvpn setup: Client:

Error:

Remote Server:

if you want I can post some settings, but like mentioned above there seems to be no problem logging in and reaching the LAN networks from my windows desktop through viscosity.
I really hope someone can help me here.

Greetings,
Alex

[divsys]

The way I've always setup site-site connections is to do all the routing at the server end.

So your client setup doesn't need anything in the "IPv4 Remote Networks" box, those entries go in the server's "IPv4 Remote Networks".  The only other thing you have to make sure of of to add an "iroute" statement in the Client Specific Override section of the server for the client's network(s).

You mentioned Viscosity linking in ok, do you use the same OpenVPN server for both your RoadWarrior and site-site connections?
If so, you're the second person to suggest that.  I've always created 2 separate servers so that i can deal with RoadWarriors and site-site connections in a distinct fashion and adjust one without affecting the other.

Just my $.02  ;)

[heper]

your "tunnel network" is the same as one of your "remote networks"

this is most likely the cause of this error. either change the tunnel network, or remove the remote-network.

[divsys]

@heper:

your "tunnel network" is the same as one of your "remote networks"

this is most likely the cause of this error. either change the tunnel network, or remove the remote-network.

Er, I think you misread.  The OP has tunnel network:

OpenVPN IP: 10.1.0.0/24

While the remote nets are:

LAN1 = 10.0.0.0/24
LAN2 = 10.0.1.0/24

No conflicts there, he's using 10.0.0.x,10.0.1.x,and 10.1.0.x.

[toomeek]

WHY there is

ovpnc1 10.1.0.3 10.1.0.3 mtu 1500 netmask 255.255.255.0 up

shouldn't be something like:

ovpnc1 10.1.0.1 10.1.0.2 mtu 1500 netmask 255.255.255.0 up

???
Do You have correct netmask on both sides?

[divsys]

Well there's another Huh? moment for me.

I @TooMeeK:

WHY there is

ovpnc1 10.1.0.3 10.1.0.3 mtu 1500 netmask 255.255.255.0 up

shouldn't be something like:

ovpnc1 10.1.0.1 10.1.0.2 mtu 1500 netmask 255.255.255.0 up

???
Do You have correct netmask on both sides?

I read your post and thought, "Aha, that does look strange".  Then just for fun, I went back through my OpenVPN logs on my main router to look at what happens "normally".
This router has been running for about 6 years, currently at 2.1.4 on a HD with no major packages but some 5 OpenVPN servers and 20+ OpenVPN clients.

Lo and behold I found 1 of the server instances that produces the same type of entry in the logs " /sbin/ifconfig ovpns16 10.155.50.1 10.155.50.1 mtu 1500 netmask 255.255.255.0 up"!  The other instances of server (and client) all show the expected .1 .2 split of a "normal" connection.  To make matters worse (sort of  ??? ) this particular connection routes traffic just fine, I can log into remote boxes, get to the client pfsense box, etc.  I need to hunt down the difference in this particular connection and see what's up….

But as far as the OP, it doesn't necessarily matter.  :o

Edit:
Ahem - Woooops  :-[

That's what i get for typing instead of thinking <sigh>.  The server I found in the logs was for a separate RoadWarrior connection, so my log entry is exactly what's expected.

That leads me to believe that the original OP may have a similar problem.  Now I noticed the screen shots show Peer to Peer mode in the client, but the log file shows the OpenVPN instance "ovpnc1" trying to connect in what looks like Remote Access mode.  Either the log file doesn't match the configuration screen or vice-versa.

One issue I have seen with OpenVPN (especially when changing certificates) is it's possible to have a "cached" version of the OpenVPN instance that will hang around even after a GUI based restart of the instance.  I've had to manually go in and kill the process then do a GUI start.

Perhaps it be simplest to do restart of pfSense o both ends, just to test?</sigh>

[toomeek]

For me it sounds like simple invalid route.
One side shouldn't connect to itself IP.
When I hit problem with OpenVPN (example: change WAN address and see what happends with routing in OpenVPN..) then I just recreated OpenVPN server and client side using existing certificates..
Alwas make a backup of the config! It's very important and desired feature of pfSense!

[heper]

yeah, sorry misread … need to stop responding to things before having a couple of gallons of coffee ;)

@divsys:

@heper:

your "tunnel network" is the same as one of your "remote networks"

this is most likely the cause of this error. either change the tunnel network, or remove the remote-network.

Er, I think you misread.  The OP has tunnel network:

OpenVPN IP: 10.1.0.0/24

While the remote nets are:

LAN1 = 10.0.0.0/24
LAN2 = 10.0.1.0/24

No conflicts there, he's using 10.0.0.x,10.0.1.x,and 10.1.0.x.