Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [solved] road warriors can't reach other OpenVPN remote networks

    Scheduled Pinned Locked Moved OpenVPN
    10 Posts 5 Posters 1.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      SpaceBass
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • M
        marvosa
        last edited by

        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?

        1 Reply Last reply Reply Quote 0
        • S
          SpaceBass
          last edited by

          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"
          1 Reply Last reply Reply Quote 0
          • G
            Gcomm
            last edited by

            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

            1 Reply Last reply Reply Quote 0
            • B
              biggsy
              last edited by

              @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."

              1 Reply Last reply Reply Quote 0
              • G
                Gcomm
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • PippinP
                  Pippin
                  last edited by

                  Note:
                  OpenVPN GUI still has to be installed by an admin.
                  To run it without admin rights, put the config in the users folder.

                  I gloomily came to the ironic conclusion that if you take a highly intelligent person and give them the best possible, elite education, then you will most likely wind up with an academic who is completely impervious to reality.
                  Halton Arp

                  1 Reply Last reply Reply Quote 0
                  • S
                    SpaceBass
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • M
                      marvosa
                      last edited by

                      • 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.

                      1 Reply Last reply Reply Quote 0
                      • S
                        SpaceBass
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.