OpenVPN behind USG over port 53

[Mikensan]

Skipping writing out my port forwarding and double NAT - assumed knowledge. The purpose is to bypass WiFi sign-in pages since a majority don’t block external DNS lookups.

 

Running OpenVPN as a package on pfsense with two instances: one listening on good old 1194 udp (WAN), and another on 53 udp (virtual IP on WAN).

So traffic would be android > WEB > USG > pfSense > VIP > OpenVPN when trying to use port 53.

 

The problem I’m having with this method is it fails several times to connect and eventually does but with really bad packet loss. I see TLS and handshake errors throughout the log.

When trying this over the 1194, it works great and without any problems. I’ve even switched it from listening on a VIP to the WAN directly so there was no double NAT. No Dice

 

Bypassing the USG and connecting over port 53, it works great. Only when I forward OpenVPN through port 53 on the USG do I have an issue. I suspect the USG’s firewall is dropping what it thinks is “bad” packets. Under the firewall I see it is set to drop bad states, but given this is a UDP stream I’m really confused what’s going on. IPS/IDS is off, DPI is on.

 

Any idears?

[brwainer]

Personally I run OpenVPN on TCP/443 based on the same logic that noone can block that. Also OpenVPN is SSL based so a cursory inspection won’t reveal it isn’t HTTPS traffic, although a Layer 7 Deep Packet inspection can tell the difference. Your idea with DNS however is less likely to work in my opinion - systems with a wifi signin page often do inspect DNS traffic and see whether its a normal DNS packet, track users who try to leave the walled garden, and drop unusual packets. By “often” I’m referring to certain gateways that are common in the hospitality industry, I’m not sure about things used elsewhere, or the hotspot function of PFSense, Unifi USG, or Mikrotik (I’m sure on Mikrotik its just another thing that isn’t easy to set up but can be done)

[Mikensan]

8 minutes ago, brwainer said:

Personally I run OpenVPN on TCP/443 based on the same logic that noone can block that. Also OpenVPN is SSL based so a cursory inspection won’t reveal it isn’t HTTPS traffic, although a Layer 7 Deep Packet inspection can tell the difference. Your idea with DNS however is less likely to work in my opinion - systems with a wifi signin page often do inspect DNS traffic and see whether its a normal DNS packet, track users who try to leave the walled garden, and drop unusual packets. By “often” I’m referring to certain gateways that are common in the hospitality industry, I’m not sure about things used elsewhere, or the hotspot function of PFSense, Unifi USG, or Mikrotik (I’m sure on Mikrotik its just another thing that isn’t easy to set up but can be done)

I'll probably throw up a quick pfsense in place of the USG to double check it isn't an issue on the client side (interferance from hotspot security) - honestly hadn't considered this as an issue, good point. I have tried testing over my carrier with my cellphone with the same crap luck - but mobile networks aren't exactly a bar to go by.

 

I would run 443/TCP as well, but my experience has been that the traffic is blocked until you click "agree" or whatever the captive portal is asking for. Just wanting to avoid the tedious nature of logging into a captive portal every time. Started off as a "just because" and has turned into a "why isn't this working".

 

Normally I would've thought external DNS would outright be denied, forcing clients to use internal DNS servers for more insight and control. I do this at home, preventing devices from using outside DNS. Although I suppose this is just one more "public" service to be attacked. Only issue is with the handful of IOT devices like Chromecast that demand to use 8.8.8.8 etc...

 

I will say I've only tested on less sensitive networks: McDonalds / Starbucks / Malls, so my expectation of security outside a captive portal was low.

[brwainer]

51 minutes ago, Mikensan said:

I'll probably throw up a quick pfsense in place of the USG to double check it isn't an issue on the client side (interferance from hotspot security) - honestly hadn't considered this as an issue, good point. I have tried testing over my carrier with my cellphone with the same crap luck - but mobile networks aren't exactly a bar to go by.

 

I would run 443/TCP as well, but my experience has been that the traffic is blocked until you click "agree" or whatever the captive portal is asking for. Just wanting to avoid the tedious nature of logging into a captive portal every time. Started off as a "just because" and has turned into a "why isn't this working".

 

Normally I would've thought external DNS would outright be denied, forcing clients to use internal DNS servers for more insight and control. I do this at home, preventing devices from using outside DNS. Although I suppose this is just one more "public" service to be attacked. Only issue is with the handful of IOT devices like Chromecast that demand to use 8.8.8.8 etc...

 

I will say I've only tested on less sensitive networks: McDonalds / Starbucks / Malls, so my expectation of security outside a captive portal was low.

Your idea to bypass the portal isn’t a bad one, but just has some issues. If you set up a DNS server on that public IP/port, does it respond properly? I would do this as a test just to make sure.

 

Wedo need to be careful though - the rules of this forum is that we can’t discuss bypassing legal security and policy measures.

 

For just running around, having to click accept is no big deal to me. When I’m supporting a semi-permanent install, I set up remote monitoring to email me when it goes down, and train someone local how to get it back up (connect to the router via wired or wireless and accept the TOS again). I’m only setting this up for a weekend at a time for convention networking so it isn’t a big deal.

[Mikensan]

1 minute ago, brwainer said:

Your idea to bypass the portal isn’t a bad one, but just has some issues. If you set up a DNS server on that public IP/port, does it respond properly? I would do this as a test just to make sure.

 

Wedo need to be careful though - the rules of this forum is that we can’t discuss bypassing legal security and policy measures.

 

For just running around, having to click accept is no big deal to me. When I’m supporting a semi-permanent install, I set up remote monitoring to email me when it goes down, and train someone local how to get it back up (connect to the router via wired or wireless and accept the TOS again). I’m only setting this up for a weekend at a time for convention networking so it isn’t a big deal.

 

Would definitely like to narrow down the issue, will try out what we've talked about. 

 

Yea it certainly straddles the grey line, even if not malicious in nature. I'll focus my replies on just getting OpenVPN to work nicely over port 53 in any situation, not just those with a captive portal. Since the issue persists on my mobile network I'll just use that as my medium for testing. If in the end it isn't meant to be, no biggy - just one of those side-home-projects I've got myself caught up in.

 

It normally doesn't bother me either, I came across a reddit post where somebody was port forwarding 53 to their OpenVPN and it just got the dusty cogs in my head spinning.

[brwainer]

57 minutes ago, Mikensan said:

 

Would definitely like to narrow down the issue, will try out what we've talked about. 

 

Yea it certainly straddles the grey line, even if not malicious in nature. I'll focus my replies on just getting OpenVPN to work nicely over port 53 in any situation, not just those with a captive portal. Since the issue persists on my mobile network I'll just use that as my medium for testing. If in the end it isn't meant to be, no biggy - just one of those side-home-projects I've got myself caught up in.

 

It normally doesn't bother me either, I came across a reddit post where somebody was port forwarding 53 to their OpenVPN and it just got the dusty cogs in my head spinning.

I also wonder if this use of UDP/53 might get blocked by anything meant to stop DOS attacks - especially when you are talking about the mobile network situation. DNS is (or used to be) a common type of reflection amplification attack.