Software VPN over Policy Based Tunnel

[James_B]

I have a NS-25 at my data center that has the following relevant roles

1. Tunnels to all my sites (NS-5GT's)
2. A tunnel to an external site (Cisco PIX)
3. Policy-based tunnels for all my sites to the external site
4. Accepts incoming connections from NetScreen-Remote clients

All the sites can communicate with each other and the Cisco PIX.  However, I cannot get the Remote software connections to connect to the PIX.  They can connect to all my sites, just not the external one.

Please see the attached diagram to better understand.

I'm unsure if I'm missing a required route, policy or both.  I've tried adding each but haven't found the magic combination to make this work.  It used to work, no special Remote policy required, but no longer.  I'm not sure what changed and I have no control over the PIX side.

Basically I just need to know how it SHOULD be setup so I can cajole the PIX people into helping me get it running.

Any help is appreciated.

Thanks,
James

[AndyC]

Hi,

Can you do a debug flow basic on the NS25 to see if it is seeing the traffic from the Remote clients destined for the Cisco and what it is doing with the traffic. Here is a link on how to do a debug.

http://forums.juniper.net/jnet/board/message?board.id=Firewalls&thread.id=2719

Regards

Andy

[James_B]

Thanks Andy,

The results are a little overwhelming.  I'm filtering by the source IP of the client 172.16.3.x 

Then I'm pinging 10.10.10.5

I can't see the 10. address in the debug at all.  The only thing I think is corresponding to my pings is this message.

do not support multiple DIP in loopback session. pak dropped

It seems to correspond to the number of pings I send.

Does that mean something to you? 

Thanks,

James

[AndyC]

Hi,

Can you post your config from your ns25, mask any sensitive data.

Regards

Andy

[James_B]

Gladly, thanks again.

James

[AndyC]

Hi,

I think it is a route entry problem.

You have 2 route entries 

set route  10.10.10.0/24 interface ethernet4 preference 20
set route  10.10.10.0/24 interface tunnel.1 preference 40

So what that would say to me that traffic destined for 10.10.10.0/24 network isnt going to be passed into the tunnel.1 to go down the VPN, it is getting sent out eth4. That is because the eth4 route entry has a lower preference.

Try removing or changing the prefernce to a higher number than 40 for the route

set route  10.10.10.0/24 interface ethernet4 preference 20

Or lot me know if there is a reason for it to be there.

Regards

Andy

Message Edited by AndyC on 09-19-2008 03:27 PM

[James_B]

Tunnel.1 goes to one of my internal sites, not the PIX.  The PIX does not have an actual tunnel interface assigned to it, it's purely policy based.

The route to ethernet4 does work, it works for all the other locations to get over the policy based tunnels.  The second route through Tunnel.1 is a backup (that also works) for when the policy based tunnel fails.

Any other thoughts, I really appreciate your help.

James

[AndyC · Accepted solution]

Hi,

The policy that you have got for the VPN client for the 10.10.10.0 network wont work.

set policy id 74 from "Trust" to "Untrust"  "10.10.10.0/24" "Dial-Up VPN" "ANY" nat src tunnel vpn "Example_VPN_Primary" id 104 

The reason for this is that the VPN terminates on the Untrust zone and then when the firewall does a look up for the 10.10.10.0/24 network it will see that it is out eth4 from the routing table which is the Untrust. So the policy would need to be Untrust to Untrust for the policy to be hit.

The problem then is that you wouldnt be able to hit the policy of trust to untrust for the policy based vpn to the remote site.

What you need to do to get this to work is to create a route based VPN for the Dialup vpns, terminate them on a tunnel interface on the trust zone and then they will be able to hit the policy based vpns as required and work as you want it to.

Hope this helps

Andy

[James_B]

Andy, you're the best!

A route-based VPN terminating on a tunnel in the trust zone is exactly what was required.

Thanks for all your help,

James