Opened 3 years ago
Closed 3 years ago
#1163 closed request (pending)
NAT64 issues
| Reported by: | Owned by: | ||
|---|---|---|---|
| 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
Attachments (1)
Change history (3)
Changed 3 years ago by
| Attachment: | signature.asc added |
|---|
comment:1 Changed 3 years ago by
| Cc: | Clemens Schrimpe <Ccsch@…> added |
|---|---|
| Component: | incoming → nat64 |
| Owner: | changed from < default > to panda@… |
| Status: | new → assigned |
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 3 years ago by
| Resolution: | → pending |
|---|---|
| Status: | assigned → closed |
Note: See TracTickets for help on using tickets.
Added by email2trac