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?