Mon Apr 18, 2022 10:27 pm
If you cannot find a paragraph clearly labelled then I suspect reading the paragraph will not help.
Suggest changing devices to D-stink, TP-stink, nor Net-crap. ;-PP
Seriously,
The issues is the SERVER (the third party VPN is only expecting one source for IPs coming from the client Router).
Think of it simply. The PEER Settings on the Third party VPN describing the peer (the MT device) include ALLOWED IPs= single IP address.
Put the shoe on the other foot. If I was using an iphone instead of an MT device, it would be easy because I assign the Wireguard in the interface settings this single supplied IP address.
That is the only source address the client, the iphone will send over the tunnel and the only source IP the 3rd Party VPN will see........
However, when I set the MT router as a client, I will be sending MANY private IPs over the tunnel, the entire subnet will have access !!!!!!!!!!!!!!
BUT, the wireguard THIRD PARTY SERVER is only expecting one, and thus at their end all the traffic will get dropped!!.
OR not sure how they do it, lets say they changed all the incoming IPs to the single IP, not a source nat but a modification.
Then all the returning traffic will have a single source IP, none of which match any of the private users on teh originating subnet.
In either case the solution is to sourcenat all the private IPs to the assigned IP from the third party provider.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From a router to router perspective,,,,, You tell the server MT router, via allowed IPs, hey you can expect this entire subnet to be coming out of the tunnel at your end (by its peer settings for allowed IPs) and thus all this traffic is permitted whereas, if it showed up on a third party vpn expecting only one source IP, it would be dropped