MAG2600 SA with IPV6 vlans?

[herwarth_]

hello,

i am migrating from IPV4 to IPV6 and to my surprise it is not possible to attach an IPV6 address to a vlan.

so my clients are unable to get an IPV6 address routed through the SA.

how am i able to connect to IPV6 only hosts behind an SA?

when will juniper make this possible? IPV6 is not a new technology and it makes me wonder why a network company is not able to work this out.

greetings,

h

[Kita_]

Are we talking about IPv6 via the VPN tunnel?  We starting supporting IPv6 in different phases.  Partial support started in 7.3 and 7.4.  However, IPv6 should be fully implemented in 8.0.

http://www.juniper.net/techpubs/software/ive/releasenotes/j-sa-sslvpn-7.3R1-whatsnew.pdf

http://www.juniper.net/techpubs/software/ive/releasenotes/j-sa-sslvpn-7.4r1-whatsnew.pdf

http://www.juniper.net/techpubs/en_US/uac5.0/information-products/topic-collections/security-access-...

[herwarth_]

what do you mean fully implemented?

i can set an ipv6 address on the internal port, on the external port, but i can only set an ipv4 address on a vlan.

i am using version 8 and yes i mean ipv6 address over an ipv4/ipv6 vpn connection.

[Kita_]

If we are talking about sending IPv6 traffic through the VPN tunnel, this should work with Pulse 5.0 and Pulse Secure gateway 8.0.  You can refer to the table on pg 961 (http://www.juniper.net/techpubs/en_US/sa8.0/information-products/topic-collections/junos-pulse-secur...

There are certain limitation depending if you are talking about IPv4 to IPv6 or IPv6 to IPv6 through the tunnel as we had to make changes to both the Pulse Secure gateway and Pulse Secure client software.

[herwarth_]

 these limitations mean no ipv6 vlan support?

and the link is dead....

---

---

@kita wrote:

If we are talking about sending IPv6 traffic through the VPN tunnel, this should work with Pulse 5.0 and Pulse Secure gateway 8.0.  You can refer to the table on pg 961 (http://www.juniper.net/techpubs/en_US/sa8.0/information-products/topic-collections/junos-pulse-secur...

There are certain limitation depending if you are talking about IPv4 to IPv6 or IPv6 to IPv6 through the tunnel as we had to make changes to both the Pulse Secure gateway and Pulse Secure client software.

---

[mattspierce_]

This has been a very helpful thread as I'm butting heads with this issue. I added v6 addressing to my SA4500 cluster running 8.or7.1 .recently. I assign clients a vlan via role. The vlan only allows ipv4 addresses. I am assigning the clients a ipv6 subnet in the vlan in the connection profile. The clients get a ipv6 address from the assigned role. They cannot ping each other while connected. They can ping each other via the ipv4 addresses. The connected clients cannot ping the ipv4 address of the internal interface of the SA, nor ping through to any ipv6 address beyond. The ND cache shows a ff02::1.
The vlan ipv6 route table shows:

default		fe80::	64	::	VLAN 100	0
default		::	0		VLAN 100	2

The route status is flagged as unkown.

My guess is I would need to define a route from the ipv6 address subnet range I assign to clietnt to the vlan ipv6 gateway. I I wasn't able to find good information to that effect in the documentation.

[hslabbert]

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.