- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-25-2021 07:21 AM
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
12-25-2021 08:16 AM
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 🙂
12-25-2021 08:16 AM
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 🙂
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!