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

    Site to site VPN routing additional subnetworks at Main server site

    Scheduled Pinned Locked Moved OpenVPN
    12 Posts 4 Posters 4.3k 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.
    • P
      phil.davis
      last edited by

      @tbaror:

      Hello All,

      I have established site to site VPN AS follows below diagram, on remote main i need to access additional sub network of 192.168.0.0
      On server configuration i added

      push "route 192.168.0.0 255.255.0.0";

      but when i try to access that network i cant , did i missed something ?
      please advice
      Thanks

      client BRANCH 172.16.1.0/24>>>>>>>>>MAIN server21x.x.x.x
                                                                    |
                                                                    |
                                                                  21x.x.x.4 gateway
                                                                     192.168.0.0/24

      Your "diagram" shows 192.168.0.0/24 - so the push route should be:

      push "route 192.168.0.0 255.255.255.0"
      

      (that should not have broken anything)

      a) Routing boxes need to know about subnets that are not locally connected:
      MAIN server - make sure it has a route to 192.168.0.0/24 through 21x.x.x.4
      21x.x.x.4 gateway - make sure it has a route to 172.16.1.0/24 through MAIN server 21x.x.x.x

      b) Traffic needs to be passed by any firewalls along the way:
      Make sure that firewall rules on MAIN server and gateway allow traffic to/from all the subnets.

      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
      • T
        tbaror
        last edited by

        @phil.davis:

        @tbaror:

        Hello All,

        I have established site to site VPN AS follows below diagram, on remote main i need to access additional sub network of 192.168.0.0
        On server configuration i added

        push "route 192.168.0.0 255.255.0.0";

        but when i try to access that network i cant , did i missed something ?
        please advice
        Thanks

        client BRANCH 172.16.1.0/24>>>>>>>>>MAIN server21x.x.x.x
                                                                     |
                                                                     |
                                                                   21x.x.x.4 gateway
                                                                      192.168.0.0/24

        Your "diagram" shows 192.168.0.0/24 - so the push route should be:

        push "route 192.168.0.0 255.255.255.0"
        

        (that should not have broken anything)

        a) Routing boxes need to know about subnets that are not locally connected:
        MAIN server - make sure it has a route to 192.168.0.0/24 through 21x.x.x.4
        21x.x.x.4 gateway - make sure it has a route to 172.16.1.0/24 through MAIN server 21x.x.x.x

        b) Traffic needs to be passed by any firewalls along the way:
        Make sure that firewall rules on MAIN server and gateway allow traffic to/from all the subnets.

        Hi
        Thanks for the answer , my main server siteA is aware and can ping 192.168.0.0 successfully
        Now when i ping from 172.16.1.49 >>>>>fwbranch>>>>>>fwmain21x.x.x.1>>>>>>21x.x.x.4 i have replay and i can ping opposite
        but when i ping        for example 172.16.1.49 >>>>>fwbranch>>>>>>fwmain21x.x.x.1>>>>>>21x.x.x.4>>192.168.3.59 i get timeout
        But i think the issue is on the branch side why when i do simple tracert test to 21x.x.x.4 i get routed trogh the tunnel network

        C:\Users>tracert 21x.xx.xx.4

        Tracing route to tunnel [21x.xx.xx.4]
        over a maximum of 30 hops:

        1    <1 ms    <1 ms    <1 ms  172.16.1.3
         2   118 ms   110 ms   111 ms  10.0.8.1    >>>>>tunnel network
         3   113 ms   128 ms   122 ms  host [21x.xx.xx.4]

        and when i do same to private network i can see i am not go trough the tunnel

        C:\Users>tracert 192.168.3.59

        Tracing route to 192.168.3.59 over a maximum of 30 hops

        1     *        *        *     Request timed out.
         2  net-xx-x1-1x-1.cust.dsl.vodafone.it [xx-x1-1x]  reports: Destination net
        unreachable.

        Trace complete.

        so i guess there is route push config i tried to put on server side

        push "route 192.168.0.0 255.255.0.0";

        and client side

        route 192.168.0.0 255.255.0.0;

        but still not working

        please advice
        Thanks

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

          Yes, the push route should work. There might be some confusion about the 192.168.0.0 subnet.
          Your original diagram mentions 192.168.0.0/24
          But your push route examples are using 192.168.0.0/16 and you are pinging to 192.168.3.59 - out of the /24 but in the /16.
          I suggest double-check all settings and make sure "/16" "255.255.0.0" is being used everywhere for 192.168.0.0 - particularly the client conf file (it might have an old push route entry that is wrong?)
          And try to ping/traceroute to something in the 192.168.0.1-254 range - if that works then you just have a subnet mask wrong somewhere preventing getting to the higher addresses.

          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
          • M
            marvosa
            last edited by

            That's precisely why I asked for a better network map and more detail.  We are also still waiting for configs.

            1 Reply Last reply Reply Quote 0
            • T
              tbaror
              last edited by

              @phil.davis:

              Yes, the push route should work. There might be some confusion about the 192.168.0.0 subnet.
              Your original diagram mentions 192.168.0.0/24
              But your push route examples are using 192.168.0.0/16 and you are pinging to 192.168.3.59 - out of the /24 but in the /16.
              I suggest double-check all settings and make sure "/16" "255.255.0.0" is being used everywhere for 192.168.0.0 - particularly the client conf file (it might have an old push route entry that is wrong?)
              And try to ping/traceroute to something in the 192.168.0.1-254 range - if that works then you just have a subnet mask wrong somewhere preventing getting to the higher addresses.

              Hi
              Thanks for the answer ,yes you right this is my mistake its 192.168.0.0/16  ,we have 16bit internal network ,any way the push and route where set correctly but still i don't have routing that LAN (192.168.0.0/16) yet, so when  I am doing tracert to one of those ip's i can see that its not going trough the tunnel
              I attached LAN diagram as requested by Marvosa
              Thanks

              s2ssset.png
              site2sitevpn.png_thumb
              site2sitevpn.png
              s2ssset.png_thumb

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

                I can't see a problem with your screenshots.

                C:\Users\>tracert 192.168.3.59
                
                Tracing route to 192.168.3.59 over a maximum of 30 hops
                
                  1     *        *        *     Request timed out.
                  2  net-xx-x1-1x-1.cust.dsl.vodafone.it [xx-x1-1x]  reports: Destination net
                unreachable.
                
                Trace complete.
                

                That seems really odd. I guess this is from a client inside BRANCH 172.16.1.0/24. In the other successful traceroute, the first hop is the BRANCH pfSense 172.16.1.3 - that should be the default gateway for this BRANCH client. So why doesn't this tracert also go to 172.16.1.3 straight away?
                Are there multiple routers at BRANCH? Maybe the default gateway is something else, and that other router needs to be told that 192.168.0.0/16 is reachable through the pfense VPN?
                Let us know more about the network at BRANCH.

                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
                • T
                  tbaror
                  last edited by

                  @phil.davis:

                  I can't see a problem with your screenshots.

                  C:\Users\>tracert 192.168.3.59
                  
                  Tracing route to 192.168.3.59 over a maximum of 30 hops
                  
                    1     *        *        *     Request timed out.
                    2  net-xx-x1-1x-1.cust.dsl.vodafone.it [xx-x1-1x]  reports: Destination net
                  unreachable.
                  
                  Trace complete.
                  

                  That seems really odd. I guess this is from a client inside BRANCH 172.16.1.0/24. In the other successful traceroute, the first hop is the BRANCH pfSense 172.16.1.3 - that should be the default gateway for this BRANCH client. So why doesn't this tracert also go to 172.16.1.3 straight away?
                  Are there multiple routers at BRANCH? Maybe the default gateway is something else, and that other router needs to be told that 192.168.0.0/16 is reachable through the pfense VPN?
                  Let us know more about the network at BRANCH.

                  Hi Phil,

                  You right they do have second gateway Internet Interface on same firewall , I did force all outgoing destination 192.168.0.0/16 go trough the gateway

                  fastwebnet.it [9x.xx.xx.xx]

                  interface where is tunnel is setup but still i get as follows bellow , tracert from host.
                  now i do see 192.168.0.254 right before the gateway but i don't know from where its coming since the internet interface is set directly with the static 9x.xx.xx.xx ip address
                  In addition when i am doing tracert from firewall itself i do see  and answer from destination  and also verified at diagnostic routes that route exist for destination.
                  Thanks

                  C:\Documents and Settings>tracert 192.168.1.1

                  Tracing route to 192.168.1.1 over a maximum of 30 hops

                  1    <1 ms    <1 ms    <1 ms  192.168.0.254 
                    2    12 ms    12 ms    12 ms  9x-xx-x-x.ipx0.fastwebnet.it [9x.xx.xx.xx]
                    3    12 ms    12 ms    12 ms  10.0.28.69
                    4    12 ms    12 ms    12 ms  10.0.28.69
                    5    12 ms    12 ms    12 ms  10.254.11.17
                    6    *        *        *    Request timed out.
                    7    *        *        *    Request timed out.
                    8    *        *        *    Request timed out.
                    9    *        *        *    Request timed out.
                  10    *        *        *    Request timed out.
                  11    *        *        *    Request timed out.
                  12  ^C

                  tracert from firewall

                  1  10.0.8.1 (10.0.8.1)  211.616 ms  205.635 ms  206.989 ms
                  2  2xx.xxx.xxx.4 (2xx.xxx.xxx.4)  208.586 ms  208.149 ms  209.119 ms

                  172.16.1.3 link#2 UHS 0 0 16384 lo0
                  192.168.0.0/16 10.0.8.1 UGS 0 952 1500 ovpnc2

                  Interfaces
                  WAN_FASTWEB [WAN_FASTWEB is up] 9x.xx.xx.xx 100baseTX <full-duplex>LAN [LAN is up]172.16.1.3 1000baseT <full-duplex>WAN_VODAFONE(DHCP) [WAN_VODAFONE is up]10.10.10.3 |100baseTX</full-duplex></full-duplex>

                  1 Reply Last reply Reply Quote 0
                  • T
                    tbaror
                    last edited by

                    Ok,
                    I think the mystery solved , but still not works :( , i discovered next hop right after external fw leg is 192.168.0.254 so this is why there is no  routing to 192.168.0.0/24
                    but what more mysterious is when i do tracroute from firewall its go trough vpn tunnel  ,but not the case from lan client side
                    Any idea

                    Thanks

                    1 Reply Last reply Reply Quote 0
                    • R
                      rubic
                      last edited by

                      You should not use 'push "route…' and 'Local network' settings in preshared key setup - it doesn't work: http://doc.pfsense.org/index.php/Why_won%27t_OpenVPN_push_routes%3F

                      Clean up advanced options and 'Local network' on both ends and try the following:
                      Remote network: 172.16.1.0/24 - on the server side
                      Remote network: 192.168.0.0/16 (!) - on the client side.

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

                        @tbaror:

                        Ok,
                        I think the mystery solved , but still not works :( , i discovered next hop right after external fw leg is 192.168.0.254 so this is why there is no  routing to 192.168.0.0/24
                        but what more mysterious is when i do tracroute from firewall its go trough vpn tunnel  ,but not the case from lan client side
                        Any idea

                        Thanks

                        IMHO, when you ping/traceroute from a LAN client, the packet goes first to your other gateway. That other gateway knows about 192.168.0.0/24 attached to (or close to) it. So it sends it there.
                        When you ping/traceroute from pfSense, it knows a route to 192.168.0.0/16 across the OpenVPN, so sends it across the OpenVPN.

                        I am finding more and more, rule #1 of designing a private IPv4 network is, never use 192.168.[0-n].0 addresses (where "n" is maybe up to 10 or 20). Then you avoid conflicts with all the default private networks that get in your way when your network map expands.
                        I pick a "random" 10.n.0.0/16 and make /24s out of that - e.g. 10.73.0.0/24 10.73.1.0/24 …
                        IPv6 is much better, with a large chunk of "private" address space to randomly pick from.

                        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
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.