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

[Bill Fenner]

On Fri, Dec 9, 2016 at 4:39 PM, Michael Richardson 
wrote:

>
> Bjoern A. Zeeb  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  record.
>
> In Bill's case, he hasn't got (1), so it's not going to work.
>

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.


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

That is what I have configured.

  Bill
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[David Schinazi]

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  wrote:
> 
>> 
>> On 9 Dec 2016, at 23:43, Michael Richardson  wrote:
>> 
>> 
>> Yoav Nir  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.
> 
> 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
> 
> ___
> IPsec mailing list
> IPsec@ietf.org 
> https://www.ietf.org/mailman/listinfo/ipsec 
> 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tommy Pauly]

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 <nick.heat...@ee.co.uk> wrote:
> 
> 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 <tpa...@apple.com <mailto:tpa...@apple.com>> 
> Date: 09/12/2016 17:32 (GMT+00:00)
> To: "Heatley, Nick" <nick.heat...@ee.co.uk <mailto:nick.heat...@ee.co.uk>> 
> Cc: "Bjoern A. Zeeb" <bzeeb-li...@lists.zabbadoz.net 
> <mailto:bzeeb-li...@lists.zabbadoz.net>>, Bill Fenner <fen...@fenron.com 
> <mailto:fen...@fenron.com>>, ipsec@ietf.org <mailto:ipsec@ietf.org>, 
> suns...@ietf.org <mailto:suns...@ietf.org>
> Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients
> 
> 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 <nick.heat...@ee.co.uk 
> > <mailto:nick.heat...@ee.co.uk>> wrote:
> > 
> > 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:sunset4-boun...@ietf.org 
> > <mailto:sunset4-boun...@ietf.org>] On Behalf Of Bjoern A. Zeeb
> > Sent: 09 December 2016 16:33
> > To: Bill Fenner
> > Cc: ipsec@ietf.org <mailto:ipsec@ietf.org>; suns...@ietf.org 
> > <mailto:suns...@ietf.org>
> > Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients
> > 
> > On 9 Dec 2016, at 16:07, Bill Fenner wrote:
> > 
> >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <nick.heat...@ee.co.uk 
> >> <mailto:nick.heat...@ee.co.uk>>
> >> 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
> > 
> > ___
> > sunset4

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

[Yoav Nir]

> On 9 Dec 2016, at 23:43, Michael Richardson  wrote:
> 
> 
> Yoav Nir  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.

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Heatley, Nick]

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 <tpa...@apple.com>
Date: 09/12/2016 17:32 (GMT+00:00)
To: "Heatley, Nick" <nick.heat...@ee.co.uk>
Cc: "Bjoern A. Zeeb" <bzeeb-li...@lists.zabbadoz.net>, Bill Fenner 
<fen...@fenron.com>, ipsec@ietf.org, suns...@ietf.org
Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

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 <nick.heat...@ee.co.uk> wrote:
>
> 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:sunset4-boun...@ietf.org] On Behalf Of Bjoern A. Zeeb
> Sent: 09 December 2016 16:33
> To: Bill Fenner
> Cc: ipsec@ietf.org; suns...@ietf.org
> Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients
>
> On 9 Dec 2016, at 16:07, Bill Fenner wrote:
>
>> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <nick.heat...@ee.co.uk>
>> 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
>
> ___
> sunset4 mailing list
> suns...@ietf.org
> 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: 180
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


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

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

[Michael Richardson]

Yoav Nir  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.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Michael Richardson]

Bjoern A. Zeeb  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  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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tommy Pauly]

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  wrote:
> 
> 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:sunset4-boun...@ietf.org] On Behalf Of Bjoern A. Zeeb
> Sent: 09 December 2016 16:33
> To: Bill Fenner
> Cc: ipsec@ietf.org; suns...@ietf.org
> Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients
> 
> On 9 Dec 2016, at 16:07, Bill Fenner wrote:
> 
>> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick 
>> 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
> 
> ___
> sunset4 mailing list
> suns...@ietf.org
> 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: 180
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yoav Nir]

> On 9 Dec 2016, at 18:32, Bjoern A. Zeeb  
> wrote:
> 
> On 9 Dec 2016, at 16:07, Bill Fenner wrote:
> 
>> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick  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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Heatley, Nick]

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:sunset4-boun...@ietf.org] On Behalf Of Bjoern A. Zeeb
Sent: 09 December 2016 16:33
To: Bill Fenner
Cc: ipsec@ietf.org; suns...@ietf.org
Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients

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

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

___
sunset4 mailing list
suns...@ietf.org
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: 180
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Bjoern A. Zeeb]

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

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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec