[SOLVED]Adding iroute in client-specific configuration appears to have no effect
-
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.
-
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 :)
-
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).
-
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 -
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.0to
route OFFICE_SUBNET 255.255.255.0 PFSENSE_VPN_GATEWAY_IPFixed everything (and now netstat -nr contains a route to OFFICE_SUBNET from pfsense).
Thanks!
-
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 ;)
-
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.
-
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.
-
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.
-
@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.
-
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.
-
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.0On 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-lzoRoutes 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 ovpns1While 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_gatewayAnd 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 msSo the take-home lesson for me seems to be that both the route and iroute commands require "vpn_gateway" after the subnet mask.
