Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 09 Dec 2016 16:32:34 +0000

On 9 Dec 2016, at 16:07, Bill Fenner wrote:

> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <[email-masked]> 
> 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?

/bz

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 9 Dec 2016 17:03:38 +0000

It is just the single NAT64 that is in question (I also tend to think that is broken for IPsec clients?).

Popular IPsec clients work perfectly via 464xlat (double NAT64).

-----Original Message-----
From: sunset4 [mailto:[email-masked]] On Behalf Of Bjoern A. Zeeb
Sent: 09 December 2016 16:33
To: Bill Fenner
Cc: [email-masked]; [email-masked]
Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients

On 9 Dec 2016, at 16:07, Bill Fenner wrote:

> 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?

/bz

_______________________________________________
sunset4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sunset4

NOTICE AND DISCLAIMER
This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. 
If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. 
If you've received this email in error, please let me know immediately on the email address above. Thank you.

We monitor our email system, and may record your emails.

EE Limited 
Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9BW
Registered in England no: 02382161

EE Limited is a wholly owned subsidiary of:

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

---

From: Yoav Nir <[email-masked]>
Date: Fri, 9 Dec 2016 19:30:29 +0200

> On 9 Dec 2016, at 18:32, Bjoern A. Zeeb <[email-masked]> wrote:
> 
>> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <[email-masked]> wrote:
>> 
>>> Hi All,
>>> 
>> contact my office VPN server (SSL VPN and IPSEC); neither one worked from
>> 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
>> support matrix still says that even the newest software does not support
>> SSL VPN over IPv6.
> 

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

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 09 Dec 2016 09:32:41 -0800

With our push to support NAT64 networks (without 464xlat) for Apple's devices, we added support for NAT64 networks to both our IKEv1 and IKEv2 clients a few releases ago. It was a fairly straightforward change. The main parts are making sure any IPv4 literals meant to be use outside the tunnel that come across in the IKE exchange are synthesized into IPv6 addresses; and making sure that the ESP layer is happy encapsulating IPv4 in IPv6 for tunnels. Historically, many implementations only supported IPv4-in-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4.

From an interop perspective, this is just a change that needs to be made on the client behind the NAT64, and requires no protocol changes in IKE or knowledge on the server side.

Thanks,
Tommy Pauly

> On Dec 9, 2016, at 9:03 AM, Heatley, Nick <[email-masked]> wrote:
> 
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Dec 2016 16:39:11 -0500

Bjoern A. Zeeb <[email-masked]> wrote:
    > 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

NAT64 depends upon DNS64 to provide a fake IPv6 target for the application to
connect to.

So, for IPsec to work over NAT64 would require:

1) IPsec able to traverse over IPv6 networks (outer IP header being IPv6).
2) An IKEv2 deamon that uses DNS to find it's IPv4-only gateway, so that it
   can be lied to about the returned AAAA record.

In Bill's case, he hasn't got (1), so it's not going to work.
Once he has (1) (the upgrade he mentioned), if his policy lets him use DNS to
find his gateway, and he doesn't do DNSSEC on that, then it ought to work.

Of course, once he has the upgrade, if his gateway would just have an IPv6,
he wouldn't need NAT64. And he can tunnel his company 10.x v4 network over
things as much as he likes... but there is the question about where his
Internet bound v4 traffic will go... likely if his company's VPN wants to
inspect his traffic, the v4 will go through the tunnel, not using the NAT64
at all, and causing him higher latency.  But, that's what would happen in
a pure v4 situation anyway.

    > 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?

I'm not sure IKEv2 even knows or cares how the port-500 packets get there.
I use v6 over X tunnels (where X is usually v4) in order to get v6 to my
laptop from coffee shops regularly.  I haven't tried this over NAT64, but I
will change this to use DNS.  Of course, I wouldn't need this tunnel in a
NAT64 network, since I'd have v6, so I'll setup some v4 IPsec too for the
next IETF and try it out.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Dec 2016 16:43:06 -0500

Yoav Nir <[email-masked]> wrote:
    > 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.

So, I think that you are saying that if the client does DNS through the
tunnel, then the HQ's DNS servers have to do DNS64 synthesis?  I guess people
need to do DNS through the tunnel because of needing to resolv internal
addresses.  It's the whole MIF/split-horizon DNS problem, and I think it's
all a bad IPv4-specific idea, and we should be trying to kill it.

In an IPv6 world, we have better ways to build walled gardens.

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 09 Dec 2016 13:46:46 -0800

