> On 9 Dec 2016, at 18:32, Bjoern A. Zeeb <[email protected]> > wrote: > > On 9 Dec 2016, at 16:07, Bill Fenner wrote: > >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <[email protected]> wrote: >> >>> Hi All, >>> >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>> >>> Just checking, is there any summary on how VPN clients behaved on the >>> nat64 SSID following the event? >>> >> >> Just an anecdote, not actual information: I have two different ways to >> contact my office VPN server (SSL VPN and IPSEC); neither one worked from >> NAT64. The vendor documentation says that they don't support IPv6 >> transport for the SSL VPN; I do not know what went wrong with the IPSEC >> VPN. The vendor introduced support for IPSEC with v6 transport in their >> newest software, to which we'll upgrade soon; perhaps that upgrade will >> include whatever is required for it to work through NAT64 too. Their >> support matrix still says that even the newest software does not support >> SSL VPN over IPv6. > > That’s maybe for the ipsec wg but while native IPv6 VPN has been working fine > for me for ages, how would a NAT64 policy exchange actually look like (I am > thinking about what is done for IPv4 NAT or double NAT within the same > address family); I doubt that different AFs on each end as part of the > policy are specified to work, so I’d not expect IPsec VPNs to work across a > NAT64 (from a v6 to a v4 endpoint); someone surprise me and say with IKEv2 > you can? Someone surprise me and say with a double NAT64 it can work?
Regardless of IKE version, an IPsec client (and SSL-VPN client as well) will encapsulate the v6 packet within the tunnel. The internal v6 packet will never reach the NAT in any form that the NAT can do anything about. The encapsulating packet (for IPsec) or stream (for SSL) will get translated correctly by the NAT64, but when the other side decrypts the packet, it’s going to be an IPv6 packet. The problem is the destination address, which is the NAT64 address invented by the DNS64. The tunnel endpoint will not know how to deal with that. To get this working, the DNS64 should be on the remote tunnel endpoint or behind it. And this will require that it has an IPv6 address and knows to do the NAT64 translation in cooperation with the tunnel endpoint. I guess this vendor’s IPsec implementation doesn’t do all that. Neither does my employer’s. Yoav _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
