Transparenlty NATing IPsec traffic to other device

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Transparenlty NATing IPsec traffic to other device

L1 Bithead

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

1 accepted solution

Accepted Solutions

L1 Bithead

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 🙂

View solution in original post

1 REPLY 1

L1 Bithead

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 🙂

  • 1 accepted solution
  • 2172 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!