OpenVPN Client Router -> AirVpn - Specify Interface To Use As Gateway

[mad1337man 0]

I have a two-port "router" (really a little computer running Ubuntu 19.10) set up as OpenVPN Client.

The router has two ethernet ports:

eth0: 192.168.1.3
eth1: 192.168.1.2

Both of these ports are currently connected another router:

192.168.1.1 -> Internet

This is my .ovpn configuation:

client
dev tun
remote 213.152.161.180 443
resolv-retry infinite
persist-key
persist-tun
auth-nocache
route-delay 5
verb 3
explicit-exit-notify 5
push-peer-info
setenv UV_IPV6 yes
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
proto udp
key-direction 1

OpenVPN is started in /etc/rc.local:

openvpn --config /etc/openvpn/client/client.ovpn &> /var/log/openvpn.log &
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

All of this works fine.  When the tunnel comes up, I get this routing table:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.5.128.1      128.0.0.0       UG    0      0        0 tun0
default         _gateway        0.0.0.0         UG    0      0        0 eth0
10.5.128.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
128.0.0.0       10.5.128.1      128.0.0.0       UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
180.161.152.213 _gateway        255.255.255.255 UGH   0      0        0 eth1

Note that the route 180.161.152.213 _gateway is using eth1.  I want that route to use eth0.

Note that both routes will work with the current configuration, but that will soon change.

How can I ensure that OpenVPN dynamically-created route will use interface eth0?
 

[OpenSourcerer 1442]

Spontaneously two things come to mind.

1. Additional route directive in OpenVPN with a lower metric, for example route 180.161.152.213 255.255.255.255 net_gateway [lower metric].
2. local directive, for example local 192.168.1.3. Though this might mean traffic on all other ports is not routed. Should be tried out.

Actually, you can control that by simply setting the metric of eth0 routes to lower values. Maybe this anomaly with all routes are the most important is causing that. Does ip r show the same?

And also, from a router's perspective, what's the point of having two interfaces in the same subnet? Load balancing? Do you regularly use the full throughput of gigabit ethernet?

[mad1337man 0]

14 minutes ago, giganerd said:

Spontaneously two things come to mind.

1. Additional route directive in OpenVPN with a lower metric, for example route 180.161.152.213 255.255.255.255 net_gateway [lower metric].
2. local directive, for example local 192.168.1.3. Though this might mean traffic on all other ports is not routed. Should be tried out.

Actually, you can control that by simply setting the metric of eth0 routes to lower values. Maybe this anomaly with all routes are the most important is causing that. Does ip r show the same?

And also, from a router's perspective, what's the point of having two interfaces in the same subnet? Load balancing? Do you regularly use the full throughput of gigabit ethernet?

Giganerd thanks for answering this! The current configuration is just a hack, because I'm missing a piece of hardware. In the final configuration, both ports will be on different subnets. Let me try the other things you mentioned, and I'll post back here.

[mad1337man 0]

OK so I modified the netplan as follows:
 

# Let NetworkManager manage all devices on this system
#network:
#  version: 2
#  renderer: NetworkManager
network:
    version: 2
    ethernets:
        eth0:
            addresses:
             - 192.168.1.3/24
            gateway4: 192.168.1.1
            nameservers:
                addresses:
                - 1.1.1.1
            dhcp4: false
            dhcp6: false
            routes:
            - to: 0.0.0.0/0
              via: 192.168.1.3
              metric: 100
        eth1:
            addresses:
            - 192.168.1.2/24
            dhcp4: false
            dhcp6: false
            routes:
            - to: 0.0.0.0/0
              via: 192.168.1.2
              metric: 200
            nameservers:
                addresses:
                - 1.1.1.1
                - 1.0.0.1
                search: []

So eth0 is 100 (lower) and eth1 is 200 (higher).  I also modified client.ovpn as follows:

