agowa
commented
4 years ago Sorry to be a bit pessimistic here, but this cannot be solved using a middle box.
The only thing that jool could do here is in the case of an IPSec VPN that has the NAT Traversal feature enabled that it could handle half of the connections packages so that they reach the IPSec server. But than the server would try to respond to the IPv4 address which fails if it neither has a locally installed clat nor a IPv4 route to the other peer. See: https://download.huawei.com/mdl/imgDownload?uuid=7884197cc8984788b49e6f294fdcc4cb.png
We're fine with the actual encryption (ESP), but the problem relies in the authenticating part (AH) as the source and destination ip are included in the signature. And that is something that an ALG cannot fix. The only options to work around this would be:
- To patch the IPSec server software to treat the NAT64 address equivalent to the IPv4 address and use that one instead for AH validation. E.g. Packet arrives using NAT64 address, server uses IPv4 address for signature check as well as sends the outbound package with the NAT64 address as destination, but with the IPv4 one used for the signature calculation.
- Create another IPSec session in tunnel mode through the IPv6 only infrastructure to a central point that offers native IPv4 within the tunnel (if the IPSec is not UDP encapsulated these need to be public IPv4 addresses). Basically getting an IPv4 onto the peer.
- Install a clat on the peer, so that it can handle the return traffic (but this still only works with IPSec traffic that is UDP tunneled e.g. NAT-able). The clat will than take care of the necessary address conversion from the IPv4 to the NAT64 one.
That's may be why there is no RFC for it, as nothing that is currently broken could be fixed interim, but need to be done by the peers trying to communicate.
Sites for reference:
ydahhrk
Someone requested this feature in the 2020 survey.
I'm not entirely sure if IPSec can be made to work on a NAT64 through an ALG, and it doesn't look like there's an RFC dealing with it.
I will leave this issue in standby mode until someone helps clarify the situation or the popularity of this bug forces me to personally dig into the entrails of IPSec to develop a proper opinion.