[solved] road warriors can't reach other OpenVPN remote networks
-
Hey folks!
I feel like this is almost a weekly post. But for the life of me, after scouring the other threads. I'm still stuck.
tl;dr: I am pushing routes, rules are any/any, road warriors can reach lan hosts, but not hosts on other OVPN segments.I have 4 sites all connected to each other via OpenVPN site to site networks. Each site can successfully reach the other sites.
But road warriors connecting to any of the 4 sites' PFsense boxes can only reach hosts on that particular site's LAN.
I'm sure it's an error in how I've done the push routes and I'd be grateful for a 2nd set of eyes! :)
Here's a simplified diagram of Site A and Site B and a road warrior connected to site B
Here's the site-to-site config on 'custom options' of Site A:
[b]push "route 10.5.1.0 255.255.255.0";[/b] push "route 192.76.33.0 255.255.255.0"; push "route 192.168.42.0 255.255.255.0"; push "route 10.99.1.0 255.255.255.0"; push "route 192.168.27.0 255.255.255.0";
Here's the Road Warrior config on Site A's Custom options:
[b]push "route 10.5.1.0 255.255.255.0"[/b];push "route 10.1.1.0 255.255.255.0";push "route 10.15.1.0 255.255.255.0";push "route 192.168.54.0 255.255.255.0"
the problem is:
when connected to Site A, road warrior clients cannot reach 10.5.1.0/24 (site B's LAN)Anyone see anything I'm missing?
-
Post the server1.conf from site A and the client1.conf from site B.
Also, all of those custom options are unnecessary. If you enter the CIDR ranges in the GUI, those directives are auto generated.
Are you using shared key or PKI?
-
thanks Marvosa for the reply.
first, here's the site-to-site config
Server1
dev ovpns4 verb 1 dev-type tun tun-ipv6 dev-node /dev/tun4 writepid /var/run/openvpn_server4.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC auth SHA1 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local [redacted] tls-server ifconfig 192.168.43.1 192.168.43.2 lport 1200 management /var/etc/openvpn/server4.sock unix push "route 10.50.1.0 255.255.255.0" push "route 10.5.1.0 255.255.255.0" route 10.15.1.0 255.255.255.0 ca /var/etc/openvpn/server4.ca cert /var/etc/openvpn/server4.cert key /var/etc/openvpn/server4.key dh /etc/dh-parameters.2048 comp-lzo adaptive push "route 10.5.1.0 255.255.255.0" push "route 192.76.33.0 255.255.255.0" push "route 192.168.42.0 255.255.255.0" push "route 10.99.1.0 255.255.255.0" push "route 192.168.27.0 255.255.255.0"
client2
dev ovpnc6 verb 1 dev-type tun tun-ipv6 dev-node /dev/tun6 writepid /var/run/openvpn_client6.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC auth SHA1 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local [redacted] tls-client client lport 0 management /var/etc/openvpn/client6.sock unix remote [redacted] 1200 ifconfig 192.168.43.2 192.168.43.1 route 10.50.1.0 255.255.255.0 ca /var/etc/openvpn/client6.ca cert /var/etc/openvpn/client6.cert key /var/etc/openvpn/client6.key comp-lzo adaptive resolv-retry infinite
Now, here are the road warrior configs for both
Road Warrior server config for 'server 1'
dev ovpns6
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun6
writepid /var/run/openvpn_server6.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-128-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local [redacted]
tls-server
server 192.168.42.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc/server6
username-as-common-name
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Vail LDAP,Blackcomb' false server6" via-env
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'NSnetVPN' 1"
lport 1195
management /var/etc/openvpn/server6.sock unix
push "route 10.50.1.0 255.255.255.0"
push "route 10.5.1.0 255.255.255.0"
push "route 10.15.1.0 255.255.255.0"
push "route 10.1.1.0 255.255.255.0"
push "dhcp-option DOMAIN vpn.nsnet.us"
push "dhcp-option DNS 10.50.1.1"
push "dhcp-option DNS 10.15.1.1"
push "dhcp-option DNS 10.15.1.15"
push "dhcp-option DNS 8.8.8.8"
push "redirect-gateway def1"
client-to-client
duplicate-cn
ca /var/etc/openvpn/server6.ca
cert /var/etc/openvpn/server6.cert
key /var/etc/openvpn/server6.key
dh /etc/dh-parameters.2048
tls-auth /var/etc/openvpn/server6.tls-auth 0
comp-lzo adaptive
persist-remote-ip
float
topology subnet
push "route 10.5.1.0 255.255.255.0"
push "route 10.1.1.0 255.255.255.0"
push "route 10.15.1.0 255.255.255.0"
push "route 192.168.54.0 255.255.255.0"road warrior server on 'client 1'
dev ovpns2 verb 1 dev-type tun tun-ipv6 dev-node /dev/tun2 writepid /var/run/openvpn_server2.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC auth SHA1 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown client-connect /usr/local/sbin/openvpn.attributes.sh client-disconnect /usr/local/sbin/openvpn.attributes.sh local 108.31.103.106 engine cryptodev tls-server server 192.168.27.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc/server2 username-as-common-name auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user VmFpbCxCbGFja2NvbWI= false server2 1194" via-env tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'wdc.nsnet.us' 1" lport 1194 management /var/etc/openvpn/server2.sock unix push "dhcp-option DOMAIN vpn.nsnet.us" push "dhcp-option DNS 10.15.1.1" push "dhcp-option DNS 10.15.1.15" push "dhcp-option DNS 8.8.8.8" push "redirect-gateway def1" client-to-client duplicate-cn ca /var/etc/openvpn/server2.ca cert /var/etc/openvpn/server2.cert key /var/etc/openvpn/server2.key dh /etc/dh-parameters.2048 tls-auth /var/etc/openvpn/server2.tls-auth 0 comp-lzo adaptive topology subnet push "route 10.50.1.0 255.255.255.0" push route "10.75.1.0 255.255.255.0"
-
Make sure that the roadwarriors are running their VPN clients with admin rights on their Windows machines otherwise they won't always get the pushed routes in their routing tables - this tested with OpenVPN GUI and Windows 7.
The other thing that I'm experiencing right at this moment is even though you have your pushed routes in the Custom Options box you might need to click SAVE to enable them (yes even though they are there) if your PfSense has rebooted - this tested on
2.3.2-RELEASE (amd64)
built on Tue Jul 19 12:44:43 CDT 2016
FreeBSD 10.3-RELEASE-p5 -
Make sure that the roadwarriors are running their VPN clients with admin rights on their Windows machines otherwise they won't always get the pushed routes in their routing tables - this tested with OpenVPN GUI and Windows 7.
From the OpenVPN GUI download site:
"OpenVPN GUI bundled with the Windows installer has a large number of new features compared to the one bundled with OpenVPN 2.3. One of major features is the ability to run OpenVPN GUI without administrator privileges. For full details, see the changelog. The new OpenVPN GUI features are documented here."
-
Nice Biggsy. Maybe it's time SpaceBass for you and I to upgrade to the latest, however I didn't catch which version your roadwarriors were running.
Let us know.
-
Note:
OpenVPN GUI still has to be installed by an admin.
To run it without admin rights, put the config in the users folder. -
Thanks friends!
None of my clients are Windows. Everything is MacOS, Linux, iOS or Android.On MacOS I use viscosity.
On iOS I use OpenVPN.app
on Linux I just use the openvpn cliI dont think it's a version or client software issue…but I could be wrong.
-
-
The road warriors coming in on server 1's remote access server cannot access client 2's LAN because there is no return route for server 1's remote access tunnel network (192.168.42.0/24) on client 2's site-to-site config.
Fix -> Add 192.168.42.0/24 to the IPv4 Remote network(s) line on client 2's site-to-site config -
The road warriors coming in on client 2's remote access server cannot access server 1's LAN because there is no return route for client 2's remote access tunnel network (192.168.27.0/24) on server 1's site-to-site config.
Fix -> Add 192.168.27.0/24 to the IPv4 Remote network(s) line on server 1's site-to-site config -
Clean up -> On server 1's remote access config, remove everything from the Advanced Configuration section, it's all redundant with the exception of 192.168.54.0/24. Add 192.168.54.0/24 to the IPv4 Local network(s) section.
-
Clean up -> On client 2's remote access config, remove everything from the Advanced Configuration section. Add 10.50.1.0/24 and 10.75.1.0/24 to the IPv4 Local network(s) section.
-
-
Thank you Marvosa!!
Took me a while to wrap my brain around your fix but it totally worked! 100%!
And I learned a lot about OVPN and routing too. Thank you!!