client
dev tun
remote 213.152.161.180 443
route 213.152.161.180 255.255.255.255 net_gateway 0
resolv-retry infinite
persist-key
persist-tun
auth-nocache
route-delay 5
verb 3
explicit-exit-notify 5
push-peer-info
setenv UV_IPV6 yes
remote-cert-tls server
cipher AES-256-CBC
comp-lzo no
proto udp
key-direction 1
<ca>

Resulting route table:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.5.128.1      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
0.0.0.0         192.168.1.3     0.0.0.0         UG    100    0        0 eth0
0.0.0.0         192.168.1.2     0.0.0.0         UG    200    0        0 eth1
10.5.128.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
128.0.0.0       10.5.128.1      128.0.0.0       UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
213.152.161.180 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1

So you can see that I've affected the metrics but the dynamically-added route is still pointing to eth1.  This effect occurs if the IP address is the same, if it is different, I get two routes, and the one I add manually gets the metric that I specify. It seems like the OpenVPN route "clobbers" the static route that I create, but not sure.  I'm going to try local.

 

[mad1337man 0]

Here's the log with local:

Sun Nov 17 14:30:12 2019 OpenVPN 2.4.8 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [                                                              PKCS11] [MH/PKTINFO] [AEAD] built on Oct 30 2019
Sun Nov 17 14:30:12 2019 library versions: OpenSSL 1.1.1c  28 May 2019, LZO 2.10
Sun Nov 17 14:30:12 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SH                                                              A1' for HMAC authentication
Sun Nov 17 14:30:12 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SH                                                              A1' for HMAC authentication
Sun Nov 17 14:30:12 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]213.152.161.                                                              180:443
Sun Nov 17 14:30:12 2019 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sun Nov 17 14:30:12 2019 UDP link local (bound): [AF_INET]192.168.1.3:1194
Sun Nov 17 14:30:12 2019 UDP link remote: [AF_INET]213.152.161.180:443
Sun Nov 17 14:30:16 2019 TLS: Initial packet from [AF_INET]213.152.161.180:443, sid=9e7860e8 270                                                              66d08
Sun Nov 17 14:30:17 2019 VERIFY OK: depth=1, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=airvpn.org                                                               CA, emailAddress=info@airvpn.org
Sun Nov 17 14:30:17 2019 VERIFY KU OK
Sun Nov 17 14:30:17 2019 Validating certificate extended key usage
Sun Nov 17 14:30:17 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS                                                               Web Server Authentication
Sun Nov 17 14:30:17 2019 VERIFY EKU OK
Sun Nov 17 14:30:17 2019 VERIFY OK: depth=0, C=IT, ST=IT, L=Perugia, O=airvpn.org, CN=server, em                                                              ailAddress=info@airvpn.org
Sun Nov 17 14:30:17 2019 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 409                                                              6 bit RSA
Sun Nov 17 14:30:17 2019 [server] Peer Connection Initiated with [AF_INET]213.152.161.180:443
Sun Nov 17 14:30:19 2019 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sun Nov 17 14:30:19 2019 PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gatewa                                                              y ipv6 def1 bypass-dhcp,dhcp-option DNS 10.5.128.1,dhcp-option DNS6 fde6:7a:7d20:180::1,tun-ipv6                                                              ,route-gateway 10.5.128.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:180                                                              ::10cb/64 fde6:7a:7d20:180::1,ifconfig 10.5.128.205 255.255.255.0,peer-id 4,cipher AES-256-GCM'
Sun Nov 17 14:30:19 2019 OPTIONS IMPORT: timers and/or timeouts modified
Sun Nov 17 14:30:19 2019 OPTIONS IMPORT: compression parms modified
Sun Nov 17 14:30:19 2019 OPTIONS IMPORT: --ifconfig/up options modified
Sun Nov 17 14:30:19 2019 OPTIONS IMPORT: route options modified
Sun Nov 17 14:30:19 2019 OPTIONS IMPORT: route-related options modified
Sun Nov 17 14:30:19 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sun Nov 17 14:30:19 2019 OPTIONS IMPORT: peer-id set
Sun Nov 17 14:30:19 2019 OPTIONS IMPORT: adjusting link_mtu to 1625
Sun Nov 17 14:30:19 2019 OPTIONS IMPORT: data channel crypto options modified
Sun Nov 17 14:30:19 2019 Data Channel: using negotiated cipher 'AES-256-GCM'
Sun Nov 17 14:30:19 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit ke                                                              y
Sun Nov 17 14:30:19 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit ke                                                              y
Sun Nov 17 14:30:19 2019 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=40:62:31:03:3                                                              3:1e
Sun Nov 17 14:30:19 2019 GDG6: remote_host_ipv6=n/a
Sun Nov 17 14:30:19 2019 ROUTE6_GATEWAY fe80::9a1e:19ff:fe31:ce2a IFACE=eth0
Sun Nov 17 14:30:19 2019 TUN/TAP device tun0 opened
Sun Nov 17 14:30:19 2019 TUN/TAP TX queue length set to 100
Sun Nov 17 14:30:19 2019 /sbin/ip link set dev tun0 up mtu 1500
Sun Nov 17 14:30:19 2019 /sbin/ip addr add dev tun0 10.5.128.205/24 broadcast 10.5.128.255
Sun Nov 17 14:30:19 2019 /sbin/ip -6 addr add fde6:7a:7d20:180::10cb/64 dev tun0
Sun Nov 17 14:30:24 2019 /sbin/ip route add 213.152.161.180/32 via 192.168.1.1
Sun Nov 17 14:30:24 2019 /sbin/ip route add 0.0.0.0/1 via 10.5.128.1
Sun Nov 17 14:30:24 2019 /sbin/ip route add 128.0.0.0/1 via 10.5.128.1
Sun Nov 17 14:30:24 2019 add_route_ipv6(::/3 -> fde6:7a:7d20:180::1 metric -1) dev tun0
Sun Nov 17 14:30:24 2019 /sbin/ip -6 route add ::/3 dev tun0
Sun Nov 17 14:30:24 2019 add_route_ipv6(2000::/4 -> fde6:7a:7d20:180::1 metric -1) dev tun0
Sun Nov 17 14:30:24 2019 /sbin/ip -6 route add 2000::/4 dev tun0
Sun Nov 17 14:30:24 2019 add_route_ipv6(3000::/4 -> fde6:7a:7d20:180::1 metric -1) dev tun0
Sun Nov 17 14:30:24 2019 /sbin/ip -6 route add 3000::/4 dev tun0
Sun Nov 17 14:30:24 2019 add_route_ipv6(fc00::/7 -> fde6:7a:7d20:180::1 metric -1) dev tun0
Sun Nov 17 14:30:24 2019 /sbin/ip -6 route add fc00::/7 dev tun0
Sun Nov 17 14:30:24 2019 Initialization Sequence Completed

We can see that local had an effect (bound), but here is the routing table:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.5.128.1      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
10.5.128.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
128.0.0.0       10.5.128.1      128.0.0.0       UG    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
213.152.161.180 192.168.1.1     255.255.255.255 UGH   0      0        0 eth1

You know I'm wondering maybe I should give up on taking the push routes and just specify them myself in the .ovpn config, would that make sense?




 

[mad1337man 0]

I'm thinking now that my use case is so wierd that it isn't worth any more investigation. It may be that the OpenVPN developers never anticipated that there could be more than one port on the same subnet, and felt free to aribtrarily select any port on the correct subnet, with no recourse to override that. Once the correct hardware configuration is established, this will be a non-issue. Thanks for helping me.

[OpenSourcerer 1442]

12 hours ago, mad1337man said:

It may be that the OpenVPN developers never anticipated that there could be more than one port on the same subnet, and felt free to aribtrarily select any port on the correct subnet, with no recourse to override that.

Or the selection of the interface to use is deduced from the system configuration, but as I said, it's weird that all your routes are the most important (metric 0). But yes, in OpenVPN there is no way to select a certain interface.