Route IP address through Sonicwall VPN

You can within the SITE TO SITE VPN TUNNEL specification include the IP in question
i.e.
SITE1 allowed access LAN1
SITE2 DENIED ACCESS LAN2

your VPN policy will be to include the IP_inquestion in the SITE2 VPN setting

site2
remote LAN: LAN1 and IP_inquestion

If your VPN setup includes dynamic routing protocol updates, all you would need to do in this case, is advertise the IP/32 to the SITE2 VPN.

The remaining question is whether your Sonicwall VPN will allow the request that came in via the VPN to leave the outside interface.

skullnobrains, I tried the routing method, but it doesn't give me access. I've setup the route from the Site 2(cannot authenticate) LAN to the IP with the gateway as the router on the other side (Site 1). Do i need to add anything to the router on Site 1?
Thanks.

arnold, I tried to setup the VPN as suggested, but I'm not sure I've got the parameters correct on both sides. Site 1 can access the IP address, Site 2 cannot. Since Site 2 can see the IP, but not authenticate to it, I assume I have to add a firewall rule denying access from Site 2 LAN to WAN for the IP. I also added a rule allowing Site 2 LAN to VPN for the IP. I added the IP to the remote network on the Site 2 side of the VPN. I also added a firewall rule allowing VPN to WAN for the IP on the Site 1 side. With these settings, I can't ping the IP from Site 2. Am I missing something?
Thanks.

what you setup is a little unclear to me.

you need the gateway to be the lan address of the other side of the vpn

you can list existing routes on your firewall. the existing routes that are used to reach the network at site1 should serve as a model if your VPN works

assuming that you can normally ping machines from one side of the vpn to the other, nothing should be needed to be set on site 1 in terms of routes. but you may need a firewall rule allowing the corresponding traffic, and you need to apply nat if the site is external to your LAN. it is likely that your firewall is setup to only allow internet access to hosts on site1

for debugging routes, ping is pretty useful : ping the router from a regular host to start with and move on

Actual numbers:
Side that can't authenticate: 10.1.1.xxx with router at 10.1.1.250.
VPN established to site that can authenticate 10.1.2.xxx through 10.1.2.250
IP address with the issue is 216.194.164.150

On 10.1.1 side, route added:
Source: LAN Primary Subnet (10.1.1.0)
Destination: 216.194.164.150
Gateway: 10.1.2.250
Interface: WAN

On the 10.1.2 side Access rule added:
Action: Allow
From Zone: VPN
To Zone: WAN
Service: Any
Source: 10.1.1.XXX
Destination: 216.194.164.150

Still can't ping from 10.1.1 side.

the server at 216.194.164.150 does respond to pings, but i was not really expecting end-to-end pinging to work straightaway

the route looks good, and unless you forgot nat, the rule as well.

can you confirm that you can ping 10.1.2.250 from your source machine ? (this should be the case if the VPN works properly)

can you confirm that on your side, you have a rule that allows that traffic. it seems possible that you only allow traffic through the VPN when it is targeted to the 10.1.2.x network

if yes to both of the above, can you run a packet sniffer on 10.1.2.250 ? do you see packets reaching through the VPN when you try to connect to the web site ? do you see those same packets leaving through the wan interface ? what about return packets ?

I have only default/automatically generated NAT entries. Sould there be something else?
I can ping 10.1.2.250 from the source.
i have a Side2Subnet-VPN to Any-WAN rule on the destination side so it should allow traffic coming through the VPN to access outside IPs.

I'm getting no packets on the 10.1.2.250 side. I think they are being stopped before they even get to the VPN.

if you can ping but http packets don't reach, you probably don't have a rule that allows routing http traffic over the VPN on side1. you can confirm this by sniffing inbound and vpn interface on side1.

if you found a solution to the question you actually posted, you should post it and accept it as a solution. of all people i'm interested

Found another work around for the issue which seems tied to the specific hardware. I believe the answers provided by skullnobrains would have solved the problem.