Hi,
On 03/05/21 12:12, Gert Doering wrote:
On Mon, May 03, 2021 at 12:01:04PM +0200, Jan Just Keijser wrote:
I would expect this to do the same thing it would do for the "non proxy"
case - install a host route to the existing default gateway so packets
to the server (and with proxy, to the proxy) can still flow. Then,
change the default route into the tunnel.
Of course there might be bugs - so you'll end up having to test this.
AFAIK this does *not* work for the "non proxy" case;
What exactly is "this" here?
by "this" I meant "connecting to an OpenVPN server via a proxy with
'redirect-gateway' set"
Bypass routes for IPv4 (if you have "redirect-gateway" or "redirect-private"
in your config) and IPv6 (automatic) have been worked for a long time...
I just wasn't sure it would take the correct "remote IP" for socks/http
proxy setups.
actually, it does, so I stand corrected, with a small "but" ( see below )
just checked the
v2.5 sources and I cannot find anything special there:
init.c:do_init_route_list() calls route.c:init_route_list()
with "remote_host" set to "link_socket_current_remote(link_socket_info)"
and that does not seem to take any proxy hosts into account.
But "link_socket_current_remote" is very likely to be "whoever we are
talking to right now", aka "the proxy".
you're absolutely right, and I now remember the caveat that applies
mostly when using "socks-proxy", not "http-proxy":
what I'd normally do when using "socks-proxy" is set up an SSH tunnel to
a remote host
ssh -D 1080 <remote-host>
and then tunnel the VPN traffic over that. The big caveat here is that
when doing this, the "socks-proxy" IP address is actually
localhost/127.0.0.1 : so OpenVPN might add an extra route to localhost ,
but as soon as the default GW is redirected, the route to the original
SSH server is gone.
Theoretically, the same applies when doing HTTP forwarding, e.g.
ssh -L 8888:<some-host>:80 <remote-host>
and then use "http-proxy 127.0.0.1 8888" . But it's the "ssh -D 1080"
use case that has bitten me quite a few times.
There's no easy way around this, as there is no way that OpenVPN can
determine what the actual remote address of the SOCKS listener is, but
this is too common a mistake to make to *not* document somewhere.
If one uses a remote SOCKS server then all works as it should.
Hope this clarifies it a bit,
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
