[APP][ROOT][6+] Tether TPROXY v0.1 (USB, Wifi Hotspot, Ethernet)

Search This thread

fddm

Senior Member
Feb 24, 2011
283
182
Thanks for reporting back! Unfortunately you already have dun set in your primary APN, so that's not what is causing the issue here. I don't have a subscription to the VZW network and am unable to do testing for this issue. When you say that it doesn't work, is it that no traffic passes, that traffic counts towards your tethering allotment, or it's throttled down as if it were regular tethered traffic?

I take it that your app basically "proxifies/socksifies" traffic on the phone's tether interfaces to a local SOCKS5 proxy service/app on the phone.
That's right, it uses the iptables tproxy module supported on most modern Android phones to redirect tethered traffic through a local proxy. The idea is that packets are recreated on the phone with the correct TTL/HL and the origin of the traffic is obscured.

What's most interesting about this approach to me is that you could run the proxy server on the phone, tproxy server on an OpenWRT device, and connect them through an adb tunnel. This in theory would bypass entitlement, APN dun profile, and TTL/HL dpi detection - all with a phone that is in an entirely stock state.

For IPv6 "GUA" is global unicast addresses (Internet routable) and "ULA" is unique local addresses (private IP addresses). I am not sure why you would want to choose a ULA in this situation since the goal is Internet access. Are the IP addresses on that configuration screen in the screenshot above the local addresses for the SOCKS5 proxy? If so, would using a ULA address for its IPv6 address mean that the clients would also need ULA addresses to access it? If so, how would the clients get those addresses? Self-generate them or does that setting set dnsmasq to issue ULA IPv6's to the tethered clients? Since (if?) you are using a SOCKS5 proxy to send the Internet traffic I am not sure why you say above that using "ULA" for IPv6 will prefer IPv4 when the IPv4 address is also a private one. Why favor private IPv4 over private IPv6?
This setting effects the preferred protocol version for connected clients (per RFC 3484). GUA tells DNSMASQ to assign local IPs in the 2001:db8::/64 range, which is treated like a real public address, so clients will prefer sending their traffic through IPv6. ULA assigns addresses in the fd00::/64 range, so clients will send traffic through IPv4 by default.
 
  • Like
Reactions: JDToo

J0nhy

Senior Member
Jan 22, 2016
293
67
Thanks for reporting back! Unfortunately you already have dun set in your primary APN, so that's not what is causing the issue here. I don't have a subscription to the VZW network and am unable to do testing for this issue. When you say that it doesn't work, is it that no traffic passes, that traffic counts towards your tethering allotment, or it's throttled down as if it were regular tethered traffic?


That's right, it uses the iptables tproxy module supported on most modern Android phones to redirect tethered traffic through a local proxy. The idea is that packets are recreated on the phone with the correct TTL/HL and the origin of the traffic is obscured.

What's most interesting about this approach to me is that you could run the proxy server on the phone, tproxy server on an OpenWRT device, and connect them through an adb tunnel. This in theory would bypass entitlement, APN dun profile, and TTL/HL dpi detection - all with a phone that is in an entirely stock state.


This setting effects the preferred protocol version for connected clients (per RFC 3484). GUA tells DNSMASQ to assign local IPs in the 2001:db8::/64 range, which is treated like a real public address, so clients will prefer sending their traffic through IPv6. ULA assigns addresses in the fd00::/64 range, so clients will send traffic through IPv4 by default.
Is not happening only with Verizon it happens with any sim on my phone either esim or psim,, thanks anyways

Here's the outcome for tmo
Row: 0 _id=799, name=T-Mobile US, numeric=310260, mcc=310, mnc=260, carrier_id=-1, apn=fast.t-mobile.com, user=, server=*, password=, proxy=, port=, mmsproxy=, mmsport=, mmsc=http://mms.msg.eng.t-mobile.com/mms/wapenc, authtype=-1, type=default,supl,mms, current=0, protocol=IPV4V6, roaming_protocol=IPV4V6, carrier_enabled=1, bearer=0, bearer_bitmask=917503, network_type_bitmask=916479, lingering_network_type_bitmask=0, mvno_type=, mvno_match_data=, sub_id=-1, profile_id=0, modem_cognitive=0, max_conns=0, wait_time=0, max_conns_time=0, mtu=1440, mtu_v4=0, mtu_v6=0, edited=0, user_visible=1, user_editable=0, owned_by=1, apn_set_id=0, skip_464xlat=-1, always_on=0
 

JDToo

