ROUTE BASED VPN QRY WITH SRC NAT

[technicalsupport]

I am trying to configure a ROUTE BASED VPN in TUNNEL MODE.

I have a unit with 2 interfaces configured for Layer 3 operation with the following zones.

L3-PRIV (ZONE) = My private internal network.

L3-PUBL (ZONE) = My public outside network.

I created a numbered ip TUNNEL.10 interface which is also defined in its own zone called L3-VPN10.

I have 1 Virtual Router which is shared amongst all interfaces.

I have configured all the appropiate routing for inside and outside networks and additional routes to egreess the traffic that reuiqres encryption out via TUNNEL.10

I have successfully configured the IKE and CRYPTO and the IPSEC TUNNEL and IKE are both UP UP.

I have configured a NAT policy to change the source address and replace it with the source TUNNEL.10 ip address where the destination is = to the network that requires encryption.

In addition to the above I have configured the appropiate Source Zones - Destimation Zones policies which for troubleshooting purposes is set to ANY ANY.

From my log I can see traffic egressing the L3-VPN10 zone, but TCP connections are showing incomplete. The remote end can see my traffic, but I dont see any return traffic comming back and there are no Deny matches on the logs. The PEERS have come from a working tunnel between 2 netscreens, so I got the remote end to just change their PEER to match my PALO UNIT so I know that this works, but not on the PALO.

Help ....is there any known issue with route VPNs.

Do I need to set the proxy ID? to be the source and destion subnet as this a bit like a point to point conenction.

Currenty I have this set to 0.0.0.0/0 0.0.0.0/0 as I am using a static route to enter the tunnel. The tunnel ip is basically a /29 subnet which is in essence is the network that is being encrypted. The remote end is also set to a route based VPN.

Help!!!!!!!!

[swhyte]

Hello,

great problem description. There is no issue with route based vpn.

From your problem description this should work just fine UNLESS, there is a routing issue on the other side of the tunnel.

Especially since you are getting incompletes, it sounds like traffic is going across the tunnel from the Paloalto side but nothing is returning.

So since the remote end can see your traffic, make sure that that return traffic from the remote end is pointed to the device that is the other side of the tunnel.

So in other words if your configuration is like this:

client<----->Paloalto<----->tunnel<------>the device terminating the tunnel<----------->server on remote network

make sure and pay attention to your NAT's and routes. The "server on remote network" traffic that is destined for the "client" should be routed back to "the device terminating the tunnel".

thanks,

Stephen

[technicalsupport]

Thanks for taking the time out to reply. Its been a while.

1. First thing to say is that routing at the remote end is not a problem as the remote configuration is a working one. The only element of that configuration that has chagned is the PEER address of the IKE GATEWAY.

2. With respect to NAT I can seen in the traffic logs that NAT is taking place and validated routing via the test routing fib-lookup virtual-router vr-default ip command so this apprears to work.

3. But the gut feel is that it has something to do with NAT. Are there any debugging commands that shows you the NAT session table. In the cisco world used show xlate, .

4. I ended up using Proxy entries which contains the NAT SRC ADDR/29 - DST ADDR/32 and I am using the interface ip as part of the SRC NAT policy. This subnet support the end to end tunnel a bit like an end to end (point to point) ip serial link over a WAN albeit with a few more addresses in the range.

5. I also check for MTU path discovery which the Palo seems to identify as 1460.

Any ideas on how I can effectively troubleshoot this one? I may have to get hold of a Netscreen LAB it. If you need details am happy to wiz over a viso digram of what I am try to do with screen shots etc. Its gota be somthing simple.

PS The client can see return traffic going back into the tunnel, but I dont see any deny / drops / discards.

[technicalsupport]

session     203314
        c2s flow:
                source:   SRC[L3-PRIV]
                dst:      DST
                sport:    19551         dport:    80
                proto:    6             dir:      c2s
                state:    INIT          type:     FLOW
                ipver:    4
                src-user: +++++
                dst-user: unknown
        s2c flow:
                source:  DST[L3-VPN10]
                dst:      SRC NAT
                sport:    80            dport:    64516
                proto:    6             dir:      s2c
                state:    INIT          type:     FLOW
                ipver:    4
                src-user: unknown
                dst-user: ++++++
                qos node: ethernet1/1, qos member N/A Qid 0
        start time            : Thu Jul  8 19:03:36 2010
        timeout               : 5 sec
        total byte count      : 124
        layer7 packet count   : 2
        vsys                  : vsys1
        application           : incomplete
        rule                  : APP Allow General

The ports used in the session dont seem to match src port 19551 sould equal dst port 64516 ????

[pieters]

didn't read the whole thread so I might be missing something but I had a similar issue when I tried putting the tunnel interface in its own zone thinking it would be safer and give more control. Tunnel was up but I couldn't get traffic to flow through.

Try moving it into the same zone as your other external ip adresses (typically 'untrust'). That worked for me.