Opened 3 years ago

Closed 3 years ago

#1163 closed request (pending)

NAT64 issues

Reported by: wesgeorge@… Owned by: panda@…
Priority: tbd Milestone: ietf-100
Component: nat64 Keywords:
Cc: Clemens, Schrimpe, <Ccsch@…> My Current Location:
My MAC Address: My OS:


Tested my setup with the NAT64 SSID today for a bit, found a few things that aren’t working. I don’t think that this is specifically a problem with the NAT64 implementation on the IETF network, but rather an interesting failure case I wanted to share that is mostly related to my specific setup.

Without VPN, just on standard NAT64:
Outlook Mac 2011 refuses to connect to exchange server, even after closing and re-opening the app. This is normally reachable externally without a VPN over v4. Unclear if this is somehow a problem with Outlook 2011, I’m thinking maybe it doesn’t support IPv6 <-> Exchange in this version.
Trillian won't connect to AIM, Google Hangouts, FB, or Jabber ( <>) - this might be Trillian, as Hangouts and FB messenger works in the web client inside of Gmail.

With corporate VPN:
VPN connects and establishes a connection to a v4-only tunnel endpoint no problem, authenticates, etc. so far so good.
However, intranet sites are unreachable (“DNS probe finished, no internet” in Chrome), and Outlook still doesn’t work. I also can’t ssh to my jump host via either name or IP.

Relevant info - my company’s VPN is technically misconfigured, in that it allows split tunneling - IPv6 traffic bypasses the VPN when you are connected to a dual-stack network. My guess is that there are two issues here - one is that the provided DNS servers do not have entries for our internal stuff, and it seems like maybe DNS queries aren’t being redirected to the DNS servers that should have been provided by the VPN. The other is that somehow even the stuff that should have a route via IPv4 (i.e. internal 10.x hosts connecting directly via IP to bypass DNS) doesn’t seem to be redirecting over the VPN tunnel as expected. Appears that the VPN client isn’t installing the default IPv4 route when it connects over NAT64, maybe because of the 169.254 address present on the interface it’s using. Some output and other details that might help below.

Software used and versions:
MacOS 10.11.6 (El Cap)
VPN: Junos Pulse Secure, SSL/VPN
Outlook Mac 14.7.7
Chrome 62.0.3202.89
Trillian 6.0 (4)

This is the output for when VPN is active on the dual-stack network and IPv4 default is present:
wgeorge-mac:~ wgeorge$ netstat -nr
Routing tables

Destination        Gateway            Flags        Refs      Use   Netif Expire
default         UGSc           24        0   utun0
default         UGScI          18        0     en0       UHr            26       40   utun0    link#11            UCS             1        0   utun0
31.133.128/20      link#5             UCS             4        0     en0       link#5             UHCS            1        0     en0    link#5             UCS             2        0     en0       0:0:5e:0:1:80      UHLWIir        21        0     en0   1109   link#5             UCS             1        0     en0      78:4f:43:96:d8:f4  UHLWIi          1        1     en0   1176     ac:bc:32:b0:99:7b  UHLWIi          1        1     en0   1114
127                UCS             1        0     lo0          UH              7  2363656     lo0       UGHCS           2        0     en0       UGHWIi          3      992     en0
169.254            link#5             UCS             1        0     en0
224.0.0            link#5             UmCS            2        0     en0        1:0:5e:0:0:fb      UHmLWI          1        0     en0 link#5             UCS             1        0     en0

Rest of the output is when VPN is active on the NAT64 SSID, note missing IPv4 default route:

wgeorge-mac:~ wgeorge$ netstat -nr
Routing tables

Destination        Gateway            Flags        Refs      Use   Netif Expire       UH              1        0   utun0
127                UCS             1        0     lo0          UH              7  2363141     lo0
169.254            link#5             UCS             2        0     en0  link#5             UCS             1        0     en0
224.0.0            link#5             UmCS            2        0     en0        1:0:5e:0:0:fb      UHmLWI          1        0     en0 link#5             UCS             1        0     en0