Member
Feb 1, 2015
16
1
What's most interesting about this approach to me is that you could run the proxy server on the phone, tproxy server on an OpenWRT device, and connect them through an adb tunnel. This in theory would bypass entitlement, APN dun profile, and TTL/HL dpi detection - all with a phone that is in an entirely stock state.
It's a great approach to the problem. I have been looking at doing the same thing using Redsocks and Wi-Fi hotspot running on a Linux PC to get devices like TV's that don't have SOCKS support to be able to traverse through an unrooted tethered phone running a SOCKS5 server. I previously bricked an old router with DD-RT so I have been hesitant to use one with it or OpenWRT to do this, but if you have a router that certifiably works with either replacement firmware, it would be a more convenient choice.
 
Last edited:

fddm

Senior Member
Feb 24, 2011
283
182
Since you have root, you can just install the kmod-usb-net-rndis in OpenWRT, bridge usb0 to lan, and disable DHCP. That'll let you use your phone's USB tethering as a wan to serve your network.
Add kernel RNDIS support:
Code:
opkg update
opkg install kmod-usb-net-rndis

Network -> Interfaces -> Devices Tab
-> Configure br-lan

Bridge Ports: add usb0

Network -> Interfaces -> LAN
-> DHCP Server
--> General Setup

Check "Ignore interface"

For routers, I find Linksys to be the cheapest. You'll want a Qualcomm or Mediatek CPU with a USB2+ port. There is a bug with Qualcomm USB3 where the driver can crash when plugging in a phone. This is easily fixed with a script, but it's easier to just recommend Mediatek hardware:
You need to pay attention to the hardware version when purchasing though, different versions of the same model often have wildly different hardware.

If you edit your APN settings for your APN protocols to "IPv4" and have "dun" in APN type, then you can add this to the router to automatically bypass tether limitations without any app:
Lets you set the outgoing TTL if your unable to set it on your phone. IPv4 only.

Code:
opkg update
opkg install iptables-mod-ipopt
opkg install iptables-mod-physdev

System -> Startup -> Local startup
Code:
sysctl -w net.bridge.bridge-nf-call-arptables=1
sysctl -w net.bridge.bridge-nf-call-iptables=1
sysctl -w net.bridge.bridge-nf-call-ip6tables=1

Network -> Firewall -> Custom Rules
Code:
iptables -t mangle -I POSTROUTING -m physdev --physdev-out usb0 -j TTL --ttl-set 65

Alternatively, I always recommend VPN Hotspot with a local VPN like Adguard for bypassing restrictions. It's relatively foolproof to set up. Just need to make sure to disable IPv6 and Tether hardware acceleration in the app.
 
Last edited:
  • Like
