About 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-for-nat-address-pools.html   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 ... View more