routing vpn traffic into procurve

[Ryan_D]

Hello,

I am having difficulty with routing between my SonicWALL 3060 (ip 192.7.221.1) and our 5412zl. I have vlans 221 (192.7.221.0/24 - the main uplink port to/from 5412 and SonicWALL), 224 (192.7.224.0/24) for servers and 226 (192.7.226.0/24) for workstations set up on the 5412. I have static routes in the SonicWALL defined as follows:

224 static route:
destination network: 192.7.224.0
subnet mask: 255.255.255.0
gateway: 192.7.221.254
interface: LAN

226 static route:
destination network: 192.7.226.0
subnet mask: 255.255.255.0
gateway: 192.7.221.254
interface: LAN

192.7.221.254 is the gateway of the 221 subnet that has the main uplink port to the SonicWALL (IP 192.7.221.1).

These routes work fine for internal routing as well as routing between the ProCurve and SonicWALL, but the problem lies when we try to establish our site to site vpn tunnels.

The first site we are trying to establish has internal network of 192.168.1.0/24. I have checked the logs on the remote vpn appliance via external IP and it's showing items like "UDP packet dropped" from our main SonicWALL as the source and the remote site as the destination. The remote sites are given local DHCP addresses on their local network (in this case, 192.168.1.0)

Do I need to set up an additional route in the ProCurve to allow such traffic through or would I need to make another static route on the SonicWALL for the 192.168.1.0/24 network (and every other remote job site)?

I currently only have a default route set up (ip route 0.0.0.0 0.0.0.0 192.7.221.1) on the ProCurve.

When I try to ping 192.168.1.1 (remote site SonicWALL ip) from our network, I get "Reply from 192.7.221.254: TTL expired in transit." Is that because the ProCurve isn't routing correctly or the SonicWALL isn't routing correctly?

Thanks for your help guys, great forum!!

Ryan

[Pieter 't Hart]

Hi Ryan,
We've met before on antoher post.

I assume the sonic functions as a firewall.
If you don't do anything else, you just have a tunnel wich ends at both sonic's.
You probably need to setup rules to allow access between these networks.
You should check the sonic (both local and remote) so it forwards 224 and 226 (in cisco terms "interresting trafic") through this tunnel and not to a default gateway.
This is not just a routing statement it may be called a crypto map?

[Leonard Davison]

Ryan,

I am assuming you have all the networks defined in the remote sonicwall correctly (IE: 192.7.221.0/24 192.7.224.0/24 and 192.7.226.0/24)

Is 192.7.221.254 the procurve switch or another box? If it is another box, I would point the procurve at it, not the sonicwall as the default gateway.

Does 192.7.221.254 know where 192.168.1.0/24 is?

[Ryan_D]

Hi guys, thank you both for responding to my question and I apologize for the delayed reply.

UPDATE:

We created a new address group on the remote SonicWALL and defined the 224 AND the 226 address objects as members belonging to an address group. Prior to this change, all vpn traffic could reach 224 but not 226 (because 224 was the only address object defined). By doing this, apparently there are now 2 vpn tunnels, one for the 224 network and one for 226 (SEE ATTACHMENT).

I don't see why we couldn't just have one tunnel and pass 224 and 226 traffic across that one tunnel and have it routed appropriately on both ends. We obviously still need to play around with the routing policy on the remote SonicWALL to make this work - any advice is appreciated. :)

Pieter: Your assumption is correct, the SonicWALL is our firewall.

Leonard: We did have all the routes configured in the local SonicWALL correctly, but the change above had to be made on the remote SonicWALL to even pass traffic to 226. 192.7.221.254 is the gateway for vlan221 - port A2 is the only port in vlan221 and is the main trunk feeding the ProCurve from the SonicWALL).

Thank you again to both of you for your assistance!

Ryan

[Pieter 't Hart]

As for this info from the manual :

Step 6
Select a local network from Choose local network from list if a specific local network can access the VPN tunnel. If traffic can originate from any local network, select Any Address. Use this option is a peer has Use this VPN Tunnel as default route for all Internet traffic selected. You can only configure one SA to use this setting. Alternatively, select Choose Destination network from list, and select the address object or group.

Using a group for the destination network (remote sonic) should not result in setting up two tunnels.
But i think you should match it with a group on the local sonic for the "local network".

Does the option "default route for all trafic" make a difference?

ps. in the screendump the "gateway" for both networks is a "black spot" does this mean no gateway is configured?
If so it seems logical the remote sonic tries to reach both the 224 and 226 network directly, wich does mean separate links = separate tunnels.

[Ryan_D]

Hello again!

When the remote site requests information on any subnet back at the home office (224.0, 226.0, etc) we would like them to have access to whichever without multiple vpn tunnels. We only want their lan traffic to enter the vpn, not the internet traffic (they use their own internet provider for that). We don't have "default route for all traffic" enabled because of what was explained above.

I suppose we could try it for testing purposes but our WAN link is slow enough without having every site route through it. :)

The default gateway is defined - it is our SonicWALL external IP from our ISP.

We haven't noticed any slowness because of the multiple vpn tunnels from our testing jobsite, but we will be able to do more testing when our additional testing equipment comes in this afternoon.

Thanks!
Ryan

[Pieter 't Hart]

"The default gateway is defined - it is our SonicWALL external IP from our ISP."

I'd say this is not correct.

The VPN-tunnel is setup between the public ip-adresses.
You setup a VPN to virtually patch a cable between your private networks.
Thus for your own network (local or remote), you must not setup the public adress as the default gateway!
I suggest it should be the switch that routes between 224 and 226.

[Ryan_D]

That screenshot is from a SonicWALL on a remote site. The vpn tunnel default gateway for that site is the external IP of our local SonicWALL. How would the remote SonicWALL know where to look to establish the tunnel otherwise?

We have our main uplink to the ProCurve via 221vlan (GW is 221.254) and any traffic coming in over the vpn needs to access 224 (GW 224.254), 226, etc. You're saying we need to make the default vpn gateway 221.254 instead of our SonicWALL external IP?

Ryan

[Pieter 't Hart]

I'll try to look up an example to make it clear.

In short, you need to separate traffic needed to establish VPN-tunnel, wich is setup between the public adresses

and traffic that passes through the tunnel, wich is between two private networks and at this level have nothing to do with these public adresses.

If you specify the sonic outside adress as default gateway the gateway falls outside the subnets used, so it cannot be reached.
NB! A gateway is a next-hop router, that needs to be on the same subnet!.