So, with @anav’s awesome help I was able to get my Site to Site Fully tunneled Wireguard VPN working.
HOWEVER, the primary goal of this was to not have to dish out another $70/mo to Hulu for another Live TV Subscription for my best friend who’s at my house 90% of the time anyway cause they also work for me.
EVERYTHING Works on the tunnel -except- Hulu.
Hulu appears to be doing some sort of deep packet inspection that’s somehow “figuring out” that a “VPN” is in play.
Does anyone have any ideas what this might be, or have any suggestions on how I can defeat this protection?
HULU is provided how in its original format, via your normal cable / bell provider??
Since its a US based Service one has to ensure access is from a US location.
If you have a home network designated does that mean a specific IP address structure is required?
Are you allowed multiple connection points ??? Can i use Hulu at my house, turn it off and then go to my friends house and use it, or to the next state over and use it???
If you are using a third party VPN, then HULU probably detects the same or similar public IP using the service which is like a red flag that VPN is being used.
However I get the sense that you just want to be able to watch HULU that you pay for, from a different household.
Now if trying to do that at the same time, that would be problematic wouldnt it??
They may look at path MTU / MSS sizes and detect a VPN that way. If so, using a VPN type that slices packets at encapsulation level rather than fragmenting them at IP level should help, allowing the path MTU to stay at 1500 bytes. L2TP in MLPPP mode provides this. PPTP might work as well, never tried that. You can keep using Wireguard as the encryption layer, i.e. you can use plain L2TP without IPsec. The price to pay is a double packet rate as compared to the standalone Wireguard, which should not be critical.
Okay so you are saying nothing changes as per wireguard goes…
What is different is that we are sending an L2TP subnet out wireguard vice a standard lan subnet out wireguard, so to speak…
How to begin LOL… So we create an ispecless L2TP instance, sounds like fun. Cannot wait to here more. Dont look at me I cannot even fathom what a PPP local address vice remote address means.
I suspect that, the HOME Router will be the LT2P server and the other end the Remote client. Conceptually speaking we are creating an unencrypted path over wireguard from client to server.
One will have to create a faux VPN IP address at each end that is different.
For the purposes of ease of wireguard…
Traffic will be sourcenatted to this VPN faux L2TP IP at the Remote site before entering the tunnel heading for the IPTV source at the home router (pull).
No passwords or encryptions needed.
So in wireguard, the allowed IPs at the remote end will have to include the home server faux VPN address ??? as a ‘destination subnet’ and of course the wireguard IP address of the server.
At the remote end we must have a route that includes
add dst-address=fauxaddressofhomeServer gateway=wireguard table=main
at the home server the allowed IPs must include the faux VPN address of the remote site (incoming from remote site)
a route must be made
add dst-address=fauxaddressof remote server gateway=wireguard table=main. So that return traffic from IPTV has a path.
Then there will be the firewaall rules.
At remote side, allow VPN faux traffic IP to wireguard tunnel (return traffic auto covered).
At home server site, allow wireguard traffic to faux VPN IP…
What I am not sure of at home site is how the faux VPN IP then goes to IPTV and how that traffic reaches back to faux L2tp VPN IP and then back through the tunnel.
if you use an application that app can collect information about your environment and client device to identify your usage habits beyond anything you can do in networking
if you use a web browser without giving the site permissions to anything like location notifications etc you have a better chance of obscuring your habits
If you already have one working VPN between the two sites, use EoIP with 1500 MTU.
Is like the two routes are directly connected by ethernet cable, and MTU is not changed.
IF EoIP is used (or other similar) there is no way on WAN to detect if the device is connected directly to main router or on the remote EoIP side.
Obviously change the latency.
My preference of L2TP with MLPPP comes from the fact that in this case, the transport packets are not fragmented in the IP sense, and I have experienced issues with delivery of fragments on multiple network paths unrelated to each other. So EoIP is definitely a bit simpler to set up, but there is some chance for a bonus puzzle.
You have added another word to the equation Sindy. MLPPP, where does that fit in? Are you suggesting that L2TP has to be combined with MLPPP in that solution. Okay so I know MLPPP has nothing to do with major league baseball…
I have already mentioned that in #3. Multi-Link PPP is an extension to PPP that is named after its ability to send parts of the same payload packet using multiple transport links, but the mechanism allowing that can be used on a single link too. The result is that the payload packet is split into multiple transport packets that fit the MTU of the transport link, so the transport packets need not get fragmented.
Okay so it sounds like LT2P in MLPPP mode is a more optimal solution than EOIP, in terms of actual projected capability/functionality (expectation of success), whilst EOIP may be easier to initiate.
Yeah I was thinking MTU might be something they are inspecting and throwing flags on.
Hulu with Live TV requires all devices accessing “Live TV” except actual mobile devices be on the same IP.
Theoretically, this could be solved with my friend just casting their phone to their TV and using the Hulu App. But they won’t do that because then they “Can’t play games while they watch TV.”
Hulu requires you to be on your “Home Wifi” every 30 days to keep it “active”.
I am like “owqhigioahwgeoihwegiohwaeriogh you can’t do both anyway either WATCH TV OR DON’T” but you know that’s not an option.
It sounds like EOIP may be the way to go if it essentially wraps everything an extra time to make everything look like a standard raw lan packet .
Can you expand on this statement.
So if you pay for hulu TV service, you cannot have two TVs in the house on at the same time as they will have two different IP addresses on the home private network,
or do you mean the same PUBLIC IP?
.