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

    [SOLVED] Remote Access Clients not able to access remote S2S hosts

    OpenVPN
    4
    12
    2.2k
    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.
    • P
      penzoiders
      last edited by

      Hello,

      I tried to figure this out but I may better ask.

      I have 4 pfsense 2.2 boxes, 1 is OpenVPN server, the other 3 connect trough site2site openvpn,
      so the main pfsense has 3 s2s openvpn server running on different ports,  I export each local network and import each remote network so any host in any site is able to ping any other host in any other site… so this part is ok.

      now I added a remote access server (so 4th openvpn server on main firewall) to connect the mobile clients to the network.

      I set all the LAN subnets of all sites in the filed "IPv4 Local Network/s" but when I connect I can only access the networks that are behind the main firewall and not the s2s endpoint's Local Network (that are the LAN behind the 2nd, 3rd and 4th firewall).

      s2s is working fine,  but remote access is limited to the main firewall's LAN subnet (even if other networks are exported and the openvpn client correctly add routes to the tun0 interfaces for those networks)

      one image to help understanding what I may think as a solution but I need your help to figure it out.

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

        I think this is the kind of situation where you need to use iroute… (no experience with it, just know of its existence ;) )

        see http://backreference.org/2009/11/15/openvpn-and-iroute/
        (or google for iroute, there was a tutorial on the openvpn site somewhere also)

        4x XG-7100 (2xHA), 1x SG-4860, 1x SG-2100
        1x PC Engines APU2C4, 1x PC Engines APU1C4

        1 Reply Last reply Reply Quote 0
        • P
          penzoiders
          last edited by

          I see that iroute is a parameter for ccd…
          cannot be applied to all clients connected to the server at once (I cannot write a file for every user of vpn, need something more maneageble).

          I need to push the routes for all remote networks to the mobile clients.
          10.254.254.1 is the ovpns gateway for the mobile clients, and when I specify wich networks to export it correctly adds the routes to the client

          Thu Feb  5 16:28:52 2015 us=241182 /usr/sbin/ip route add 10.55.0.0/16 via 10.254.254.1  ---> LAN of ovpnserver [working, pingable]
          Thu Feb  5 16:28:52 2015 us=246179 /usr/sbin/ip route add 192.168.2.0/24 via 10.254.254.1 –-> other subnet of virtual IP for LAN of ovpnserver  [working, pingable]
          Thu Feb  5 16:28:52 2015 us=249160 /usr/sbin/ip route add 10.66.0.0/16 via 10.254.254.1 –-> LAN of ovpn site to site remote client [not working]
          Thu Feb  5 16:28:52 2015 us=249233 /usr/sbin/ip route add 10.77.0.0/16 via 10.254.254.1 –-> LAN of ovpn site to site remote client [not working]
          Thu Feb  5 16:28:52 2015 us=249256 /usr/sbin/ip route add 10.88.0.0/16 via 10.254.254.1 –-> LAN of ovpn site to site remote client [not working]
          Thu Feb  5 16:28:52 2015 us=251273 Initialization Sequence Completed

          routes on the ovpnserver are these:

          LOCAL LAN - related
          10.55.0.0/16    link#1  U       3491272 1500    vr0
          10.55.0.1       link#1  UHS     0       16384   lo0
          
          S2S OpenVPN - related
          10.66.0.0/16    172.16.99.2     UGS     937200  1500    ovpns1
          10.77.0.0/16    172.16.98.2     UGS     16440   1500    ovpns2
          10.88.0.0/16    172.16.97.2     UGS     26330   1500    ovpns3
          172.16.97.1     link#10 UHS     0       16384   lo0
          172.16.97.2     link#10 UH      78      1500    ovpns3
          172.16.98.1     link#9  UHS     0       16384   lo0
          172.16.98.2     link#9  UH      0       1500    ovpns2
          172.16.99.1     link#8  UHS     0       16384   lo0
          172.16.99.2     link#8  UH      610     1500    ovpns1
          
          Remote Access OpenVPN - related
          10.254.254.0/24 link#12 U       777     1500    ovpns4
          10.254.254.1    link#12 UHS     0       16384   lo0
          

          maybe 10.254.254.1 cannot go trough 172.16.99-98-97.1 to ask for 10.66-77-88.0 ?
          i added a rule to permit all in the OpenVPN interface under firewall-rules.
          cannot see where other I can set this up.

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            At the other office ends of the site-to-site OpenVPN links, they will need to have the "road warrior" subnet listed in IPv4 Remote Networks box. They need to know that the "road warrior" subnet is reached across the OpenVPN link to main office.
            Then rules on the OpenVPN tab on each pfSense need to allow traffic coming to/from the "road warrior" subnet as appropriate.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

              Ah. I was under the impression that was already done & tried, wrong assumption, my bad.

              As Phil explained, a route to each network needs to be know by the client.

              You can add those remote networks here: Openvpn:Server>Tunnel Settings>IPv4 Local Network/s,
              or under the Openvpn:Server>Advanced configuration>Advanced, like this:  push "route 10.66.0.0 255.255.0.0";
              and so on. (one entry for each route, or summarize them)
              Doing so will push that route to the route table of the vpn client.

              Give it a shot, let us know.

              4x XG-7100 (2xHA), 1x SG-4860, 1x SG-2100
              1x PC Engines APU2C4, 1x PC Engines APU1C4

              1 Reply Last reply Reply Quote 0
              • P
                penzoiders
                last edited by

                @phil.davis:

                At the other office ends of the site-to-site OpenVPN links, they will need to have the "road warrior" subnet listed in IPv4 Remote Networks box. They need to know that the "road warrior" subnet is reached across the OpenVPN link to main office.
                Then rules on the OpenVPN tab on each pfSense need to allow traffic coming to/from the "road warrior" subnet as appropriate.

                I feel so stupid…  ::)  ;D

                I put the "road warrior" subnet in the "IPv4 Local Network/s" on the Site 2 Site Server Configuration... and I forgot to put it into the "IPv4 Remote Network/s" on the Site 2 Site Client Configuration.

                now everything is working fine

                1 Reply Last reply Reply Quote 0
                • P
                  phil.davis
                  last edited by

                  Yeh, that is a bit tricky. As I remember for site-2-site it is what is in IPv4 Remote Network/s box on each end that is effective. What is in IPv4 Local Network/s does not get pushed to the other end.
                  But for "road warrior" style servers the IPv4 Local Network/s on the server end are pushed to the clients as they connect.

                  As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                  If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                  1 Reply Last reply Reply Quote 0
                  • P
                    penzoiders
                    last edited by

                    @phil.davis:

                    Yeh, that is a bit tricky. As I remember for site-2-site it is what is in IPv4 Remote Network/s box on each end that is effective. What is in IPv4 Local Network/s does not get pushed to the other end.
                    But for "road warrior" style servers the IPv4 Local Network/s on the server end are pushed to the clients as they connect.

                    yes.. I don't understand why s2s LocalNetworks are not pushed to the client… maybe because I specified something in the RemoteNetworks on the s2s client.. I have to make a test and see if  I leave it blank it gets the push (as for the road warriors).

                    is it possible to connect more s2s clients to a single s2s server?  maybe in this case the "remote networks" field on the client makes sense in order to limit the access of a single s2s client.
                    ... and if this is true I have 2 s2s server in excess and i could have used only one... right?

                    1 Reply Last reply Reply Quote 0
                    • D
                      doktornotor Banned
                      last edited by

                      There's this client-specific overrides overrides thing available, I assume for some reason. Here's what I have there for site2site:

                      which results in this in cat /var/etc/openvpn-csc/homeoffice.example.com

                      
                      ifconfig-push 10.0.9.2 10.0.9.1
                      push "route 10.0.0.0 255.255.255.0"
                      iroute 192.168.1.0 255.255.255.0
                      iroute 192.168.10.0 255.255.255.0
                      
                      

                      It works.

                      1 Reply Last reply Reply Quote 0
                      • P
                        phil.davis
                        last edited by

                        Yes, that all works nicely - you can have a fistful of s2s clients and the s2s server knows which one is which by the client certificate it presents. Then it knows which subnets are on the end of which clients, so it can pick the correct client link to send packets down.

                        If you use pre-shared key (PSK) then you can only have 1 client for 1 server and they authenticate by having a matching PSK. In that mode there is no way to tell the difference between multiple clients.

                        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
                        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

                        1 Reply Last reply Reply Quote 0
                        • D
                          doktornotor Banned
                          last edited by

                          @phil.davis:

                          If you use pre-shared key (PSK) then you can only have 1 client for 1 server and they authenticate by having a matching PSK. In that mode there is no way to tell the difference between multiple clients.

                          One more reason to avoid PSK configs. ;)

                          1 Reply Last reply Reply Quote 0
                          • P
                            penzoiders
                            last edited by

                            @doktornotor:

                            @phil.davis:

                            If you use pre-shared key (PSK) then you can only have 1 client for 1 server and they authenticate by having a matching PSK. In that mode there is no way to tell the difference between multiple clients.

                            One more reason to avoid PSK configs. ;)

                            Ok, now I remember why… I followed a s2s guide that was using PSK... In my case it would have been better to use SSL/TLS and manage all with certs on one server ... next time will do better :)

                            thanks anyone for the feedback (learnt something more today) now I have a much clearer view on the pfsense OpenVPN settings

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