Destination                             Gateway                         Flags         Netif Expire
default                                 fe80::1998:1%en0                UGc             en0
::1                                     ::1                             UHL             lo0
2001:67c:370:1998::/64                  link#5                          UC              en0
2001:67c:370:1998:6203:8ff:fea5:f3f0    60:3:8:a5:f3:f0                 UHL             lo0
2001:67c:370:1998:6409:1a83:671b:8cd2   60:3:8:a5:f3:f0                 UHL             lo0
2001:67c:370:1998:7598:e871:b5c2:737d   link#5                          UHLWIi          en0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en0/64                           link#5                          UCI             en0
fe80::1998:1%en0                        0:0:5e:0:2:c6                   UHLWIir         en0
fe80::6203:8ff:fea5:f3f0%en0            60:3:8:a5:f3:f0                 UHLI            lo0
fe80::%awdl0/64                         link#9                          UCI           awdl0
fe80::dccc:bcff:fed6:1189%awdl0         de:cc:bc:d6:11:89               UHLI            lo0
ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%en0/32                           link#5                          UmCI            en0
ff01::%awdl0/32                         link#9                          UmCI          awdl0
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%en0/32                           link#5                          UmCI            en0
ff02::%awdl0/32                         link#9                          UmCI          awdl0
wgeorge-mac:~ wgeorge$

ssh: Could not resolve hostname nodename nor servname provided, or not known
wgeorge-mac:~ wgeorge$ dig

; <<>> DiG 9.8.3-P1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52947
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;	IN	A

;; AUTHORITY SECTION:		600	IN	SOA 1311360617 21600 3600 604800 600

;; Query time: 30 msec
;; SERVER: 2001:67c:370:229::7#53(2001:67c:370:229::7)
;; WHEN: Sun Nov 12 20:22:51 2017
;; MSG SIZE  rcvd: 109

wgeorge-mac:~ wgeorge$ ssh
ssh: connect to host port 0: Can't assign requested address

wgeorge-mac:~ wgeorge$ ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	inet6 ::1 prefixlen 128
	inet netmask 0xff000000
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
	nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
	ether 60:03:08:a5:f3:f0
	inet6 fe80::6203:8ff:fea5:f3f0%en0 prefixlen 64 scopeid 0x5
	inet6 2001:67c:370:1998:6203:8ff:fea5:f3f0 prefixlen 64 autoconf
	inet6 2001:67c:370:1998:99f1:35f3:b595:f562 prefixlen 64 autoconf temporary
	inet netmask 0xffff0000 broadcast
	nd6 options=1<PERFORMNUD>
	media: autoselect
	status: active
	ether 72:00:01:8e:da:e0
	media: autoselect <full-duplex>
	status: inactive
	ether 72:00:01:8e:da:e1
	media: autoselect <full-duplex>
	status: inactive
	ether 02:03:08:a5:f3:f0
	media: autoselect
	status: inactive
	ether de:cc:bc:d6:11:89
	inet6 fe80::dccc:bcff:fed6:1189%awdl0 prefixlen 64 scopeid 0x9
	nd6 options=1<PERFORMNUD>
	media: autoselect
	status: active
	ether 02:e1:10:00:5a:00
		id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
		maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
		root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
		ipfilter disabled flags 0x2
	member: en1 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 6 priority 0 path cost 0
	member: en2 flags=3<LEARNING,DISCOVER>
	        ifmaxaddr 0 port 7 priority 0 path cost 0
	nd6 options=1<PERFORMNUD>
	media: <unknown type>
	status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1400
	inet --> netmask 0xffffffff

Hope this is helpful

Wes George


Attachments (1)

signature.asc (833 bytes) - added by wesgeorge@… 3 years ago.
Added by email2trac

Download all attachments as: .zip

Change history (3)

Changed 3 years ago by wesgeorge@…

Attachment: signature.asc added

Added by email2trac

comment:1 Changed 3 years ago by llynch@…

Cc: Clemens Schrimpe <Ccsch@…> added
Component: incomingnat64
Owner: changed from < default > to panda@…
Status: newassigned

Thanks for trying the NAT64 network (SSID ietf-nat64) and reporting
your experience. As far as we can tell, the issue you reported is
either an issue of the NAT64 implementation's handling of that
specific traffic or the given application vendor's implementation.
We're collecting all the issues that come up and will pass the
reports back to the vendor at the end of the week. Hopefully this
will lead to better implementations and greater functionality for
the next meeting. If you're curious about other known issues,
please see

If you have additional input on this issue please update the ticket,
if you see new issues please open additional tickets.

Thanks -

comment:2 Changed 3 years ago by panda@…

Resolution: pending
Status: assignedclosed
Note: See TracTickets for help on using tickets.