[VPN] Non-standaard poorten geblokkeerd door mobiele ISP's

[Urk]

Deze vraag heeft betrekking op jullie ervaring voor het blokkeren van niet-standaard TCP poorten door mobiele providers zoals KPN, Vodafone, T-Mobile etc.

Sonicwall firewalls gebruiken voor hun SSL VPN server standaard poort 4433.
Ik heb zelf voor een klant een SSL VPN server opgezet op een andere poort dan 443 aangezien die al in gebruik is. Dat betreft een SSTP (VPN naar Windows Server) VPN op poort 4439.

Zodra ik met WiFi verbind naar een VPN server op poort 4433 of poort 4439 werkt dat prima.
Zodra ik dat echter met een mobiele hotspot probeer (in mijn geval via Vodafone maar ook T-Mobile getest) worden deze poorten geblokkeerd, ik kan dan dus geen VPN verbinding maken.

Wat is jullie ervaring hieromtrendt? Is het niet vreemd dat deze poorten voor mobiele providers dichtzetten en bij "normale/bekabelde" providers niet...?

Ik heb Vodafone support hier al over gebeld en werd uitstekend geholpen door iemand bij Groot-Zakelijk en kreeg ook bevestigd van zijn technische team dat poort 4433 inderdaad dicht zit. Volgens zijn zeggen vanwege trojans die ooit veel van deze poort gebruik maakten...

[GekkeR]

Afhankelijk van een boel dingen zou in dit geval een 2de IP met de VPN op 443 jou een boel ellende schelen.
Maar dat zijn mogelijk extra kosten en inrichting (sonicwall) waar je niet op zit te wachten. Anders dan dat zou je kunnen leunen op een algemene VPN provider, om daarna verbinding te maken met de correcte VPN tunnel (tunnel in een tunnel). Beetje meer gedoe en foutgevoelig maar if it works...

Nog een alternatief is wat slimmigheid met AWS, DNS opzetten naar een bucket ofzo en deze redirecten naar een specific poort nummer (dan kan je controleren naar waar mensen heen gaan). Clients hebben dan simpelweg die DNS entry. Ik weet echter niet wat SSTP toestaat voor redirects.

En als laatste kan je zoeken naar een oplossing in de zin van dat die SSTP service zelf verbinding maakt met een externe partij (Azure?) waar de rest weer verbinding mee maakt.

Blijft lastig inderdaad.

[Urk]

GekkeR schreef op maandag 18 oktober 2021 @ 12:14:
Afhankelijk van een boel dingen zou in dit geval een 2de IP met de VPN op 443 jou een boel ellende schelen.
Maar dat zijn mogelijk extra kosten en inrichting (sonicwall) waar je niet op zit te wachten. Anders dan dat zou je kunnen leunen op een algemene VPN provider, om daarna verbinding te maken met de correcte VPN tunnel (tunnel in een tunnel). Beetje meer gedoe en foutgevoelig maar if it works...

Nog een alternatief is wat slimmigheid met AWS, DNS opzetten naar een bucket ofzo en deze redirecten naar een specific poort nummer (dan kan je controleren naar waar mensen heen gaan). Clients hebben dan simpelweg die DNS entry. Ik weet echter niet wat SSTP toestaat voor redirects.

En als laatste kan je zoeken naar een oplossing in de zin van dat die SSTP service zelf verbinding maakt met een externe partij (Azure?) waar de rest weer verbinding mee maakt.

Blijft lastig inderdaad.

2e IP was inderdaad voorheen altijd al het geval. Alleen door wat wijzigingen had ik maar 1 IPv4 adres nog vrij. Nog wel een paar miljoen IPv6 adressen beschikbaar maar weet niet of dat werkt als een client alleen maar verbinding maakt via IPv4?!

Dit topic mag dicht wat mij betreft, want achteraf bleek het helemaal geen blokkade te zijn maar een DNS issue...

Ondanks dat toch bedankt voor je uitgebreide reactie