[SOLVED]Adding iroute in client-specific configuration appears to have no effect

[chezmojo]

I have the following configuration: HOME_SUBNET -> pfsense openVPN server -> openVPN-client -> OFFICE_SUBNET

openVPN-client is an Ubuntu machine that is also the gateway/router/firewall for OFFICE_SUBNET.

Running Pfsense 1.2.3, I used the SSL/TLS configuration on the pfsense server with 'route OFFICE_SUBNET' in the advanced settings, and 'iroute OFFICE_SUBNET' in the client-specific settings. This enabled the machines in OFFICE_SUBNET and HOME_SUBNET to communicate with each other transparently (i.e., they were unaware of the VPN tunnel), which was the desired behavior.

When I upgraded to Pfsense 2.0-BETA (nanoBSD), the SSL/TLS configuration no longer worked (the client could not negotiate the TLS encryption). I followed the sticky tutorial in this forum for the 'Remote Access SSL/TLS + User Auth' and was able to get openVPN-client to connect again. I used the same combination of route and iroute (and added HOME_SUBNET to the 'Local Network' field in the Pfsense server configuration), however the machines on HOME_SUBNET (i.e., on the Pfsense openVPN server side) cannot see the machines in OFFICE_SUBNET anymore. (The machines in OFFICE_SUBNET can see the machines in HOME_SUBNET fine, however).

Using tcpdump on the openVPN-client, I can see that packets destined for OFFICE_SUBNET are not being routed from HOME_SUBNET, which leads me to conclude that the 'iroute OFFICE_SUBNET' option in the 'Client Specific Overrides' section is not having any effect.

To summarize: packets originating in HOME_SUBNET with OFFICE_SUBNET as their destination are not being routed through the VPN tunnel by Pfsense even though I have specified 'route OFFICE_SUBNET' and 'iroute OFFICE_SUBNET' on the server side. Packets originating in OFFICE_SUBNET with HOME_SUBNET as their destination are being routed just fine.

When I try a Peer-to-Peer connection with OFFICE_SUBNET in the "Remote Network" field and HOME_SUBNET in the "Local Network" field I get a bunch of errors on the client side:

PUSH: Received control message: 'PUSH_REPLY,route HOME_SUBNET'
OPTIONS IMPORT: route options modified
ROUTE default_gateway=OFFICE_INET_GATEWAY
OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
OpenVPN ROUTE: failed to parse/resolve route for host/network: HOME_SUBNET

And no machines can communicate across the VPN tunnel except the endpoints.

???

[kpa]

I believe 2.0 OpenVPN with 'Remote Access SSL/TLS + User Auth' uses the user name from the user manager as the name for the client specific configuration, 1.2.3 used what was the common name in the certificate. You might have a mismatch there.

[chezmojo]

Thanks for the quick reply.

I made the CN the same as the username because I wasn't sure which one was relevant in 2.0, so presumably that isn't the problem… Unless setting the CN and username the same causes a problem itself, of course :)

[kpa]

I'm not exactly sure how iroute works but it should modify the routing table when the client connects so maybe you can look at Diagnostics->Routes before and after the client connects (or do netstat -nr from a shell).

[chezmojo]

Indeed, netstat -nr reveals that for the "Client SSL/TLS + User Auth" server configuration, no route to OFFICE_SUBNET is added. However, the "Peer to Peer SSL/TLS" configuration does add a default route for OFFICE_SUBNET.

So I guess a better option is to figure out how to get the Peer to Peer configuration working. I still get the errors below..?

PUSH: Received control message: 'PUSH_REPLY,route HOME_SUBNET'
OPTIONS IMPORT: route options modified
ROUTE default_gateway=OFFICE_INET_GATEWAY
OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
OpenVPN ROUTE: failed to parse/resolve route for host/network: HOME_SUBNET

[chezmojo]

