I am trying to use NAT and an IPsec tunnel interface in the same VPP instance. 
I have a hardware interface that has an IPv4 address configured on it. That 
same address is the local address for an IPsec tunnel interface.

When I bring the IPsec tunnel interface up, I can send packets and receive 
replies across the tunnel. When I subsequently add the IPv4 address of the 
hardware interface to a NAT pool and set the hardware interface as an outside 
interface, I don’t see replies to packets sent across the tunnel anymore. The 
outbound packets reach the other side of the tunnel and a reply comes back, but 
nat44-out2in drops the inbound ESP packet because there is no matching session. 
I thought enabling NAT forwarding would allow the inbound ESP packets to pass 
through to the FIB lookup and make their way to the IPsec nodes. That didn’t 
work because ESP is an unknown protocol (an IP protocol other than TCP, UDP, 
ICMP, ICMP6). There’s no check for whether NAT forwarding is enabled for 
packets that have an unknown protocol.

If I put a check for forwarding_enabled around the places in out2in where a 
packet with an unknown protocol has it’s next node set to error-drop, the 
inbound ESP is allowed and gets handled properly. I submitted that patch as 
https://gerrit.fd.io/r/#/c/10940/ <https://gerrit.fd.io/r/#/c/10940/>. I’m not 
sure if that is the right or complete solution though. If anyone has any 
thoughts on whether that’s ok or better ideas for how to make this work, I’m 
all ears. Or at least partially ears.

One thing that I was wavering on is whether inbound ESP (and possibly other 
protocols - GRE, L2TP) should work without enabling NAT forwarding. I.e. should 
there be a check before discarding a packet with an unknown protocol to see 
whether that protocol is handled locally?


Reply via email to