I would like to share my great idea with OpenWRT community.
many of OpenWRT users are using OpenWRT because of the capability to make their home router as VPN client and route all traffic through a VPN Server (either commercial VPN Server or their own built VPN Server).
now , clients in their home network are using the router to get access to the Internet. there are some app , for example HULU streaming services that it's doing all it can to determine if it is running behind a VPN connection or Proxy.
I was thinking how actually HULU app can determine if it's running behind a VPN or NOT. one option is with IP reputation database. but lets assume that the IP Address is not FLAGED as VPN Server base. still HULU app can perform additional checkups to determine if it is running behind a VPN. How ? to do simple PING request to destination in the same GEO zone that the VPN client pretended to be. if the latency is between the acceptable range then this eliminate the thinking that the Client sits behind VPN , but if the latency is outside the acceptable range then there is great suspicious that the Client sits behind a VPN connection.
now , how actually the OpenWRT community can help in this ?
I will tell you how.
OpenWRT should have a software package that provide fake ICMP results for specific clients.
Assuming that you have a streamer , Like just for the sake of the example , lets say Amazon FireTV Stick. which itis being connected through WiFi to OpenWRT router. once you installed that software Package which can help you in faking ICMP result. you can choose which clients will have fake ICMP results. that package should provide you the capability to choose which Clients in the network will get fake ICMP results. besides that , the OpenWRT will catch those ICMP communications and will fake the result. so for example:
Amazon FireTV HDMI Stick , get an IP address in the internal network like: 192.168.1.140
OpenWRT has IP address such as: 192.168.1.1
OpenWRT will do deep packet inspections for specific clients you choose. you choose in our example 192.168.1.140
once OpenWRT catch a packet which contains ICMP request to a destination. then OpenWRT will fake the response with predefined delay.
good idea ? what do you think ? can the OpenWRT community would like to develop such thing ? share your ideas in this thread.
Leaving the potential contractual issues aside, the first step would be for you to confirm that the client actually follows your scheme and employs ICMP for that purpose.
If the homerouter is the vpn server than the clients are usually smartphones, smartpads, laptops etc somewhere out in the world calling home to either get data from home or surfing through the home ISP connection.
Why would that setup want fake and slower ICMP results?
no One say local LAN.
OpenWRT will do Deep Packet Inspection for specific Clients only.
means , it will only take a look on Packets originated from Specific IP Address from the LAN Network. any other IP source will dismiss and continue communication without manipulation.
who cares about legal ? lets assume that those applications are doing latency check for determine that they are really originating from the GEO location that advertised and being really the case.
if you think about this more forward. this software addon for OpenWRT can potentially will raise up the usage of OpenWRT. why ?
because this ICMP manipulation can be beneficial for workers around the world that work from HOME and declare for their employer that they work from one location but in reality they work from another location. by doing ICMP manipulation by catching the packets on the OpenWRT router they will never discover their real location.
WOW , I brought here a great idea for feature development for OpenWRT.
Anyone actually wanting a long living business of some sort cares about legal.
And if the streaming services start loosing money they start hunting season for the problem.
But they come with the solution as a asymmetrical but long term fixing of the problem!
We just give lobbyist and politicians in EU and USA another nail in the coffin for the goal of the router manufacturers to start to encrypt the router firmwares and âdeath to open sourceâ which they canât control.
Use Xiaomi Router AX3000T which is made in CHINA with OpenWRT. it is not EU and not USA. most of the routers that using OpenWRT are already made in CHINA and not EU and NOT USA. actually even the USA routers like D-Link are made in Vietnam and not CHINA.
but lets not change the objective and the subject of this thread. I brought here an idea for feature request.
OpenWRT is the community. if the community will find that my IDEA is good for use case and there is great demand for it , maybe the development on this would come.
the streaming companies are getting money from the customers. NO one is saying not to pay to the streaming companies. but GEO limitation. this is NO NO. why someone from USA will get better pricing from EU market ? this is just an example.
or why someone from another country will not get all the content which available in USA but the streaming company decided that in another country they will take more money and provide shrink version of the same version. pay more money and get less.
again this is just an example.
my FEATURE idea is for any USE CASE. not just streaming. manipulate ICMP latency this is all about. GREAT idea. the community need to develop a solution for this. this is my opinion.
But, just for giggles, how do you think you could a) send a ping from an external host to a device within a LAN that only has a private IP, and b) end up responding to that ping in less time than it actually takes the packet to travel the distance?
you did not understand my idea.
Local LAN , LOCAL LAN !!! client in the LOCAL LAN that OpenWRT acts as their router !!!
Deep packet inspection.
Software filter the packet. once it finds a match for ICMP ECHO.
the Software looks on the destination. it creates a fake response to looks like that it is coming back from the real destination. how much intensive this would be for a router CPU ? need to first develop this feature and then do testing and QA.
I don't think you understand how networking works...
And how exactly does that allow a remote host to ping a device behind a NAT firewall? How do you think the remote host is targeting a specific device rather than the public IP?
A fake response that somehow responds quicker than the time it takes the packets (including the fake response) to travel the distance between the two routers? How do you figure that's going to work?
We already know DPI is an CPU resource intensive process. That's why it's not commonly used on consumer level router hardware.
you really do not follow me.
I never said REMOTE HOST pinging.
I said local host in the LAN generating a PING for getting the latency and understand the latency between it to a remote host which exist in the INTERNET network.
The streaming service is a remote host. You're the one who claimed they're pinging to determine latency and comparing it against a known value to determine if your device is in the same region.
That doesn't even make sense as a sentence, let alone as a networking idea.
You also say this a lot.
First of all I donât even know if we have any support of this function at this time, to this day I have never seen much written about it here or in the wiki?
But deep package inspection usually arenât mentioned in home router datasheets because this function is cpu intensive and a business class networking thing where many times it is a hardware module in the SoC that do this job isolated. Just as the hardware crypto accelerators.
I started this thread with bringing an IDEA for manipulating ICMP response in order to manipulate the latency.
I wrote. the CLIENT which is streamer device , NOT STREAMER company. NOT STERAMER Server. again , Streamer CLIENT. it can be Amazon FireTV HDMI , it could be a laptop , it can be anything else.
the streaming software which is running on those devices would like to determine the real location , and compare it with the public address. so , the software send ICMP to check the latency.
if for example you sit in NYC , and the software send a PING test to destination. and the response is greater than 10ms , the software will try again , if it see that it is steady 150 ms and not 10ms , the software understand that someone is not really sits physically on the GEO location where the Public IP address is.
this is where OpenWRT ICMP manipulation come into the picture.
This isnât how internet works, it is per design impossible to tell what way data travels on the internet and how long time it takes.
That is why you can end up in a problem that when sending a lot of data in many packages the data packages arrives in the wrong order because the first package was a globetrotter and traveled longer that the last package that arrived first before the first package.
But as far as I have understand the streaming services are finding the vpn servers by simply looking how many connections comes from one suspect server.
correct , but it is not required. because if the USER wants to enable the ICMP manipulation then it knows that there is BIG GAP !!! between what should be the latency if he was sitting in reality in the same GEO location like the IP address of the VPN Server.
for example , I understand that it was difficult for you to follow me and understand me so I will try with an example.
my VPN server , has IP address of NYC.
I am running ping from a CLIENT on my home , to destination in NYC , I get 150 ms
if I was really sit in NYC , I would get 10ms
now , think the a streaming software generating the PING , it gets 150 ms and not 10 ms.
there is a BiG GAP between 150ms and 10ms , the steaming software determine you are using a proxy or VPN. boom , you are being blocked by the streaming software.
if OpenWRT would manipulate the ICMP , OpenWRT catch the packet that comes from inside the LAN , not giving it to leave the home network. but creates a fake response. what will be the latency of the fake response ? the processing time. which for sure will be less than 150ms.
ICMP is UDP , not TCP. as far as I remember UDP is connection less. not giving importance for the order !!!
NOT only , but also with Latency. again , I am providing here an idea for feature development that only application users that need such feature enabled in their local network would use. not everyone needs such thing
Oh, you just want to capture the echo request, discard it, and then forge a echo reply. And do this with a small enough delay that the reply still looks local. So nothing overly complicated then.
Good thing you've confirmed that streaming services definitely use pings (coming from the local device) to determine location. Wouldn't want someone wasting time creating a 'solution' to a problem that doesn't exist.