Script to block ALL VPN connections

Discussion in 'Tomato Firmware' started by Magdiel1975, Sep 10, 2016.

  1. Magdiel1975

    Magdiel1975 Addicted to LI Member

    I am using Shibby Tomato v132. I have "Intercept DNS port
    (UDP 53)" checked. - -

    Is there a script or anything I can do to block internet connection to users using vpn plugins like DotVPN from Chrome?

    I use OpenDns to block porn, but I noticed that if the Chrome plugin DotVPN is installed, it bypasses any and all settings on the router and the user can access any website.

    Is there anything I can do to block these type of connections? - please help, thank you.
  2. vancer32

    vancer32 Networkin' Nut Member

    Exactly the same question I wanted to ask. Any ideas how to do this?
  3. kthaddock

    kthaddock Network Guru Member

    Only way to block is to use ipnumber-block.
  4. Mr9v9

    Mr9v9 Serious Server Member

    I think for PPTP VPN connections, you need to open TCP port 1723 (for PPTP tunnel maintenance traffic). PPTP also uses IP port 47 for tunneling data. Port 47 is designed for "General Routing Encapsulation" or GRE packets.
    For L2TP VPN connections, you need to open UDP port 500 for Internet Key Exchange (IKE) traffic and UDP port 1701 for L2TP traffic.
    So in theory couldn't you just block those ports? I guess it also depends on the type of VPN connection. I know some use use port 80 and 443, so blocking those could end up making much worse problems.
  5. koitsu

    koitsu Network Guru Member

    Some clarification is needed here: there is no such thing as an "IP port". What you're referring to is a IP protocol type/number. ICMP gets protocol 1, TCP gets protocol 11, UDP gets protocol 17, and GRE gets protocol 47. Again: these are not TCP/UDP port numbers, thus you cannot "forward" these using "port forwarding" rules.

    Instead, a firewall must have support for directly referencing the protocol type -- and iptables does via the -p flag. The protocol names iptables understands come directly from the file /etc/protocols on the router, utilised via the getprotobyname(3) libc function. Thus, iptables -p gre will match packets using protocol 47.

    As for the rest of the information: you got this absolutely correct.

    The OPs question appears to have to do with outbound client traffic (i.e. systems on his LAN) utilising VPNs via browser plugins like DotVPN to circumvent firewall or network security rules. The OP will need to install and learn how to use tcpdump on his router to detect/analyse this type of traffic so that it can be blocked by the router itself. Be aware this may be extremely tricky and difficult depending on how DotVPN implemented their methodology. You can see even enterprise folks are being given the same advice I just gave. :) Use of Process Explorer on Windows may also come in handy when reproducing the situation (load up Chrome with the extension installed, be sure to have a home page of about:blank first, then use Process Explorer to do a properties on chrome.exe and review the TCP/IP tab -- you will see all the TCP/IP source/destination endpoints used by the process. It's up to you to figure out which DotVPN uses. For some reason the DotVPN folks don't really disclose this, which is shameful (IMO) on their part).
  6. jerrm

    jerrm Network Guru Member

    None of that is likely to work. Most all the "access blocked sites" vpn clients attempt to tunnel over multiple common ports - 443, 80, 21, 22, 23 etc, rendering simple port blocks useless.

    Most of them deliberately make themselves hard to block - they have a continuously updated long list of potential servers and don't use a defined set of domains or networks, so you can't just block "*" or Trying to block on IP or host name just becomes a game of whack-a-mole.
    koitsu likes this.
  7. Monk E. Boy

    Monk E. Boy Network Guru Member

    What if you add VPN & anonymizer categories to OpenDNS? Block them from doing DNS lookups for DotVPN and it's possible their house of cards will fall down. If they have some IPs hard-coded or if its in their DNS cache from another network then you can't block the DNS lookup since none is made.

    The categories are updated regularly so the whack-a-mole game is much easier, since you just add them to OpenDNS and the list grows larger and larger. Since tens of thousands of people add to the list all the time it tends to be an easier game to play than doing it all on your own.

    Still, they can just hard-code in an IP and defeat the DNS lookup, but when they change providers their IP changes, then their client breaks and thousands of 12yo script kiddies are yelling at them because they can't surf for porn anymore.

    Keep in mind though I have all my ports and packets defined for need-to-work traffic plus L7 filters for things like FTP sometimes need that extra attention, while all undefined traffic gets squelched to 1% in QoS... so even if the VPN connection gets past the DNS blocks, and gets past the port/packet blocks, its so god-awful slow that people quickly rear up and expose themselves by claiming the network is broken, at which point I look at what they're doing, remove the offending client, and tell them to not do that again unless they want to go back to that state.

    Sometimes they even listen.

    Note: This configuration pretty much breaks P2P and anything else that uses a wide variety of ports (unless it has a working L7 filter of course). The good thing is that - so far - I absolutely don't care about that traffic, so yay.
    Last edited: Nov 22, 2016
  8. koitsu

    koitsu Network Guru Member

    Masking/spoofing the DNS results is a clever idea (dnsmasq makes this quite, see address).

    The only downside is that for this to work (or more specifically: to ensure people cannot bypass the behaviour), you need to ensure that client machines cannot use/specify an alternate DNS serve. Hopefully that "Intercept DNS port (UDP 53)" feature of Tomato works as its description implies. :)

    And yeah, if DotVPN ends up hard-coding IP addresses in their plugin then you get to reverse-engineer what those are and explicitly block them (preferably by CIDR/netblock -- I use a combination of ARN and review of announced BGP routes to determine that as best I can). The Process Explorer methodology I described should help, but tcpdump (on the router) would be useful too. You really have to know what you're looking at though; blockin the wrong thing can be detrimental.

    In general, this problem is a social one: a user on your network is doing something that you do not permit/allow. I tend to approach situations like this differently: instead of trying to use technology to block things, I instead talk to the user and explain that said behaviour isn't permitted. It's not a comfortable conversation, but in my experience, the benefits outweigh the negatives as long as the user is reasonable/fair. It's a lot like catching a thief in the act: instead of building mile-high castle walls and iron portcullises to keep a single thief out, you approach them in the middle of their activities, explain that doing said thing isn't permitted/is very uncool and not to do it again, and send them on their way. If they do it again, well, as they say... hell hath no fury like a violated network administrator. ;-)
  9. vancer32

    vancer32 Networkin' Nut Member

    After tinkering and surveillance of users using VPN I have successfully block most of the VPN ports and IP address range with success by using access restrictions. Most of my tenants that use VPN are using cellphone.

    VPN can do the following:
    - bypass Opendns parental controls
    - bypass Google force safesearch
    - bypass Intercept DNS Port (UDP 53)
    - VPN can hide their web usage
    - VPN connections can originate from a single IP Address or just a few IP's like around 2 to 5.

    Normally if you're browsing the web you will open a few tcp/udp ports but can get to 100's or even 1,000's open connections. That's not the case in VPN as it will only open one or few connections and there's no web usage being log. This is the surefire way of catching someone is using VPN. You can also google search the IP Address if its a VPN IP.
  10. macster2075

    macster2075 Connected Client Member

    I also would like to have the ability to block VPN connections on via the router.

    I have noticed that iPhones have parental controls that actually block all the vpn apps I have tried on the phone.
    How is Apple able to do this?

    The way I have set parental controls is... I set the phone to only access the websites on the white list...everything else is blocked. - - so, the vpn app connects, but it will not pull any websites, unless they belong to the white list.

    But, If block access to a certain website at the router level, any vpn will completely bypass any router settings.... this puzzles me... so vpns cannot bypass an iphone, but they can bypass a router?...what?.. how?
  11. eibgrad

    eibgrad Network Guru Member

    You're comparing apples (no pun intended) to oranges here. You have to realize that there's a big difference between what can be done on the local client itself (i.e., the iPhone), vs. a router that's merely one part of a long communications chain between that client and the target device/system.

    The iPhone can block access to VPNs entirely, inform other apps that a VPN is active (allowing them to choose whether they want to allow access through a VPN), or even limit what destination IPs will be allowed over a VPN (i.e., a whitelist). It's all readily available information on the client platform, long before there's even an attempt to start the communications.

    The router is another story. It's a least one step (if not more) removed from that client. All the router "sees" is a source IP and destination IP. And so that's the only criteria upon which a decision can be made to allow/deny access. If you want to restrict access based on source IP, you need to implement PBR (policy based routing). If you want to restrict access to a destination IP (be it a VPN or anything else), you need firewall rules that block access. Unlike the client app itself, the router has no clue about the intent or purposes of any given client beyond these narrow parameters.
    Last edited: Jul 13, 2018
    Monk E. Boy likes this.
  12. Monk E. Boy

    Monk E. Boy Network Guru Member

    If you're willing to live without wifi calling you could block tcp/udp 500 and udp 4500. It's not ideal since clients can still connect to services that don't use standard IPSec, as well as really weird services that tunnel everything over https (I still get nightmares from my time supporting a system like that). However if you get some kind of filtered DNS it can help nip the worst of them. Other interesting ports are tcp/udp 1194 (OpenVPN), tcp/udp 1701 (L2TP), tcp/udp 1723 (PPTP). PPTP is less than widely used these days due to vulnerabilities but desperate children are known to do patently stupid things. The more ports you block the more collateral damage you will have.

    No setup (short of real-time https/ssl inspection, which far exceeds the capability of consumer hardware) is perfect but if you put enough roadblocks in their way most people will usually get frustrated and give up.
    Last edited: Jul 13, 2018
    nodnarb91 likes this.
  13. i1135t

    i1135t Network Guru Member

    I just tested this and opendns ( and, familyshield, blocks DotVPN. How are they getting out? If you are using and, do you have VPN/anonymizers categories checked off for your external IP config?
  14. Monk E. Boy

    Monk E. Boy Network Guru Member

    Its possible if you don't intercept DNS that they could use external DNS servers to get around internal blocking. There's a new Personal VPN category in OpenDNS.
    Last edited: Jul 19, 2018
  15. ruggerof

    ruggerof Network Guru Member

    Alternatively you can go hardcore and use Untangle NG firewall.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice