I've seem to hit a few issues in the Pulse forums as a whole and wanted to confirm if these are known problems or something isolated I'm running into. There isn't a specific forum for "general discussion" not tied to a particular product, so I'm dropping this under Pulse Connect Secure as we have some MAGs. 1. Thread/reply depth Threads seem to be limited to 2 replies (i.e. a depth of 3 posts). This makes replies clunky as at the 3rd tier, the [i]reply[/i] button is no longer available and so replies have to be done on a higher post rather than the one to which the author is actually replying. I guess there's some logic trying to make things look pretty and not go crazy on the indentation on replies, but IMHO simply restricting thread depth strikes the wrong balance. Fix the UI, don't break functionality. 2. Missing content on threads imported from forums.juniper.net Example: - Pulse thread: https://forums.pulsesecure.net/topic/pulse-connect-secure/265480-mag2600-sa-with-ipv6-vlans - Juniper forums thread: http://forums.juniper.net/t5/SSL-VPN/MAG2600-SA-with-IPV6-vlans/td-p/265480 There are more replies in the original forums.juniper.net thread than in the copy imported into the Pulse forum. I'm guessing this [i]could[/i] be time-based (i.e. content added to the Juniper thread after the Pulse export/import was done), but my gut says this is likely a result of #1, and that nothing past the 3rd level of replies in a thread is being displayed in the Pulse forum. Whether this is a view issue only (content exists in the Pulse forum backend DB for this but is simply not being displayed) or a content thing (content was never imported or doesn't exist in the Pulse forum backend DB) is unclear, but I'm betting that's a [b]lot[/b] of content that's basically missing now. 3. Ephemeral nature of reply windows DIVs that fade in dynamically with JS magic are pretty, but clicking outside of a reply composition window should not be considered sufficient to close that DIV and discard whatever text I had composed. If I accidentally click outside of the reply composition window after flipping to another application or browser window and clicking back, I really don't want my reply to disappear simply because I clicked in the wrong part of the page.
... View more
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