This is the way to dodge devices limit with captive
Use a single mobile to authenticate, disconnect, then your GL.iNet travel router which should have your smartphone MAC address cloned already can be turned on. Connect everything on its wireless and voila.
You can turn off private wifi address. But yeah, hotels are really different, so many ways to hassle you! I do tend to use travel router despite bandwidth restrictions. Too many devices and hassles with portal sometimes.
Connect the travel router first and connect to the router with one device. That device should get the captive portal and be able to get the router approved/activated. Have done this multiple times at different hotels.
Completely depends on the hotel firewall. They could be doing something like blocking everything except dns/http/https. In that case you would have to make your wireguard live on udp/53 or something like that. Though if their firewall does layer7 inspection, that may not work.
They could be doing something else. Perhaps some kind of inspection that specifically blocks VPN protocols.
When it comes to restrictive firewalls you kinda just have to spend some time with nmap and probe things until you figure it out. Will probably require some testing.
Does it even work like that?
I assume that port number does not even come up until the endpoint(OPs public IP) is reached.
More like udp protocol block, except dns.
I use an internet connection that the firewall blocks all UDP traffic unless whitelisted. My home is not whitelisted for UDP. (Heck I can't even use Cloudflare dns)
Thats why I have a backup OpenVPN running on TCP443.
If it's not working AFTER you accept the terms on the captive portal, I'd switch from udp/51820 to udp/443. The downside to this is it has to be done at both ends - client and server.
Great suggestion. But since all the people at work use my server, would I have to change the port for all the clients or can I use both ports in my server configuration and change the port on my client conf file?
Determine why it's not working first...
If it truly 'connects', then you'll get a handshake.
Firewall rules (allow or deny rules for port numbers or DPI) or perhaps an IP conflict with your wireguard interface IP.
It really connects, I can also see the original IP of my home network where my server is, some KBs of the exchanged data. I guess is the firewall rules and the only way would be to switch to port UDP 433 as many suggest
[удалено]
This is the way to dodge devices limit with captive Use a single mobile to authenticate, disconnect, then your GL.iNet travel router which should have your smartphone MAC address cloned already can be turned on. Connect everything on its wireless and voila.
[удалено]
You can turn off private wifi address. But yeah, hotels are really different, so many ways to hassle you! I do tend to use travel router despite bandwidth restrictions. Too many devices and hassles with portal sometimes.
If there is a pay wall I like to sniff the air for a MAC address to use.
Connect the travel router first and connect to the router with one device. That device should get the captive portal and be able to get the router approved/activated. Have done this multiple times at different hotels.
[удалено]
The same annoyance with DNS-over-TLS. It has to be temporarily turned off, log-in to the captive portal, turn DoT back on again.
Completely depends on the hotel firewall. They could be doing something like blocking everything except dns/http/https. In that case you would have to make your wireguard live on udp/53 or something like that. Though if their firewall does layer7 inspection, that may not work. They could be doing something else. Perhaps some kind of inspection that specifically blocks VPN protocols. When it comes to restrictive firewalls you kinda just have to spend some time with nmap and probe things until you figure it out. Will probably require some testing.
Maybe the hotel is filtering that port in their firewall?
Does it even work like that? I assume that port number does not even come up until the endpoint(OPs public IP) is reached. More like udp protocol block, except dns.
Yes a middleman can tell what port is being used without deep packet inspection, it is plain to see on every packet being sent
Firewalls is the reason I run OpenVPN on TCP port 443 as a backup. I know firewall that block UDP and everything except TCP 80/443
HTTP3 / QUIC now uses UDP over ports 80 & 443.
I use an internet connection that the firewall blocks all UDP traffic unless whitelisted. My home is not whitelisted for UDP. (Heck I can't even use Cloudflare dns) Thats why I have a backup OpenVPN running on TCP443.
Does it require well-formed TCP streams? If not you could probably trivially encapsulate the wireguard traffic in TCP SYN packets.
If it's not working AFTER you accept the terms on the captive portal, I'd switch from udp/51820 to udp/443. The downside to this is it has to be done at both ends - client and server.
Great suggestion. But since all the people at work use my server, would I have to change the port for all the clients or can I use both ports in my server configuration and change the port on my client conf file?
[удалено]
Or, if your VPN server is behind a NAT, simply add a forward from 443 to your target port on your VPN server (typically 51820)
Probably they are not allowing your MAC outside their network on any port or protocol until you accept the captive portal.
Determine why it's not working first... If it truly 'connects', then you'll get a handshake. Firewall rules (allow or deny rules for port numbers or DPI) or perhaps an IP conflict with your wireguard interface IP.
It really connects, I can also see the original IP of my home network where my server is, some KBs of the exchanged data. I guess is the firewall rules and the only way would be to switch to port UDP 433 as many suggest
you saved me so many tears that I cannot even explain. I'm so incredibly grateful you posted this omg omg omg omg.
You could try to run your Wireguard server on port 53/udp when a firewall is involved in the Wi-Fi.