Screen OS

I have a Sonicwall NSA2400 at the main site and a SSG20 at the remote site.  The main site has two subnets and the remote has one.

I have created a VPN on both sides and I can make it work using one of the subnets at the main site but not both.  I believe I am using a policy based approach from a Juniper point of view.

The tunnel fails when I add multiple subnets to the source in the policy, but works when I only have the one subnet.  I have more experience with Sonicwall and the subnets assigned to the VPN are correct so it must be my lack of knowledge on how to handle this in ScreenOS.

Can anyone give me some pointers please?

Chris

Hi Chris,

From my personal experience route based VPN would be much better option for you.

Using Route based VPN you have to create correct proxy-id on both end of the tunnel and that should work fine.

For example:

Juniper SSG20   --------------------------------- Sonicwal NSA2400

X.X.X.X/24          --------------------------------- Z.Z.Z.Z/24

Y.Y.Y.Y/24          --------------------------------- Z.Z.Z.Z/24

This will have to match on both ends otherwise your tunnel will never come up.

Remember to create correct policy as well.

Thanks for the reply and suggestion.

My next question is how?  Are there any examples of creating a Route based VPN via the web interface?  I can see lots of CLI commands but would be easier to use the web interface.

Ok forget my last post, I removed the original policy based VPN and gateway then connected via SSH and added the route based VPN using the settings here: http://kb.juniper.net/InfoCenter/index?page=content&id=KB4147

Now I have the SA connecting but no traffic flowing.  I have added two routes for my remote subnets to the SSG but no traffic.

This is what I have been using 

http://kb.juniper.net/InfoCenter/index?page=content&id=KB8402

Have you created tunnel interface for you route based VPN?

You need to have tunnel interface binded to you Phase2, then routes in your routing table with next hop pointing to that tunnel interface, policy from Trust --> Untrust or other direction too and remember about Proxy IDs in Phase2 configuration otherwise you won't be able to see any traffic

"Have you created tunnel interface for you route based VPN?"

Yes

"You need to have tunnel interface binded to you Phase2"

Not sure- how do I do/check this?

"then routes in your routing table with next hop pointing to that tunnel interface"

Yes

"policy from Trust --> Untrust or other direction too"

Yes, this time action set to Permit rather than Tunnel I presume?

"remember about Proxy IDs in Phase2 configuration otherwise you won't be able to see any traffic"

The only proxy IDs I have configured is to link them to the AutoIKE VPN object.

Initially I am only trying to connect to the primary LAN subnet on the Sonicwall so no multiple subnets in play.

The tunnel interface is in trust zone  and bound to ethernet0/0 interface.  It shows status as down but the vpn sa status is active.

Hi Chris,

Go to VPNs --> AutoKey IKE --> Edit --> Advanced --> Bind to --> Tunnel Interface --> from drop down menu select your tunnel interface

Is your port Ethernet0/0 in Trust or Untrust zone??

Ok, yes that is already configured then.

ethernet0/0 (WAN) is in the untrust zone.

Ok what is in your proxy id  then??

VPNs --> AutoKey IKE --> Proxy ID 

Currently just one entry:

Local: trust (SSG LAN Subnet)

Remote: untrust (Sonic LAN Subnet)

Service: ANY

That fine as long as it match the other end.

So is your tunnel currently UP??

you can check it from cli by typing "get sa | inc X.X.X.X"

where X.X.X.X is the public address of the remote end (where the tunnel terminates).

Don't worry about the tunnel interface. It's always says Inactive for some reason...

There are Active SA's on the SSG and the Sonic show the tunnel as being up.  I ping from the Sonic LAN to the SSG LAN and can see packets going out of the Sonic but nothing coming back.

Must be down to the routing or policies on the SSG.

Route add to SSG:

IP/Netmask: Sonic LAN Subnet

Gateway: <blank>

Interface: tunnel.1

Policies:

Trust to Untrust:

Source: SSG LAN Subnet

Destination: Sonic LAN Subnet

Service: ANY

Action: PERMIT

Reversed for Untrust to Trust.

For some reason the route I've added for the Sonic LAN sits below the default route in the routing table.

Does this mean it never reaches the custom route?  How do I move it up above the defalt route?

Currently just one entry:

Local: trust (SSG LAN Subnet)

Remote: untrust (Sonic LAN Subnet)

Service: ANY

 When you have multiple subnets you need to create a separate pair of proxy-id for each connecting pair of subnets.

For example:

Sonicwall local group has:

192.168.1.0/24

192.168.2.0/24

Sonicwall remote group has:

172.16.1.0/24

172.16.2.0/24

Your proxy-id pairs are:

192.168.1.0/24 - 172.16.1.0/24

192.168.1.0/24 - 172.16.2.0/24

192.168.2.0/24 - 172.16.1.0/24

192.168.2.0/24 - 172.16.2.0/24

For some reason the route I've added for the Sonic LAN sits below the default route in the routing table.

Does this mean it never reaches the custom route?  How do I move it up above the defalt route?

 The order does not matter.  Routing match is based on the best match for the route, so the more specific route will take precedence as long as both are active.

The active routes have an * in front of them.

I have simplified this down to just connecting a single subnet on the Sonic side to a single subnet on the SSG side so I only have one entry as I can't get the route based tunnel to pass traffic.

The Sonic shows the tunnel is established and the SSG shows there are Active SAs but the Link is Down.

Thanks for clarifying that the route order does not matter.  The route I added for the Sonic LAN does not have a * next to it so it is not active (I don't know why).

Ok, I found a troubleshooting article on the Juniper KB (http://kb.juniper.net/InfoCenter/index?page=content&id=KB9520) which in step 3 asks whether the VPN Monitor 'Optimized' feature is enabled.  It wasn't but as soon as it was the traffic began to flow!!

I then added the second subnet to the proxy-id, policies and route and the VPN works as required.

Many thanks for your help last week and over the weekend.