9 Replies Latest reply on Dec 23, 2011 9:17 AM by martin-franke

    Route across two SG's to get to another network

      We have two locations, location 1 ( and location 2 (


      Location 1 has 2x SG's, one for servers and one for staff internet, we'll call these SG1.1 and SG1.2 respectively.

      Location 2 has 1x SG, we'll call this SG2.1


      There is an ipsec vpn between SG1.1 and SG2.1


      The servers that use the gateway on SG1.1 can see and do anything on the 2nd network.

      I added a static route on SG1.2 being and input the gateway IP of SG1.1


      But my staff that use SG1.2 gateway can't connect or use applications at location 2.

      Ping and Trace's work and i can see it go SG1.2, SG1.1, SG2.1 but opening a website or RDP at remote location just fails.


      Can this even work?





        • 1. Re: Route across two SG's to get to another network

          ipsec needs to be informed about the other subnets traffic traffic and to setup the appropiate routes as per Knowledge Base article number KB62288


          you will then only need the one static route on 1.2

          • 2. Re: Route across two SG's to get to another network

            Hi Ross,

            Sorry, should have mentioned SG1.1 and SG1.2 are on the same network,


            ipsec has the details of both subnets at each location


            just that network has 2 gateways via seperate SG's, but i'm just trying to route some traffic from 1.2 via 1.1 as that is where the vpn connection is

            network diagram - http://imageshack.us/photo/my-images/838/routesg1.jpg/


            Thanks for your help



            • 3. Re: Route across two SG's to get to another network



              If the machines sitting behind SG1.2 are using SG1.2 as its default gateway I imagine that the problem is that when these machines receive an RDP connection request over the SG2.1-SG1.1 VPN they are looking at the source IP address and are then trying to respond to the connection via SG1.2 instead of SG1.1 and SG1.2 has no idea how to get traffic back to the source subnet.


              By either entering manual static routes on the machines in question to point traffic intended for the 192.168.2.x network to the internal IP address of SG1.1 or by entering a single route on SG1.2 point this traffic back to SG1.2 this should allow the responses to correctly pass back via SG1.1.


              SG1.1 should then recognise the fact that the source IP (192.168.2.x) is located on the other end of the VPN and will send the traffic back over this link.


              I too have a multi-Firewall environment at my office and have been able to solve this by performing either of these tasks.



              • 4. Re: Route across two SG's to get to another network

                Hi Phil,

                Ok so with the static routes, would prefer to try and do this at the router level to keep it simple and more manageable. I can confirm adding a static route to my PC does work as in your instructions.


                So on my SG1.2 I already have a static route installed as target,, GW being SG1.1's IP.

                So not sure where/what other routes I need to do?


                Thanks for the help

                • 5. Re: Route across two SG's to get to another network

                  Art - each to their own when it comes to how to do it. But, I tend to go with the 'path of least resistance' and would therefore go with a single static route on SG1.2 over needing to apply individual routes to each piece of kit on the network which you need to access from the subnet.


                  Reading back through the history of this thread it would seem that you have already entered a static route on SG1.2 telling it to route all traffic for the back via SG1.1. Strictly speaking this should work for everything - not just ping and traceroute. Or, as I would put it, if it works for ping and traceroute I see no reason why it shouldn't work for everything else. Maybe you should look at the target machines and see if, for any reason, they are choosing not to accept connections from the subnet for the likes of RDP.


                  However, it may be worth seeing if by adding an explicit route to one of the machines in question it makes any difference. If it doesn't then I'd put my money on the target machine being the cause of the problem and maybe personal firewall restrictions (which aren't affecting ping and ICMP traffic) are preventing the RDP requests from being processed.



                  • 6. Re: Route across two SG's to get to another network

                    Hey Phil,

                    Yes, have the static route at 1.2 pointing .2.0/24 to 1.1 and so yes, would have thought if the ping/tracert is working then it should be fine but alas it is not.


                    The static route on my PC allows me to use RDP to the target machines fine but that is taking out the jump from 2.1 to 1.1 where the problem seems to lie. Just not sure how to get some logging happening for these connections to see what is happening.

                    It all looks like it should work, but just isn't.

                    • 7. Re: Route across two SG's to get to another network

                      OK - I would put an explicit static route on the target server (just temporarily) for testing purposes.


                      Next, I'd establish an SSH connection to SG1.1 and run a tcpdump on the internal interface filtering for traffic coming from the client machine.


                      tcpdump -npi eth0 host <client_IP_Address>


                      Try to establish an RDP connection from the <client_IP_Address> in question and watch the tcpdump output. All things being equal, you should see output demonstrating bi-directional traffic. If you only see connections originating from the client machine then the return traffic is never making it's way back. By creating the explicit static route on the target server, you are ruling SG1.2 out of the equation. Therefore if the tcpdump doesn't show any return traffic, this would confirm to me that it's the server you are trying to RDP to which is at fault.



                      • 8. Re: Route across two SG's to get to another network

                        Hey Phil,

                        Thanks for the tip on getting more data out, will give it a go and post back the results.

                        • 9. Re: Route across two SG's to get to another network



                          any success on that?

                          i would suggest first to go with a gre tunnel instead of a routing table in front of it...