Reactions: JDToo

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    Screenshot (Mar 27, 2022 11 29 09 PM).png

    Tether TPROXY uses iptables tproxy rules to capture tethered traffic and route it through a local proxy. This allows you to tether through your phone's internet source, be it a VPN or whatever else. Should also bypass APN classification and TTL/HL DPI checks. It supports TCP and UDP for IPv4 and IPv6. It can not proxy raw packets like ICMP, you can disable "Prevent Leaking" if required for your setup.

    Tether TPROXY should support all tethering operations(USB, Wifi Hotspot, Ethernet). It does not enable tethering, that needs to be done manually.

    Options:
    Prevent Leaking - Allow traffic to exit through tproxy exclusively. Drops traffic on the forward chain of the filter table.
    DPI Circumvention - Passes traffic on ports 80 and 443 to tpws to skirt DPI. Gives you proper fast.com scores.
    Enable Dnsmasq - Bypass the built-in services and use Dnsmasq to provide DHCP/DHCP6/SLAAC/DNS.
    IPv4 Address* - Lets you pick your IPv4 address/prefix. Makes it possible to set static addresses on your devices.
    IPv6 Prefix* - ULA makes devices prefer using IPv4, GUA makes devices prefer IPv6.
    *Only takes effect when Dnsmasq is enabled

    Notes:
    -After disabling the service, you will need to restart any active tethers you have running
    -You may need to set APN protocol to IPv6 or IPv4/IPv6 to enable IPv6 for your mobile network.
    -Dnsmasq can be used to get IPv6 working, but it is not recommended if you want traffic to leak.
    -When using Dnsmasq, clients connected before the service is started will need to reconnect to get new addresses/routes.

    Requires a kernel built with CONFIG_NETFILTER_XT_TARGET_TPROXY

    Dependencies:
    hev-socks5-server - https://github.com/heiher/hev-socks5-server
    hev-socks5-tproxy - https://github.com/heiher/hev-socks5-tproxy
    tpws - https://github.com/bol-van/zapret
    Dnsmasq - https://github.com/worstperson/dnsmasq

    Source:

    Download:
    1
    [How it works]
    When the service is enabled, it applies iptables rules and starts any servers required. These rules do not depend on the interface so they apply to all tethered traffic with no additions. This alone is enough for IPv4 to work.

    The service also listens to "android.net.conn.TETHER_STATE_CHANGED" which fires whenever tethering is enabled or disabled. The service waits 5 seconds and then checks for Android's Dnsmasq listening on port 53 to tell if tethering is active. That IP is checked against established routes to get the active tether interface. With that, we can find it's IPv6 address and add an exception to allow IPv6 to work. If Dnsmasq is enabled, we also set IPs and routes at this point.

    To get Dnsmasq to work, we need to make it use alternative ports with the options "--port=5353" and "--dhcp-alternate-port=6767,68". Then 3 iptables are used to make clients use them. One takes DHCP broadcasts and redirects them to port 6767, the second takes DNS requests and redirects them to port 5353, and the final rule blocks Router Advertisement packets from non-root processes.
    1
    1
    Thanks for reporting back! Unfortunately you already have dun set in your primary APN, so that's not what is causing the issue here. I don't have a subscription to the VZW network and am unable to do testing for this issue. When you say that it doesn't work, is it that no traffic passes, that traffic counts towards your tethering allotment, or it's throttled down as if it were regular tethered traffic?

    I take it that your app basically "proxifies/socksifies" traffic on the phone's tether interfaces to a local SOCKS5 proxy service/app on the phone.
    That's right, it uses the iptables tproxy module supported on most modern Android phones to redirect tethered traffic through a local proxy. The idea is that packets are recreated on the phone with the correct TTL/HL and the origin of the traffic is obscured.

    What's most interesting about this approach to me is that you could run the proxy server on the phone, tproxy server on an OpenWRT device, and connect them through an adb tunnel. This in theory would bypass entitlement, APN dun profile, and TTL/HL dpi detection - all with a phone that is in an entirely stock state.

    For IPv6 "GUA" is global unicast addresses (Internet routable) and "ULA" is unique local addresses (private IP addresses). I am not sure why you would want to choose a ULA in this situation since the goal is Internet access. Are the IP addresses on that configuration screen in the screenshot above the local addresses for the SOCKS5 proxy? If so, would using a ULA address for its IPv6 address mean that the clients would also need ULA addresses to access it? If so, how would the clients get those addresses? Self-generate them or does that setting set dnsmasq to issue ULA IPv6's to the tethered clients? Since (if?) you are using a SOCKS5 proxy to send the Internet traffic I am not sure why you say above that using "ULA" for IPv6 will prefer IPv4 when the IPv4 address is also a private one. Why favor private IPv4 over private IPv6?
    This setting effects the preferred protocol version for connected clients (per RFC 3484). GUA tells DNSMASQ to assign local IPs in the 2001:db8::/64 range, which is treated like a real public address, so clients will prefer sending their traffic through IPv6. ULA assigns addresses in the fd00::/64 range, so clients will send traffic through IPv4 by default.
    1
    Since you have root, you can just install the kmod-usb-net-rndis in OpenWRT, bridge usb0 to lan, and disable DHCP. That'll let you use your phone's USB tethering as a wan to serve your network.
    Add kernel RNDIS support:
    Code:
    opkg update
    opkg install kmod-usb-net-rndis

    Network -> Interfaces -> Devices Tab
    -> Configure br-lan

    Bridge Ports: add usb0

    Network -> Interfaces -> LAN
    -> DHCP Server
    --> General Setup

    Check "Ignore interface"

    For routers, I find Linksys to be the cheapest. You'll want a Qualcomm or Mediatek CPU with a USB2+ port. There is a bug with Qualcomm USB3 where the driver can crash when plugging in a phone. This is easily fixed with a script, but it's easier to just recommend Mediatek hardware:
    You need to pay attention to the hardware version when purchasing though, different versions of the same model often have wildly different hardware.

    If you edit your APN settings for your APN protocols to "IPv4" and have "dun" in APN type, then you can add this to the router to automatically bypass tether limitations without any app:
    Lets you set the outgoing TTL if your unable to set it on your phone. IPv4 only.

    Code:
    opkg update
    opkg install iptables-mod-ipopt
    opkg install iptables-mod-physdev

    System -> Startup -> Local startup
    Code:
    sysctl -w net.bridge.bridge-nf-call-arptables=1
    sysctl -w net.bridge.bridge-nf-call-iptables=1
    sysctl -w net.bridge.bridge-nf-call-ip6tables=1

    Network -> Firewall -> Custom Rules
    Code:
    iptables -t mangle -I POSTROUTING -m physdev --physdev-out usb0 -j TTL --ttl-set 65

    Alternatively, I always recommend VPN Hotspot with a local VPN like Adguard for bypassing restrictions. It's relatively foolproof to set up. Just need to make sure to disable IPv6 and Tether hardware acceleration in the app.