So, I have an established IPSec Site to Site tunnel.
Site A has a SonicWall, Site B has a EdgeRouter.
The first tunnel consists of Site A's NATed ips to Site B's NATed ips.
Everything works as expected.
Next, I have a public IP range that Site B needs to access, but, requests need to look like they have come from Site A. When I set up this tunnel, I can just see traffic drop at the gateway.
I can't access any of these ips. Due to the fact that it works fine in the same config for lan to lan, I believe it could be a NAT issue - but I am not certain, nor know how to diagnose further.
This could be a red herring as I wasn't very confident... I have tried putting in "allow all" rules on VPN>WAN/WAN>VPN, then filter to an individual IP, then ping it from site B... I see dropped packets.
Can anyone offer any advice here?
If I understand your question, you are trying to do this:
Server A - Router A - VPN - Router B - Site B
You need Site B to be able to access Server A (which is a public IP) over the VPN, but you need the source address to look like it is coming from Site A?
You'll need to specify traffic going to Server A to go over the VPN on Router B. On Router A, you'll need to specify the return traffic to go over the VPN. Next, on Router A, you'll need to configure the NAT rule, to change the SRC IP of the traffic coming from Site B and going to Server A to an IP address that Server A will accept.
So, you just need to route requests to a certain range on the Internet via the tunnel? Can you add a static route for that range?
As a workaround, set up a proxy server at Site A and have machines at Site B use that for the certain sites.
Think simpler!
To come back to an old question I posted:
The answer is... Get a new router!
I wasted far too much time on this... It turns out that MANY off the shelf routers, just can't cope. Sonicwall and Juniper are just a few that failed.
The problem is, you have to define your WAN and LAN, and IPSEC/VPN interfaces are attached to WAN, then, if there is a bit of crossover or you need a setup out of the ordinary, it just fails and can't route properly.
In the end, I found Vyatta and EdgeOS (fork from Vyatta) handle this setup brilliantly, you simply state which subnets to forward, which interface the tunnel should be on - and it just works as expected.