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
Sorry, should have mentioned SG1.1 and SG1.2 are on the same network, 192.168.1.0
ipsec has the details of both subnets at each location
just that 192.168.1.0 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
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.
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, 192.168.2.0/24, GW being SG1.1's IP.
So not sure where/what other routes I need to do?
Thanks for the help
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 192.168.2.0/24 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 192.168.2.0/24 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 192.168.2.0/24 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.
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.
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.
Thanks for the tip on getting more data out, will give it a go and post back the results.
any success on that?
i would suggest first to go with a gre tunnel instead of a routing table in front of it...