The only way to prevent this behavior is to use the local or autolocal argument w/ redirect-private so OpenVPN does take that possibility into consideration, and why my suggestion to the OP worked. It just blindly binds the server/remote IP to the WAN (and for all I know, maybe that was it's intent all along). Apparently OpenVPN doesn't bother to consider whether the server/remote IP is already bound to another *local* network interface. That was until today and this issue of a socks proxy. And if we use redirect-private to regain access to the VPN gateway IP and it results in the server/remote IP being explicitly bound to the WAN (if unnecessarily), it was assumed no harm, no foul. But in the case of PBR where we do NOT want the gateway redirected and we use the pull-filter to ensure that doesn't happen, OpenVPN doesn't need to worry about the server/remote IP being routed into the tunnel, so it does nothing. In the case of using 'redirect-gateway def1', the behavior is a necessity to prevent the server/remote IP from being routed back into the tunnel. But in terms of behavior, it's doing what OpenVPN normally does when the 'redirect-gateway def1' option is specified it's binding the server/remote IP to the WAN. Frankly, even to this day I don't fully understand its purpose the OpenVPN documentation is essentially non-existent. And at the time, I believed it was essentially benign. One way to get it back is to use the redirect-private directive. But a side effect of the pull-filter (that we knew at the time) is that OpenVPN then refuses to provide us w/ a VPN gateway IP, which we still need to construct the routing policy table(s). I don't know why openvpn puts proxy's ip into main routing table as proxy is almost always meant to run locally.Ĭlearly the use of the pull-filter was the right decision, and the OpenVPN documentation now recommends it over other methods. Maybe it's worth to introduce new option in GUI, so this case is accounted. Any ideas? Similar problem is described here but more thoroughly. I managed to fix the problem by manually removing routing entries marked by red arrows, as a temporary solution. Quick investigation revealed a problem, proxy gets put in routing table thus making it unreachable. So the issue is as soon as VPN connection is established 172.16.1.3 (proxy) is not reachable any more from within a router and vpn is not working of course. Vpn client is configured to redirect traffic according to routing policy "From Source 192.168.1.0/24" which is secondary lan br1. Router's ip is 172.16.1.1 and 172.16.1.3 is different device connected over ethernet port to the router. My socks5 proxy was setup and ready on main lan br0, so I've added following line to custom config of vpn client:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |