Hi!
First I will describe my config, and then the problems that I encountered when upgraded from version 386.2_2 to 386.4
The router is used as a gateway to my work network. The connection is made using OpenVPN, here is a part of the client config:
When connected, the server pushes routes to private and public subnets. The default route remains my ISP. Among the public routes that the server pushes, there are 11.22.33.0/24 (that is, the subnet that owns the public address of the openvpn server itself). Since (in the 2_2 firmware) the
Also, the server pushes the DNS addresses that should be used for resolving when using a work network.
On the old firmware, where the network settings were controlled by the
When trying to use the same settings with the new firmware, I ran into two problems:
1. The public route that includes the address 11.22.33.44 goes through the tunnel interface. A separate route for /32 is not created. The logs show that the
But when these routes are processed by the
The kernel discards this route because it is on the wrong interface.
After that, the connection with the server is lost and openvpn-client goes into a loop of attempts to connect to the server. The route to which is wrapped in a tunnel.
In src/router/libovpn/openvpn_control.c (current branch, commit 598756e) there is code on line 391 for (
It seems to me that there will be nothing wrong if, for each ovpn-client table in the routes, the route to the server through localgw is unconditionally defined, even in the case of RGW: No. Offhand, this may interfere with VPN chaining, but I'm not sure that in the current implementation it is even possible.
2. Exclusive DNS configuration with RGW:No is not respected, the
At the moment (as a temporary solution) I have written a dirty
This solves my first and second problems: the default route is my ISP, and the DNS servers for global resolution are pulled from the work server. But in general config remains inconsistent and, as mentioned, dirty.
I would like to know if improvements are planned on both points? The
Nevertheless, I would be grateful if I hear explanations for my questions. Thanks!
First I will describe my config, and then the problems that I encountered when upgraded from version 386.2_2 to 386.4
The router is used as a gateway to my work network. The connection is made using OpenVPN, here is a part of the client config:
Code:
client
proto udp
dev tun
remote ovpn.example.net # for example, the address resolves to 11.22.33.44
nobind
persist-key
persist-tun
comp-lzo
setenv opt block-outside-dnsWhen connected, the server pushes routes to private and public subnets. The default route remains my ISP. Among the public routes that the server pushes, there are 11.22.33.0/24 (that is, the subnet that owns the public address of the openvpn server itself). Since (in the 2_2 firmware) the
openvpn client creates a direct route to /32 to my ISP for this situation, there are no routing problems, since smaller masks take precedence.Also, the server pushes the DNS addresses that should be used for resolving when using a work network.
On the old firmware, where the network settings were controlled by the
openvpn client, I used the following settings:
Code:
Redirect Internet traffic through tunnel: No
Accept DNS Configuration: Exclusive (see the option in the config provided)When trying to use the same settings with the new firmware, I ran into two problems:
1. The public route that includes the address 11.22.33.44 goes through the tunnel interface. A separate route for /32 is not created. The logs show that the
openvpn client is pushing:
Code:
PUSH: Received control message: 'PUSH_REPLY,route-gateway 10.250.0.1,topology subnet,ping 5,ping-restart 30,dhcp-option DOMAIN ~.,dhcp-option DNS 172.16.4.7,dhcp-option DNS 172.16.4.30,route 11.22.33.44 255.255.255.255 net_gateway, etc...openvpn-routing handler, the route is assigned to dev tun:
Code:
Add pushed route: /usr/sbin/ip route add 11.22.33.44/255.255.255.255 via 192.168.10.1 dev tun11 table ovpnc1After that, the connection with the server is lost and openvpn-client goes into a loop of attempts to connect to the server. The route to which is wrapped in a tunnel.
In src/router/libovpn/openvpn_control.c (current branch, commit 598756e) there is code on line 391 for (
Force traffic to remote VPN server to go through local GW), but it only works if (rgw != OVPN_RGW_NONE). It seems to me that there will be nothing wrong if, for each ovpn-client table in the routes, the route to the server through localgw is unconditionally defined, even in the case of RGW: No. Offhand, this may interfere with VPN chaining, but I'm not sure that in the current implementation it is even possible.
2. Exclusive DNS configuration with RGW:No is not respected, the
/tmp/resolv.dnsmasq config contains the address of the local (ISP) DNS server (with and without local domain) in addition to the addresses that the openvpn server pushes. In this case, I did not parse the source code and cannot suggest where it would be worth correcting. I assume that exclusive DNS only works with VPN Director, and in RGW:No mode, Relaxed/Strict always used.At the moment (as a temporary solution) I have written a dirty
openvpn-event script that I use along with the RGW:All mode:
Bash:
#!/bin/sh
###
# Removing all default routes from all RGW ovpn clients (cuz non-RGW works incorrect).
###
_log()
{
/usr/bin/logger -t openvpn-event -p 6 $@
}
case "$script_type" in
"route-up")
table="$(/usr/sbin/ip route list table all | /bin/grep default | /bin/grep "$dev" | /usr/bin/awk '{print $NF}')"
_log "Removing RGW default route from iface $dev table $table."
/usr/sbin/ip route delete default table $table
;;
"route-pre-down")
# _log "Reverting removed RGW default route."
### Nothing to do here: handler removes whole routing table.
;;
"*")
_log "Unknown event!"
esacThis solves my first and second problems: the default route is my ISP, and the DNS servers for global resolution are pulled from the work server. But in general config remains inconsistent and, as mentioned, dirty.
I would like to know if improvements are planned on both points? The
libovpn code regarding routing has not changed for half a year, and at the moment it is WIP with IPv6, if I understand correctly. As for the DNS configuration, the answer to the question is even more obscure, because (I think) there may be conflicts with the current VPN Director implementation (or non-obvious priority rules will have to be applied).Nevertheless, I would be grateful if I hear explanations for my questions. Thanks!
