Bypassing ISP packet sniffing with OpenWrt

My only option where I live in the US is 4glte internet, I use a BananaPi and MC7455 with OpenWrt as a modem. The problem is that my provider is using deep packet sniffing to throttle my speed when they see I am using a service they do not like (Amazon Prime streaming, Hulu, Netflix, etc...).

Using a VPN does not help because the above services do not allow access from a VPN so I am stuck, do I have any options for avoiding packet sniffing without the VPN?

Throttling is common for LTE networks, often claimed with fair share...

DPI is only escapable with a VPN. But how is the ISP preventing access to VPN services?

If the VPN connectivity would be over TCP with remote/exit node port 443 it would be hard to block that, though blocking can still be done with geo ip range mapping, i.e. preventing known commercial VPN ip ranges from being accessible.

One potential workaround is to lease a Virtual Private Server, preferable with a residential ip from its provider and operate your own VPN exit node. How long that lasts until the LTE provider gets an inkling is anybody's guess - probably not for long.


Thanks for that info, is it possible to get around the DPI with a local VPN server on my modem?

It is not the ISP that cares about the vpn but rather the streaming services

Where are you placing the local VPN server?

Yes, but they care about where your traffic goes, so it can be throttled. Not sure you understand the point of the VPN in this instance is to encrypt the traffic so it cannot be seen, hence cant be throttled. Placing the VPN server locally will not obscure the traffic to the ISP's point of view.


Fighting LTE data/bandwidth capping/throttling is likely an uphill battle. It is probably stated in the ISP's terms and conditions of what goes and what not.

I am not in the habit of promoting services but just having run a search may produce alternative providers?

Get unlimited data without usage based throttling or high speed data caps

Of course do not know whether they keep the promotional promises but at least seem to offer a 30-day trial

1 Like

Would using dns over https help here?

1 Like

No, it would just render the DNS recursion outside and encrypted of the LTE ISP.

The subsequent and actual connection attempt to the target host (ip) would still be visible to the LTE ISP.


You need a VPN server "past" your ISP somewhere. There are commercial services (none of which can I recommend for a variety of reasons) or you can try to provision a VPS in the country that you have your subscriptions, and hope that your services don't block those server blocks. A reasonable VPS can be "rented" for US$5 a month. Setting one up for WireGuard is straightforward, once you understand WireGuard's somewhat confusing configuration nomenclature.


Disadvantage though is UDP which can be easily picked up by the ISP (and potentially blocked) as opposed to TCP port 443. That is what I meant with

There had been various request (mainly from China) on the WireGuard mailing list to get WG traffic disguised via TCP 443 since the Great FireWall sorts UDP unequivocally

1 Like depends on what port you use; but I'm not sure I agree that it has to be TCP, or specifically 443/tcp. I would suggest 5060/udp or 5061/udp (or perhaps P2P or Bitcoin ports), or if you insist on TCP, use OpenVPN on the VPN server.

  • You're not in China, are you?
  • I guess this means you believe that all UDP is good... :slightly_frowning_face:
  • Also, it may be problematic to obscure traffic through the [great] firewall.
1 Like

The point I was trying to make is that encrypted udp traffic is much easier distinguishable than TCP over port 443 and the cited requests from China being more a case in point.
That is as far as I would like to digress from the thread topic, reckon having depleted my 5 cents on the buck.


Thanks for the responses everyone!

It looks like the consensuses here is that I need a VPN using TCP to get around the restrictions, it also looks like my restriction is coming from the number of devices connected. If I connect more then 15 devices my data gets cut instantly...

This is puzzling, as I assume that you've got a single IP address and are using NAT for the other devices. If that's the case, since all have your single IP as the source address, it is "challenging, at best" for the ISP to determine how many different devices you have attached. While technically possible, I would guess it is more around number or rate of connections.

1 Like

Interesting, but if that were the case why would the vpn make a difference?

The traffic inside the tunnel is encrypted and can be considered as a single connection by the ISP.


You might get away with it, short or long term, TCP or UDP, whichever port and encryption method - it just depends on how the ISP is operating its network and their terms and conditions.

Whilst the packages travelling inside the VPN tunnel are supposedly safe from DPI the ISP can still determine the data volume on the VPN route and choose to block the ip of the given VPN end point.
Seen this happening with folks trying to circumvent data volume capping a/o bandwidth throttling on LTE networks and the user ended up switching the ISP.

Flat rate LTE (no usage based throttling or high speed data caps) are usually more expensive, which is logical considering the available bandwidth shared per radio tower and number of users connected to it at any one given time.

Another point to consider is the relatively high number of clients (15+) on your LAN sharing a single LTE connection. It may simply reach a saturation point where the number and type of connections could result in a low bandwidth throughput. The hardware (pi CPU/board a/o modem) processing capabilities may come into play at some point too.


I use SSH tonnels to bypass monitoring and shaping. It's cheap (well... free, all you need just router/server with SSH access outside) and quite fast. Check it, if you wish.

PS: Working well for China firewall bypass as well.

1 Like

OpenVPN can be disguised as HTTPS traffic.

1 Like

If not mistaken UDP traffic does not work inside ssh tunnelling and it does not encapsulate. Alternative might be secure socks5 proxying.

It's possible to set up a full featured SSH VPN and there's even NetworkManager support for it in Linux, though I wasn't able to achieve the same level of fault tolerance as when using OpenVPN.