> On Dec 9, 2016, at 1:43 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

The VPN's DNS should never have to know about DNS64 or support it. The client can solve the issue independently—don't add it at the server end!

If I have a IPv4-only split-tunnel VPN over a NAT64 network, with DNS configured such that some hostnames that need to get routed outside the VPN are resolved only inside the VPN (and thus only get A records), the client can take the IPv4 literal result and synthesize the correct IPv6 address using the prefix of the NAT64 network.

Thanks,
Tommy

---

From: "Heatley, Nick" <[email-masked]>
Date: Fri, 9 Dec 2016 22:06:16 +0000

Thanks for this, very useful.
Is the vpn client also discovering the well known prefix for v6 address synthesis itself, or relying on the OS to provide that?

-------- Original message --------
From: Tommy Pauly <[email-masked]>
Date: 09/12/2016 17:32 (GMT+00:00)
To: "Heatley, Nick" <[email-masked]>
Cc: "Bjoern A. Zeeb" <[email-masked]>, Bill Fenner <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

Thanks,
Tommy Pauly

NOTICE AND DISCLAIMER

EE Limited

---

From: Yoav Nir <[email-masked]>
Date: Sat, 10 Dec 2016 00:35:23 +0200

> On 9 Dec 2016, at 23:43, Michael Richardson <[email-masked]> wrote:
> 
> 

That was what I said, but then I realized Tommy is right. It doesn’t really matter that the ISP / Wifi / whatever is providing me with only IPv6 access. Most IPsec clients have their own virtual interface (with IKEv2’s CFG, Cisco’s IKEv1 extension or (gasp!) L2TP) so that has no issue being dual-stack or even IPv4-only. The IPv4 packets never make it onto the access network - they get encapsulated in ESP/IPv6, or TLS/TCP/IPv6.

So with IPsec you can get IPv4 connectivity even when the access network doesn’t give it to you. And you don’t need any DNS games to do it.

Yoav

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 09 Dec 2016 18:28:45 -0800

The VPN client can do the synthesis themselves using RFC 6052 (https://tools.ietf.org/html/rfc6052) and RFC 7050 (https://tools.ietf.org/html/rfc7050), querying ipv4only.arpa over the DNS.

macOS and iOS also support synthesis in the OS by calling getaddrinfo() with the IPv4 address as a string, and returning an IPv6 sockaddr when on a NAT64 network.

Thanks,
Tommy

> On Dec 9, 2016, at 2:06 PM, Heatley, Nick <[email-masked]> wrote:
> 
> From: Tommy Pauly <[email-masked] <mailto:[email-masked]>> 
> To: "Heatley, Nick" <[email-masked] <mailto:[email-masked]>> 
> Cc: "Bjoern A. Zeeb" <[email-masked] <mailto:[email-masked]>>, Bill Fenner <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> > On Dec 9, 2016, at 9:03 AM, Heatley, Nick <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > From: sunset4 [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Bjoern A. Zeeb
> > Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <[email-masked] <mailto:[email-masked]>>
> >> wrote:
> >> 
> >>> Hi All,
> >>> 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/sunset4 <https://www.ietf.org/mailman/listinfo/sunset4>
> > 
> > NOTICE AND DISCLAIMER
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> 
> NOTICE AND DISCLAIMER
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: David Schinazi <[email-masked]>
Date: Fri, 09 Dec 2016 18:32:57 -0800

You'll need to play DNS games if the VPN server if IPv4-only
(or if your VPN config gives you a server IPv4 address to connect to).
In that case you'll need to query the DNS64 server for the NAT64 prefix.
Apple's IKEv2 client uses an OS-provided API to synthesize an IPv6 address
from the configured IPv4 address.
This allows our client to work even if the VPN server does not speak IPv6 at all.
It's always better, simpler, and more efficient to support IPv6 server-side,
but if you don't control the server this can be made to work client-side.

David

> On Dec 9, 2016, at 14:35, Yoav Nir <[email-masked]> wrote:
> 
>>

---

From: Bill Fenner <[email-masked]>
Date: Mon, 12 Dec 2016 11:40:51 -0500

On Fri, Dec 9, 2016 at 4:39 PM, Michael Richardson <[email-masked]>
wrote:

> working fine

Well, I was using Apple's "Cisco IPSec" client for OSX 10.11.5, and it's
the server side implementation that says that IPv6 transport is not
supported.  So, perhaps, I have a client that would support it.

> find his gateway, and he doesn't do DNSSEC on that, then it ought to work.

That is what I have configured.

  Bill