First: It appears not all post content was brought across from forums.juniper.net. This thread had 6 messages total at the original thread (http://forums.juniper.net/t5/SSL-VPN/MAG2600-SA-with-IPV6-vlans/td-p/265480) but fewer here. Is this b/c there is a limitation on the thread depth in forums.pulsesecure.net? I can't reply to the last post in this thread, so I'm assuming a max depth of 3. We're in the same boat as the OP, and it's actually starting to hold back our IPv6 roll-out. We also multi-tenant the MAGs by tying each org to a VLAN. Since we can't add IPv6 addresses or routes to VLAN interfaces, that means we effectively cannot deploy IPv6 in our customers' MAG-based VPN. Aggravating matters is that this means I can't properly dual-stack internal services. If I dual stack a host and add an AAAA record for it, a user connected to the VPN will get that AAAA record as well as the A record. Happy Eyeballs means the user will try to connect to the AAAA first. Since there is no IPv6 connectivity through VPN, that traffic goes via the public Internet rather than through the VPN. Since the resource is only accessible internally, that attempt via the public Internet is unsuccessful because of firewall policy permitting only internal hosts to reach the service. The user then either has to wait for happy eyeballs to fall back to IPv4 or has to access the service via its IPv4 literal address rather than its FQDN. I can't make my users and customers manually enter IPv4 addresses for services that should be accessible (and have been accessible) by hostname just because they're coming in via a VPN on a MAG, so I now cannot publish AAAA records for internal services until this is sorted. Looking forward to seeing if this is on the roadmap and when we expect this to work. For reference: We're running MAG4610s, currently on 8.0R5, though if I'm reading the release notes correctly, this limitation still applies in the latest code.
... View more
