Using OpenVPN through the USG server on port 53
Using OpenVPN through the USG server on port 53
Adjusting the approach to avoid WiFi authentication pages, assuming most networks allow external DNS queries. Deploying OpenVPN as a pre-installed package on pfSense using two servers: one on 1194 UDP (WAN) and another on 53 UDP (virtual IP on WAN). This setup directs traffic through the sequence android > WEB > USG > pfSense > VIP > OpenVPN for port 53. The challenge lies in repeated connection failures with significant packet loss, accompanied by TLS and handshake errors in logs. Success occurs when routing OpenVPN directly through WAN port 53, eliminating double NAT. Switching from VIP to direct WAN listening removes the double NAT issue. The USG firewall appears to block suspicious packets, though UDP streams are hard to interpret. IPS/IDS remains active while DPI is enabled. Any suggestions?
I typically deploy OpenVPN over TCP/443 using the same principle that makes it resilient to blocking. Since OpenVPN operates via SSL, a quick check won’t expose it as non-HTTPS traffic, even though deeper analysis could confirm its nature. Your approach with DNS seems less effective in my view—networks featuring a Wi-Fi login page usually scrutinize DNS activity, identifying regular queries and flagging suspicious traffic. I’m not certain about other solutions, but I understand that devices like hospitality gateways, PFSense, Unifi USG, or Mikrotik often handle DNS differently, sometimes with built-in security features that aren’t straightforward to configure.
I’ll likely set up a quick PFSense solution to confirm there’s no client-side problem (like interference from hotspot security) – actually hadn’t thought it could be an issue. I’ve tried the same with my carrier’s network using my phone, but mobile networks aren’t necessarily a reliable test. I’d also run 443/TCP, though my experience shows traffic gets blocked until you accept the captive portal. I’m just trying to skip the hassle of logging into a captive portal every time. It started as a simple “just because” and now feels like a bigger question: why isn’t this working? Normally I’d expect external DNS to be blocked, pushing clients to use internal DNS for better control. I usually restrict devices from using external DNS at home, though I acknowledge this is just another public service that could be vulnerable. The main concern is IoT devices like Chromecast that insist on using specific domains (e.g., 8.8.8.8). I’ve only tested on less secure networks—like those in McDonald’s, Starbucks, or malls—and my assumption about security outside a captive portal was low.
Your suggestion to skip the portal isn’t entirely bad, though it has a few concerns. If you configure a DNS server on that public IP/port, would it function correctly? I’d test it just to be sure. However, please keep in mind – the forum’s guidelines state we can’t talk about circumventing legal security or policy rules. For routine use, agreeing to terms is fine, but for ongoing support I set up remote monitoring and training so someone can restore it if needed. This is only planned for a short weekend at conventions, not a permanent setup.
I’m keen to pinpoint the problem and test what we discussed. It definitely sits on the gray area, though it isn’t harmful. My focus will be on making OpenVPN function smoothly over port 53 in any scenario, not just with captive portals. Since the issue continues on my mobile connection, I’ll rely on that as my testing environment. If it’s not the intended solution, no worries—this is just one of those side projects I’ve been exploring. Usually it doesn’t bother me either; I saw a Reddit thread about someone forwarding port 53 to OpenVPN, which made my mind spin a bit.
I also questioned whether using UDP/53 could be intercepted by systems designed to block DOS attacks, particularly in mobile network contexts. DNS has historically been a frequent target for reflection amplification attacks.