Opened 9 months ago

Closed 9 months 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:

Description

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 owa.neustar.biz, 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 (jabber.org <http://jabber.org/>) - 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       	5.1.5.61437, 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

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.96.12.121       UGSc           24        0   utun0
default            31.133.128.1       UGScI          18        0     en0
10.96.12.121       10.96.12.121       UHr            26       40   utun0
10.96.12.121/32    link#11            UCS             1        0   utun0
31.133.128/20      link#5             UCS             4        0     en0
31.133.128.1       link#5             UHCS            1        0     en0
31.133.128.1/32    link#5             UCS             2        0     en0
31.133.128.1       0:0:5e:0:1:80      UHLWIir        21        0     en0   1109
31.133.129.38/32   link#5             UCS             1        0     en0
31.133.130.22      78:4f:43:96:d8:f4  UHLWIi          1        1     en0   1176
31.133.136.133     ac:bc:32:b0:99:7b  UHLWIi          1        1     en0   1114
127                127.0.0.1          UCS             1        0     lo0
127.0.0.1          127.0.0.1          UH              7  2363656     lo0
156.154.9.10       31.133.128.1       UGHCS           2        0     en0
156.154.9.10       31.133.128.1       UGHWIi          3      992     en0
169.254            link#5             UCS             1        0     en0
224.0.0            link#5             UmCS            2        0     en0
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          1        0     en0
255.255.255.255/32 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

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
10.96.12.121       10.96.12.121       UH              1        0   utun0
127                127.0.0.1          UCS             1        0     lo0
127.0.0.1          127.0.0.1          UH              7  2363141     lo0
169.254            link#5             UCS             2        0     en0
169.254.142.41/32  link#5             UCS             1        0     en0
224.0.0            link#5             UmCS            2        0     en0
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          1        0     en0
255.255.255.255/32 link#5             UCS             1        0     en0

Internet6:
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 stnetcprveng01.va.neustar.com: nodename nor servname provided, or not known
wgeorge-mac:~ wgeorge$ dig stnetcpvreng01.va.neustar.com

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

;; QUESTION SECTION:
;stnetcpvreng01.va.neustar.com.	IN	A

;; AUTHORITY SECTION:
neustar.com.		600	IN	SOA	pdns1.ultradns.net. sec_grp.neustar.com. 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 10.31.88.14
ssh: connect to host 10.31.88.14 port 0: Can't assign requested address


wgeorge-mac:~ wgeorge$ ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 ::1 prefixlen 128
	inet 127.0.0.1 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
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	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 169.254.142.41 netmask 0xffff0000 broadcast 169.254.255.255
	nd6 options=1<PERFORMNUD>
	media: autoselect
	status: active
en1: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
	options=60<TSO4,TSO6>
	ether 72:00:01:8e:da:e0
	media: autoselect <full-duplex>
	status: inactive
en2: flags=963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX> mtu 1500
	options=60<TSO4,TSO6>
	ether 72:00:01:8e:da:e1
	media: autoselect <full-duplex>
	status: inactive
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
	ether 02:03:08:a5:f3:f0
	media: autoselect
	status: inactive
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484
	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
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=63<RXCSUM,TXCSUM,TSO4,TSO6>
	ether 02:e1:10:00:5a:00
	Configuration:
		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 10.96.12.55 --> 10.96.12.55 netmask 0xffffffff

Hope this is helpful

Wes George

signature.asc

Attachments (1)

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

Download all attachments as: .zip

Change history (3)

Changed 9 months ago by wesgeorge@…

Attachment: signature.asc added

Added by email2trac

comment:1 Changed 9 months 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 https://tickets.meeting.ietf.org/wiki/nat64

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 9 months ago by panda@…

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