VPN problems

[Darren1068]

I use Forticluent as a work VPN and since I switched to the new Sky Max hub it won't connect 

[jamesn123]

@Darren1068 

Have you disabled Sky Shield?

[TimmyBGood]

@Darren1068 

For business VPN through a Max Hub the most likely cause of issues is the Sky deployment of Map-T, so I'll escalate your post.

[Darren1068]

Yes sky shield is disabled . It was fine at first then around 2 weeks ago it just started blocking my VPN . Spoke to works IT and they said there are quite a few having issues with the new Sky max hub and it's something to do with settings they have changed recently 

[TimmyBGood]

---

@Darren1068 wrote:

Spoke to works IT and they said there are quite a few having issues with the new Sky max hub and it's something to do with settings they have changed recently 

---

It's the introduction of 8:1 IPv4 Map-T for Sky Max Hub users (which is an external core network transport change rather than 'settings')

[Darren1068]

I have reported it to Sky . Not sure what they will do about it 

[TimmyBGood]

@Darren1068 

For Map-T issues, the solution is to move the circuit to your address onto a permanent 1:1 mapping, so giving it a 'real' external IP.

[Darren1068]

So I have contacted Sky about the VPN issues again today 

got a very dismissive person on the phone telling me it's my issue and not SKY and they can't do anything about it 

strange as my VPN will connect to any other WIFI other my i oh em through Sky max hub 

[MW230]

I'm the same, raised on this forum last wednesday, still waiting for a developer to look at it. I went through my work who did all the checks there end then sent me this. 'you need to opt out out of IP sharing (map-T/CGNAT). My issues started after receiving the new Sky white hub after having fibre installed. 

[Tom-W19]

Hi @Darren1068 

Your post has been escalated to our Community Messaging team who will invite you to a private chat shortly and help you with this.

Just look out for the chat bubble to start the conversation.

Here's more information on how Community Messaging works - https://community.sky.com/t5/Did-you-know/Escalating-a-post-to-a-Sky-expert/ba-p/3711147

[Desi2]

I am having the same issues with white SKY MAX HUB AND WORK VPN, if the work around is moving from 8:1 to 1:1 how do I do that

[TimmyBGood]

@Desi2 

That's something Sky has to do at their end, so I've escalated your post.

[Darren1068]

I was contacted by Sky and they went through more things to try and get the VON connected and the last thing was asking me to get my IT department to check some settings , which was not an easy task so I had to come out of the conversation . I now have the information they asked for but can't join the conversation again . The company I work for employs 11000 people so asking about just my VPN isn't a quick process unfortunately 

[-rpnz-]

Customers can "opt-out" of IPv4 address sharing automatically themselves by enabling one of the following features on the Sky Max Hub:

• UPnP
• DMZ
• Port Forwarding
• Port Triggering

This will cause a brief disconnect, following which you will be given a different IPv6 prefix along with a whole IPv4 address.  This should show up on the Sky Hub WAN status page as using "MAP-T 1:1".

[If you have no specific requirement for DMZ, or Port Forwarding/Triggering, then I'd suggest only enabling UPnP to trigger this journey.]

This will fix all issues related to IPv4 address sharing, which may include some VPN issues, specifically with GRE-based VPNs such as PPTP.

If customers are still having issues with other VPNs after this, then there are two possible resolutions:

• Your IT team can reconfigure the VPN to avoid fragmentation (both of the encrypted payload and authentication packets); or
• MAP-T needs to be disabled on your line, for which this can only be done via escalation within Sky.

[-rpnz-]

---

@-rpnz- wrote:

• Your IT team can reconfigure the VPN to avoid fragmentation (both of the encrypted payload and authentication packets); 

---

To add more detail on this point, to assist any IT teams reading this thread:

The issue is that our MAP-T border relay is currently unable to translate fragmented UDP packets that have a zero checksum.

If VPN configuration can be applied to generate a non-zero checksum, that would mitigate the issue, as would avoiding fragmentation entirely.  

If configuration has been applied to ensure 1500 byte packets are being sent without fragmentation and the issue persists, please try reducing this to 1480 bytes.

If the VPN does not encapsulate payload using UDP, then it's not hitting this specific issue.

We are expecting to be able to resolve this issue our side with a future firmware update from our vendor.