HELP NEEDED with fixing routes for an OpenVPN client using a proxy to connect to the server

Installing and Using OpenWrt Network and Wireless Configuration
1

On my OpenWRT router I do use passwall and a couple of internet censorship circumventing proxies.

In order to maximise the security of my home internet I am using a *reputable commercial *
VPN product.
That said since the government censorship is very sophisticated it can block plain OpenVPN traffic using DPI methods.

Therefore, I have no choice than using http-proxy with my OpenVPN client in order to Obfuscate the OpenVPN client tcp traffic.

In addition I need to redirect the free/uncensored internet from the OpenVPN commercial provider to my connected home devices.

That said I am unable to achieve my goal because of once the OpenVPN client connects to the server the server side pushes the routes and gateway configuration back to the router and since both of the ProxyServer process and the OpenVPN client process are running on a same OpenWRT device the new pushed routes mess up with the ProxyServer process and as a result later it will mess up with the OpenVPN client as well.

So the OpenVPN client gets disconnected and tries to reconnect again and it fails since the pushed routes destroy the proxy server running on the router.

For more information very similar to my situation you could consult following link,
[https://forum.archive.openwrt.org/viewtopic.php?id=50875](link to an almost similar issue)

That said I would like to modify the pushed routes to not to destroy the proxy server,
please note that on the OpenVPN server side I do not have any control, since it is provided by a commercial company.

In fact would like to acheive following,

The proxy server running on my openWRT router should not get disturbed by route changes forcibly applied and pushed once the OpenVPN client gets connected!

Therefore I am wondering if I can ISOLATE the CPU/OS environment/or 127.0.0.1 on the OpenWRT in order to not get affected by the redirected OpenVPN internet!?

In addition I have tried route-nopull command in the client_config.ovpn file, in fact it did not disturbed the OpenWRT core default internet source, but I do not have any clue on how to manually add routes and redirect the created tun0 OpenVPN client traffic to only my home devices connected to the br-lan without messing with other processes running on the OpenWRT.

What would be the route commands/ip tables command required to get executed after tun0 interface is up?

The netstat of the router before connecting to the OpenVPN device is as follows,

#netstat -rn
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.8.1     0.0.0.0         UG        0 0          0 phy1-sta0
192.168.8.0     0.0.0.0         255.255.255.0   U         0 0          0 phy1-sta0
192.168.55.0    0.0.0.0         255.255.255.0   U         0 0          0 br-lan

Note: The router wan interface is phy1-sta0 with GW 192.168.8.1
and the connected devices are behind NAT on br-lan while they are using their ip addressed from the dhcp pool in range 192.168.55.64/26 except the router which has ip address 192.168.55.1

#ip route show
default via 192.168.8.1 dev phy1-sta0 proto static src 192.168.8.118
192.168.8.0/24 dev phy1-sta0 proto kernel scope link src 192.168.8.118
192.168.55.0/24 dev br-lan proto kernel scope link src 192.168.55.1

and after connecting the OpenVPN client by using route-nopull command in the config tun0 is added as follows,

#netstat -rn 
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.8.1     0.0.0.0         UG        0 0          0 phy1-sta0
10.124.148.0    0.0.0.0         255.255.254.0   U         0 0          0 tun0
192.168.8.0     0.0.0.0         255.255.255.0   U         0 0          0 phy1-sta0
192.168.55.0    0.0.0.0         255.255.255.0   U         0 0          0 br-lan

#ip route show
default via 192.168.8.1 dev phy1-sta0 proto static src 192.168.8.118
10.124.148.0/23 dev tun0 proto kernel scope link src 10.124.148.118
192.168.8.0/24 dev phy1-sta0 proto kernel scope link src 192.168.8.118
192.168.55.0/24 dev br-lan proto kernel scope link src 192.168.55.1

I am wondering how should a correct route table look like?

What modification/configurations I shoudl apply and run after tun0 is up?

And as a side question the processes running on the OpenWRT what would be the default interface that they use to connect to the internet? is it eth0, lan0, ....!?
For example the command traceroute ran on the OpenWRT cli utilises which device or interface by default!?

This issue has made me really frustrated :unamused:, I need a clean and unrestricted internet urgently for my connected devices.

Any advice or solution is really appreciated.

2

There are two basic ways to do this.

  1. Install a /32 route to the proxy server via the regular wan. Then when OpenVPN sets itself as the default route, packets going to the proxy server's single IP will still go by regular Internet and the VPN connection will continue to work. This is most workable if the proxy server always has the same IP address.

  2. Configure OpenVPN to not install the pulled default route, then use policy based routing to route only packets that originate from the users on the LAN into the VPN tunnel. Packets that originate in the router (such as encrypted / proxied packets) will use the old default route.

3

In additions to what @mk24 said use in the openvpn config:
pull-filter ignore redirect-gateway

This stops the OpenVPN from setting up the default route.
Use Policy Based routing to route your clients or destination via the VPN, see:

You can use scramble options for OpenVPN to circumvent DPI, there are several commercial providers supporting that:

4

@mk24 Would you mind elaborate the

Install a /32 route to the proxy server via the regular wan.

part for me.
I have mentioned that the proxy server is not a device connected to my openwrt router,
in fact the proxy server (luci-app-passwall) that I am using is a process running on the openwrt router, I have no clue at all what interface that proxy server is using (br-lan,eth0,...) and I have no clue what it is ip address it has (127.0.0.1 or 192.168.51.1, ...), I just get my openvpn client connected to it by adding http-proxy 127.0.0.1 1080 line and it gets connected and makes the tun0 tunnel.

All the troubles begin with the OpenVPN pushes the ip-routes and messes everything.

I am wondering which one of the following lines should be added to my OpenVPN client config file,
I already added route-nopull at the end.

route 127.0.0.1 255.255.255.255 net_gateway
or
route 192.168.55.1 255.255.255.255 net_gateway

Since I have tried and added all the combinations of the above lines into the config file
and it didn't work.

Please note that 192.168.55.1 is the router ip and the net_gateway is the 192.168.8.1 is the LTE modem router ip.

What I need is to treat and assume that the tun0 is a separate WAN interface, which is connected to my multiwan router, I would like to know how I could make the tun0 internet available for the connected br-lan devices of the user dhcp pool 192.168.55.64/26 or 255.255.255.192 which is (192.168.55.65-192.168.55.126) range and NOT the router (192.168.55.1) that is all I need to figure out and I could not figure those route commend yet!

5

@egc
I presume in my case the route-nopull directive would work the same as

pull-filter ignore redirect-gateway
The policy based routing looks complicated and overkill for me, it occpies more of the needed flash of my router.
I am wondering if you know the route commands that I could execute after tun0 is up in order to make the tun0 internet available for only the connected br-lan0 devices and not the router.
Thanks

6

route-nopull is outdated and is more of a nuclear option to stop any routes set so pull-filter ignore redirect-gateway is the smarter/modern option.

You can use a simple pbr with something like this, you can lock yourself out be sure to make a backup before trying:

ip route add default dev tun0 table 101
# add local routes
ip route show | grep -Ev '^default |^0.0.0.0/1 |^128.0.0.0/1 ' | while read route; do
    ip route add $route table 101 >/dev/null 2>&1
done
ip rule add from 192.168.1.0/24 table 101

note replace 192.168.1.0/24 with your own subnet

You can make a route-up script from this (first line a shebang #!/bin/sh, and make executable) and place in /etc/openvpn and call this in the openvpn config with
route-up /etc/openvpn/myscript

Edit when not using main builds use:
up /etc/openvpn/myscript there is a bug openvpn which has been solved in main builds but it has not been backported yet

7

@egc
I tried your solution as follows following lines are added to the up_script.sh,


ip route add default dev tun0 table 101
# add local routes
ip route show | grep -Ev '^default |^0.0.0.0/1 |^128.0.0.0/1 ' | while read route; do
    ip route add $route table 101 >/dev/null 2>&1
done
ip rule add from 192.168.55.64/26 table 101

and added as following into the config.ovpn file
route-up /etc/openvpn/HomeBrew/up_script.sh
or
up /etc/openvpn/HomeBrew/up_script.sh
to either of route-up and up commands inside the config.ovpn file.

In order to confirm the scripts are working I did add logging too (system log) as follows
user.alert OVPN_UP: tun0 is up - running custom commands

But after that nothing has changed, please note that I have taken out route-nopull and added pull-filter ignore redirect-gateway instead inside the config.ovpn file.

As I understood from your code it seems that the script will take out default,0.0.0.0/1 128.0.0.0/1 routes from the kernel table and copy the rest of them in table 101.
That said at the very end I added to the script my devices range subnet except the router
as follows to the table 101.

ip rule add from 192.168.55.64/26 table 101

What I am unable to do is how to execute table 101 routes and let that table to take out the kernel ip routing table.
Kindly tell me how to do that.
Would you mind assist me with that, since my kernel table has not changed.
Or the new 101 route table is not applied.
I guess I have fixed my iptables for masquerading and natting with the tun0.

In addition I am wondering whether the route orders inside a route table play a role or not.
I am very very sorry that I could not google those on my own since at the moment and for a while the internet speed has degraded dramatically many VPNs,... have stopped working or do work with a lot of interruptions, the internet is extremely slow and I am dealing with thousands of internet issues, while I am writing to you.

Your assistance would really help me with the burden that I am dealing with the internet that I have now.

Thanks

8

Did you add a shebang to the script and made it executable?

You can easily see if the script itself works, from the command line:
sh -x /etc/openvpn/HomeBrew/up_script.sh

Please show a copy of the whole script and output of:

ip ro
ip ro show table 101
ip ru

To see if the rules are applied

9

@egc I have changed the route-up to up inside the config.ovpn file in order to make sure the script runs.
and I do log it,

Sat Jan 20 04:41:59 2024 daemon.notice netifd: Interface 'ovpn' is enabled
Sat Jan 20 04:41:59 2024 daemon.notice netifd: Network device 'tun0' link is up
Sat Jan 20 04:41:59 2024 daemon.notice netifd: Interface 'ovpn' has link connectivity
Sat Jan 20 04:41:59 2024 daemon.notice netifd: Interface 'ovpn' is setting up now
Sat Jan 20 04:41:59 2024 daemon.notice openvpn(homebrew_windscribe_swe[8492]: net_addr_v4_add: 10.124.148.34/23 dev tun0
Sat Jan 20 04:41:59 2024 daemon.notice openvpn(homebrew_windscribe_swe[8492]: /usr/libexec/openvpn-hotplug up homebrew_windscribe_swe tun0 1500 1626 10.124.148.34 255.255.254.0 init
Sat Jan 20 04:41:59 2024 user.alert OVPN_UP: tun0 is up - running custom commands   <--------- The log inside the up_script.sh which shows the script runs
Sat Jan 20 04:41:59 2024 daemon.notice netifd: ovpn (8558): udhcpc: started, v1.36.1
Sat Jan 20 04:41:59 2024 daemon.notice openvpn(homebrew_windscribe_swe[8492]: Initialization Sequence Completed

after executing the contents of the up_script.sh following commands are executed after on, inside the OpenWRT CLI with the following results.

[root@router:04:40 AM ~] # ip ro
default via 192.168.8.1 dev phy1-sta0 proto static src 192.168.8.118
10.124.148.0/23 dev tun0 proto kernel scope link src 10.124.148.34
192.168.8.0/24 dev phy1-sta0 proto kernel scope link src 192.168.8.118
192.168.55.0/24 dev br-lan proto kernel scope link src 192.168.55.1

[root@router:04:53 AM ~] # ip ro show table 101
default dev tun0 scope link
10.124.148.0/23 dev tun0 proto kernel scope link src 10.124.148.34
192.168.8.0/24 dev phy1-sta0 proto kernel scope link src 192.168.8.118
192.168.55.0/24 dev br-lan proto kernel scope link src 192.168.55.1

[root@router:04:54 AM ~] # ip ru
0:      from all lookup local
32765:  from 192.168.55.64/26 lookup 101
32766:  from all lookup main
32767:  from all lookup default

It seems that the lan users do get access to the VPN internet BUT the DNS of the VPN does not solve, and once I enter or browse a site it takes minutes to resolve a URL.
Maybe the router uses fallback dns to resolve instead which is not good and will cause DNS leak issue,

pretty sure the settings of the DNS server for tun0 must be fetched from the VPN provider server side some way or other.
Is there any directive to fetch that information from the server?

Is the tun0 dns information omitted with the pull-filter ignore redirect-gateway directive?
Thanks

10

The router itself uses the wan so does dns.
If you have specified a vpn dns server which is not public you might run into problems.
Just use the regular dns servers.

Openwrt does not do anything with the dns servers pushed by the vpn provider out of the box.

So you can have a dns leak if you mean that the pushed dns server is not used.

There are ways to deal with this but as far as I am concerned that will have to wait till tomorrow, of course someone else might chime in

11

No that is not related as said openwrt does not use the dns servers pushed by the provider out of the box, you need another script to deal with this

12

You can test the DNS with a client using a browser and go to: ipleak.net that will show if you are using the VPN, what DNS server you are using and where that DNS server is located.

If you still have trouble it helps if we see the hole picture so please connect to your OpenWRT device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/dhcp
cat /etc/config/firewall
ip ro
ip route show table all
ip ru
logread | grep openvpn

13

@egc
I am wondering if there would be any kind of down script available too, since
tun0 remains in the route table regardless if the VPN fails or get manually disconnected.

How can I prepare the down.sh script?Thanks

14

Yes I will make that for you will be later to day :slight_smile:

15

Have a look:

I have not tested it so their might be typos in it, let me know if you miss anything.

Have fun

16

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

If it is not solved let me know what additional problems need to be solved :slight_smile:

17

@egc Sorry for late reply.
I am wondering running the ovpn-up-update-resolv-6 script has caused some memory persistence changes in my router and I am wondering if I should reset my router.
Currently I am using my test router which is using USB and extended overlay partition and I am not sure the /tmp folder is stored on memory or permanently on the USB, I should check that later.

Anyways after running the script ovpn-up-update-resolv-6, the http-proxy server on the test router has failed, I mean after rebooting the router I get following error a

 Jan 23 05:41:43 2024 daemon.notice openvpn(homebrew_windscribe_swe[27877]: Send to HTTP proxy: 'CONNECT 146.70.16.243:443 HTTP/1.0'
Tue Jan 23 05:41:43 2024 daemon.notice openvpn(homebrew_windscribe_swe[27877]: Send to HTTP proxy: 'Host: 146.70.16.243'
Tue Jan 23 05:41:43 2024 daemon.notice openvpn(homebrew_windscribe_swe[27877]: HTTP proxy returned: 'HTTP/1.0 200 Connection established'
Tue Jan 23 05:41:43 2024 daemon.notice openvpn(homebrew_windscribe_swe[27877]: TCP_CLIENT link local: (not bound)
Tue Jan 23 05:41:43 2024 daemon.notice openvpn(homebrew_windscribe_swe[27877]: TCP_CLIENT link remote: [AF_INET]192.168.55.1:1080
Tue Jan 23 05:41:43 2024 daemon.err openvpn(homebrew_windscribe_swe[27877]: Connection reset, restarting [0]
Tue Jan 23 05:41:43 2024 daemon.notice openvpn(homebrew_windscribe_swe[27877]: TCP/UDP: Closing socket
Tue Jan 23 05:41:43 2024 daemon.notice openvpn(homebrew_windscribe_swe[27877]: SIGUSR1[soft,connection-reset] received, process restarting
Tue Jan 23 05:41:43 2024 daemon.notice openvpn(homebrew_windscribe_swe[27877]: Restart pause, 5 second(s)

And the DNS is not resolving, I rebooted the router a couple of times and the issue is persistent.
running speedtest on the router cli could not find ip address, I do not know if the ovpn-up-update-resolv-6 commands did made permanent changes or the origin of the issue is somewhere else!

That said I have added following lines to the tcp config file,

client
proto tcp
remote se2-auto-tcp.remote_address.com 80
verb 1
#connect-retry-max 3
#connect-retry 

dev tun0
auth-user-pass cred.txt
persist-key
persist-tun
nobind
ca ca
certcert
key key
tls-auth tls
key-direction 1
remote-cert-tls server
cipher AES-256-CBC
script-security 2

# Following lines are added
# passwall proxy added conf
http-proxy 192.168.55.1 1080 auto
pull-filter ignore "redirect-gateway"
pull-filter ignore "dhcp-option DNS"

up /etc/openvpn/HomeBrew/up_script.sh
down /etc/openvpn/HomeBrew/down_script.sh
resolv-retry infinite

The problem that should be solved are divided into three parts,

First, since only one up or route-up script can be used in the config file I should merge the
ovpn-up-update-resolv-6 with both the ovpn-pbr-down and ovpn-pbr-up properly.

Please correct me If I am wrong.
Since the resolve script does have cases should I only call that script and in the up section of its script in the begining insert add the ovpn-pbd-up or shall I put them later on the bottom of the script.

*Kindly show me how this merge for both *up/down* scripts should be applied.*``After DNS or before as route-up or up script?

Second, if for any reason the OpenVPN process dies, I mean if the down-script fails to execute, I should be assured that none of the configurations applied by the OpenVPN client up script should be memory persistent in addition calling the down script manually or automatically should bring back all the settings to exactly the state of the router before OpenVPN client execution,
I mean no residue of the previous execution of openvpn client should remain after router reboot or manually calling down script.Would you mind confirm that with all the provided scripts?

In addition is there any configuration changes made by any script that stays in the router after reboot?

Third, I am wondering if I should use the proxy in the config file as http-proxy 127.0.0.1 1080 auto or http-proxy 192.168.55.1 1080 auto (55.1 is the router lan ip)?, does any of http-proxy or socks-proxy in the openvpn supports udp tunnel?

Your assistance is really appreciated.

18

First of all the script gets its DNS server from the VPN, with the added line above you actually disable this, so if you want to use the DNS servers from the VPN remove that line or add DNS servers as described in the script:

Summary

To set your own DNS servers to use when the tunnel is up, add in the openvpn conf file: dhcp-option DNS ip-address-DNS-server.

The script changes the used resolv file, if something goes wrong the script should correct any remaining remnants the next time it runs but it assumes you use default settings. If the script does not run then you can have left over settings.

Please do the following, first disable the VPN, next to see if this is the problem, do from the command line and report the output of:
uci get dhcp.@dnsmasq[0].resolvfile

If there is anything else then /tmp/resolv.conf.d/resolv.conf.auto then delete this entry with:
uci del dhcp.@dnsmasq[0].resolvfile

Reboot afterwards

If the problem is DNS related this should get you back in business.

I have slightly tweaked the file to be more resilient, new version is up and available, try the new v7.

If you use the ovpn-update-resolv-7 then all your DNS queries are going through the VPN tunnel in this case this might not be what you want if you want the DNs query to follow the client (e.g. clients using the WAN will get DNS via the WAN) then using option 6 with a publicly available DNS server is the way to go

But if you do want to run the scripts together I would make a third script which runs both scripts.
e.g make a script and name it up-all place in /etc/openvpn/HomeBrew together with the other scripts and make executable.

#!/bin/sh
# openvpn up script
/etc/openvpn/HomeBrew/up_script
/etc/openvpn/HomeBrew/ovpn-update-resolv-7

The same way you make a down script and call it down-all:

#!/bin/sh
# openvpn down script
/etc/openvpn/HomeBrew/down_script
/etc/openvpn/HomeBrew/ovpn-update-resolv-7

In the openvpn config add:

up /etc/openvpn/HomeBrew/up-all
down /etc/openvpn/HomeBrew/down-all

The ovpn-update-resolv-7 script reads the script type (up or down) and indeed acts accordingly

I have no experience with HTTP proxy so cannot help with that

19

This seems to be getting incredibly complicated. I would like to mention again my option 1 where you simply make a "hole punch" route in the regular routing table so the encrypted packets to the proxy server (with an IP that is known by number) go by regular wan. Also since all the IPs related to establishing the tunnel are known by number, it isn't necessary to have operable DNS at all before the tunnel comes up. You could statically configure DNS that only works through the tunnel.

the first one, since the proxy daemon is running on the same machine, that is exactly what 127.0.0. loopback IPs are intended for.

As a test, do not allow OpenVPN to pull and establish its default route, and confirm that the proxied VPN connection fully comes up and you can ping the 10.x IP that is the OpenVPN server at other end of the tunnel. If that does not work, all this other talk about selective routing is moot.

1 Like
20

@mk24
I not that acquainted with routing and iptables, kindly show me how that

hole punch

with the route could be implemented with the modification of the client_config.ovpn file.
Thanks