Hi, 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? Thanks, -Matt
