Hi, I am using CNPilots e410 for guest access in our remote hospital in Sudan. We have very limited bandwidth. We use vouchers via CNMaestro. The problem I have is people have figured out how to bypass the voucher system by using zero VPN. If I look on CNMaestro I can see clients connected on the guest access SSID, and their authentication status is false, but they are still downloading and uploading.
I found a similar thread about unifi controllers talking about using zero vpn to bypass their voucher system.
"ZeroVPN is using DNS2TCP to pass traffic over the DNS ports of the network. We don’t block DNS traffic by default as the client needs to be able to resolve domain names such as the controller hostname during guest authentication - and if the client is using a third-party manually configured DNS, blocking it would break the portal for that client.
The solution is to have all traffic that is on port UDP:AnyIP:53 redirected to your router, and configure the router as a DNS forwarder/cacher as necessary."
Does that seem like it would be the vector used against the CNPilot? If so can anyone help me set up a workaround for the CNpilot?
Could you set up your router to grab any request sent to 53 and redirect it to your router.
I did this in Mikrotik to force people on the guest network to use a “kid safe DNS service.”
When you request an IP from the guest DHCP server. You get the kid safe DNS as your DNS via DHCP. I have a nat rule that grabs any packets sent to port 53 not destined to that kid safe DNS… Gets sent there anyways.
A similar issue was observed by one of the ISPs in Southeast Asia, who reported massive amounts of traffic( on port 53) from clients prior to authentication. To mitigate, we recommend allowing just known DNS traffic and blocking all other DNS traffic. At the end of the ACL rule, be sure to allow all IP traffic. Please let me know if you require assistance in setting up the rule in the AP.
I was thinking something similar, but I am not sure how to set it up. Step by step instructions would be very helpful. It is consuming most of our bandwidth. I have resorted to blocking mac addresses, but it is trivial to spoof a new mac.
I’ve attached a snippet of conf that allows DNS traffic only to the IP addresses 202.5.117.1 and 192.168.246.1, denies all other DNS (PRECEDENCE 255) traffic from clients , and finally allows all IP traffic (PRECEDENCE 256).
ACL can be configured from the wireless wlan configuration page.
Can someone look to see if there is an issue with the acl list I set up via web ui? I set it up on a test network, and I can get a connection through, but I don’t know yet if it will block traffic on 53.
I got ahold of one of the phones someone was using. They were using an app called thunder vpn. So I downloaded it, and sure enough I can bypass the voucher system. So I used the packet capture and can confirm the data is being passed on port 53. I can’t seem to get the acl list in the web ui to work. Can someone take a look at this and see where I have gone wrong. I want to deny all port 53 traffic not going to my preferred dns, but when I look at the packet capture it is still getting through.
You didnt follow rules of @Anandakrishnan.
Also note precedence numbers, last statement is precedence 256 (Allow_All), Deny_allother_DNS is precedence 255 which is execute before 256
I am getting very strange results using the web ui acl list. If you look at the screen shot I have taken it seems to reverse source port, and Destination IP/Mask. Can someone confirm if these are being reversed or recreate the issue. This is happening for every rule I put.
Hi Chris,
Please double-check that the direction you gave is “out” and the description is “in.”
SIP DIP SP DP is the order, therefore the “any” after the IP address 208.67.222.123 is the destination IP. For Protocol, you’ve selected “any” , better way to manage ACL rules is to have independent rules for protocols. So, better to create two sets of rules, one for UDP and the other for TCP.
The IN rule is hitting the AP on the WLAN IN direction, so to allow traffic from client to destination IP address x.x.x.x with port number 53, the rule you should add is
Policy – Permit
direction – IN
proto – UDP/TCP
SIP – any
SP – any
DIP – x.x.x.x
DP – 53
I had In and out intuitively backwards in my mind. It still seems like there is an issue with the web ui switching SP and DIP see my last post. Can you look at that and comment?
This seems to work at least on my phone. I will check tomorrow when there are people trying to get on. It still seems like the web ui is flipping SP and DIP at least in the way that it is written. I had to add a rule to allow 1.1.1.1 53 or the captive portal login would not popup.