Screen OS

Hi all,

I'm in the process of switching from policy based to route based VPN's for our 30 device (mostly SSG5/20) network. Part of the reason is to make use of OSPF to provide failover for our production network.

I've migrated 5 devices fo far, leaving their other policy based VPN's and routes in place, and upon inital configuration, all 5 mesh fully. However, after less than 24 hours, all but one has a full mesh and the others insist on routing via the other routers and showing ExStart status on most tunnels.

I setup the network using this KB document from Juniper, including both internal and tunnel interfaces into area 0.

http://kb.juniper.net/kb/documents/public/VPN/Full_Mesh_VPN_w_OSPF_ver_1_0.pdf

I've been through the config on all 5 boxes now and cannot find anything that looks out of place but I just can't seem to get them to mesh again.

Based on the KB above, all 5 sites have a dedicated tunnel interface in a new zone. Each tunnel interface has a unique private IP assigned to it and the VPN's are bound to the tunnel interface. The NHTB's are in place pointing to the appropriate VPN and static routes are in place for the private IP's to point to the remote gateway public addresses via the tunnel interface. Cost on all interfaces are set at 1 (bandwidth does vary between sites but I believe hop count should also be practical if all costs are set to 1). The one site that seems to be holding onto the full mesh has the second lowest bandwidth of any site too.

Could anyone point me in the right direction?

Martin

Did you create the static /32 route for each of the remote site tunnel interfaces to their own address?

This route is mentioned in the document you link, and without it some of the sites can fall into exstart on the ospf.  The issue seems to be that on nhtb interfaces it sometime returns via a different site creating asymetrical routing.

Hi spuluka,

Big  thanks for the quick reply.

If my understanding of the document is correct I believe I have as follows :-

set interface tunnel.5 nhtb 172.24.21.22 vpn "VPN-A"

set interface tunnel.5 nhtb 172.24.21.32 vpn "VPN-B"

set interface tunnel.5 nhtb 172.24.21.34 vpn "VPN-C"

set interface tunnel.5 nhtb 172.24.21.26 vpn "VPN-D"

set route 172.24.21.22/32 interface tunnel.5 gateway X.X.X.X
set route 172.24.21.32/32 interface tunnel.5 gateway Y.Y.Y.Y
set route 172.24.21.34/32 interface tunnel.5 gateway Z.Z.Z.Z
set route 172.24.21.26/32 interface tunnel.5 gateway C.C.C.C

The 172.24.21.0/24 subnet is what I have assigned to the tunnel interfaces on each Juniper and these are then routed to the public external IP of the remote SSG's. All of the VPN tunnels come up OK so it looks like the VPN portion is working, it's just when OSPF goes to work that I start  getting odd issues.

Thanks and best regards,

Martin

set route 172.24.21.22/32 interface tunnel.5 gateway 172.24.21.22
set route 172.24.21.32/32 interface tunnel.5 gateway 172.24.21.32
set route 172.24.21.34/32 interface tunnel.5 gateway 172.24.21.34
set route 172.24.21.26/32 interface tunnel.5 gateway 172.24.21.26

 These are the tunnel interface ip addresses of the adjacent sites.  And the gateway address should be the same as the route /32.

Another item to confirm is that your tunnel interface is setup as point-to-multipoint in the ospf property.

set interface tunnel.5 protocol ospf link-type p2mp

Hi Steve,

Just looking at rebuilding the links now and I've noticed that having removed OSPF to be able to remove the old routes, then adding OSPF again, the routes are coming up without the static /32 routes being in place and seem to be settling down. I'll get all of the SSG's rebuild first to confirm but it's looking like they don't need these extra routes.

Would you expect this sort of behaviour?

Best regards,

Martin

I originally built the full mesh grid without the /32 routes but had to add them in to keep them from falling into exstart mode.

Hi Steve,

Doing further testing it looks like all teh links were happy to come up without the /32 routes but they wouldn't fail over if I broke a VPN link to simulate a failure. I've added the /32 routes back in now and I'm testing again.

Best regards,

Martin

Hi Steve,

Just to confirm, it looks like you nailed it with the /32 routes. All the links are stable and are failing over when I'm manually breaking a VPN link. The routes seem stable and are failing over. The routing's sometimes asymetric when in failover which is a little confusing but the client connections are happy.

Thanks again for your help.

Martin