[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

    See https://forum.pfsense.org/index.php?topic=132488.0



  • @Gcomm:

    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 cli

    I 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!!