I found the problem! Apparently the iroute command was working, but for whatever reason, moving from Pfsense 1.2.3 to 2.0-BETA requires the gateway to be specified in the 'route' command on the server side.

So changing the server-side "Advanced Config" from:

route OFFICE_SUBNET 255.255.255.0

to

route OFFICE_SUBNET 255.255.255.0 PFSENSE_VPN_GATEWAY_IP

Fixed everything (and now netstat -nr contains a route to OFFICE_SUBNET from pfsense).

Thanks!

[kpa]

Great!

I wonder if you can use "vpn_gateway" instead of the numeric address for the gateway (so it does not have to be hard coded into the configuration):

http://www.openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html, the part about –route -option.

Edit: Also it's a good question why the default for the gateway address works correctly on 1.2.3 but not on 2.0, maybe a dev could look into this ;)

[jimp]

I haven't had any issues with OpenVPN routing on 2.0 yet but I haven't gone through every scenario for site-to-site type tunnels, I've been mainly focused on mobile client access.

I want to merge at least part of the CSC tab into the user manager so there is less confusion about what is used in that case.

[kpa]

There's one thing I think should be changed about the CSC mechanism. Everything you now put there is global to every single (PKI) tunnel instance which might not be what the user wants. At least allow tunnel specific CSC settings or some other solution.

[jimp]

I'm not sure I'd agree with that. The same cert shouldn't be used on multiple instances of OpenVPN, imho. I'd prefer to use different certs if I want it to behave differently.

[chezmojo]

@kpa:

Great!

I wonder if you can use "vpn_gateway" instead of the numeric address for the gateway (so it does not have to be hard coded into the configuration):

http://www.openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html, the part about –route -option.

Edit: Also it's a good question why the default for the gateway address works correctly on 1.2.3 but not on 2.0, maybe a dev could look into this ;)

The answer is yes, which is indeed much better than hard coding it.

However, unrelated to that, I rebooted the router and I'm back to where I was: I can no longer connect to OFFICE_SUBNET even though pfsense added the route OFFICE_SUBNET -> VPN_GATEWAY. And like before, the packets are getting stuck on the pfsense side. Grrr.

[kpa]

Can you post relevant parts of your configuration please, especially subnets used in LAN/WAN and VPN networks, replace public IPs with xxx if you like.

[chezmojo]

Everything is working again (see below), but I figured I would include my configuration in case it stops working again.

On the pfsense side:

Server  mode: Remote Access SSL/TLS + User Auth
Tunnel Network: 10.8.7.0/24
Local Network: 10.10.10.0/24
Advanced: engine cryptodev;route 10.4.2.0 255.255.255.0 vpn_gateway
Client-Specific Overrides: iroute 10.4.2.0 255.255.255.0

On the client side:

dev tun1
persist-tun
persist-key
proto udp
nobind
cipher AES-128-CBC
tls-client
client
resolv-retry infinite
remote xxxxxxx 1194
auth-user-pass up
pkcs12 pfSense-udp-1194.p12
tls-auth pfSense-udp-1194-tls.key 1
comp-lzo

Routes on pfsense server:

Destination 	Gateway 	Flags 	Refs 	Use 	Mtu 	Netif 	Expire
default 	x.x.x.x 	UGS 	0 	129136 	1500 	vr1 	 
10.4.2.0/24 	10.8.7.2 	UGS 	0 	186 	1500 	ovpns1 	 
10.8.7.0/24 	10.8.7.2 	UGS 	0 	168 	1500 	ovpns1 	

While I was copying/pasting the settings into this post, I thought to change the client-specific override to:

iroute 10.4.2.0 255.255.255.0 vpn_gateway

And guess what–it works again!

PING 10.4.2.101 (10.4.2.101) 56(84) bytes of data.
64 bytes from 10.4.2.101: icmp_seq=1 ttl=62 time=31.6 ms

So the take-home lesson for me seems to be that both the route and iroute commands require "vpn_gateway" after the subnet mask.