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

      Diagram and question are unclear…. please re-draw network map and restate question.

      Are you trying to access 192.168.0.0 on the client-side or server-side?

      Post server1.conf and client1.conf.

      1 Reply Last reply Reply Quote 0
      • 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.