Transparenlty NATing IPsec traffic to other device

[ifstciss]

Hello,

We have an issue with forwarding an IPsec connection to a VPN device behind the PAN-OS FW.

So the setup is supposed to be the following:
* PAN-OS is using outside interface 192.168.1.1/24
* 192.168.1.2 is an address with DNAT to 10.10.10.1 on an internal vlan

Note that the FW also processes IPsec VPNs itself on its own IP 192.168.1.1.

NAT rule:
* src zone: outside
* dst zone: outside
* original src address: remote ipsec gw
* original dst address: 192.168.1.2
* translated src address: keep
* translated dst address: 10.10.10.1

There is a security policy of course
* src zone: outside
* dst zone: inside
* src address: remote ipsec gw
* dst address: 192.168.1.2
* app: ipsec

Using packet capture, I see that the packet is captured in receive, fw, and drop stages.

Digging further using dataplane debug

Packet received at fastpath stage, tag 1338, type ATOMIC
Packet info: len 254 port 19 interface 261 vsys 1
wqe index 216243 packet 0x0x80000003144648ca, HA: 0, IC: 0
Packet decoded dump:
L2: 00:04:96:af:51:02->00:1b:17:00:03:13, VLAN 502 (0x8100 0x01f6), type 0x0800
IP: 1.2.3.4->192.168.1.2, protocol 17
version 4, ihl 5, tos 0x00, len 236,
id 34594, frag_off 0x0000, ttl 59, checksum 58234(0xe37a)
UDP: sport 500, dport 500, len 216, checksum 27049
Forwarding lookup, ingress interface 261
L3 mode, router 2
Route lookup in router 2, IP 192.168.1.2
Route found, interface ethernet1/4.508, zone 3
Resolve ARP for IP 192.168.1.2 on interface ethernet1/4.508
ARP pending
Packet dropped, no ARP

Why would it try to route or resolve ARP when it is supposed to be responsible for that address itself, e.g. according to https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-admin/networking/nat/nat-policy-rules/proxy-arp...

I have the feeling that all of this stopped working once PAN-OS FW started processing IPsec VPNs itself on 192.168.1.1.

PAN-OS is 10.0.8

Thanks,

Marki

[ifstciss · Accepted solution]

Never mind, session 1338 seems to have been "stuck".

Probably at initial creation of the session (some time ago), the connection didn't work because some other config was incorrect, but the flow was still created and remained cached in fastpath state. Since the VPN gateways just continue trying to connect the bad session/flow was never purged or reinitialized.

I have removed it manually from the session browser and the flow was now created successfully and the VPN is successfully connected.

Also "show arp all" no longer shows 192.168.1.2 as "(incomplete)". In fact it no longer shows that address at all, which seems to be a good sign in this case.

Happy holidays 🙂