Openvpn routing

Installing and Using OpenWrt Network and Wireless Configuration
1

Hello everyone,
need help with openvpn routing or possibly some other sort of issue, openvpn connection runs up fine from the openvpn server and router sides(no errors in logs). Router gets its ip, adds routes (including default) to a routing table.
A firewall rule for allowing forwarding through tun0 has been created similar to wan.
However either some issue with a tunnel or a routing problem, not sure: not server nor router can ping each other via tunnel, but when I ping from server side there is incoming activity on a tunnel interface. But I couldn't get forwarding running when default route is being added for tun0.
Would appreciate any help with figuring this out, will supply any info needed, thanks.

2

just to add that server looks to be configured good as I can connect from my laptop with no issues.

3

1
11277×531 77.9 KB

4

3
31182×812 67.6 KB

5

4
41190×613 210 KB

6

5
51205×512 20.1 KB

10

The interface shows protocol DHCP client, but you have configured an OpenVPN tunnel. Change the protocol to unmanaged.
The IP of the tunnel is private. Does the VPN server have a public IP and have you forwarded the packets to the OpenWrt first?
You have a warning for the tun-mtu. Use the same value on both ends.

11

changed to unmanaged, removed link-mtu from config, now it starting kind of fine

Mon Jan 24 11:00:01 2022 daemon.warn openvpn(DigitalOcean)[3477]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: OpenVPN 2.5.3 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: library versions: OpenSSL 1.1.1m  14 Dec 2021, LZO 2.10
Mon Jan 24 11:00:01 2022 daemon.warn openvpn(DigitalOcean)[3477]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Mon Jan 24 11:00:01 2022 daemon.warn openvpn(DigitalOcean)[3477]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: TCP/UDP: Preserving recently used remote address: [AF_INET]*.*.*.*:1194
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: UDP link local: (not bound)
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: UDP link remote: [AF_INET]*.*.*.*:1194
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: [*] Peer Connection Initiated with [AF_INET]*.*.*.*:1194
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: TUN/TAP device tun0 opened
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: net_iface_mtu_set: mtu 1500 for tun0
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: net_iface_up: set tun0 up
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: net_addr_ptp_v4_add: 10.8.0.6 peer 10.8.0.5 dev tun0
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: /usr/libexec/openvpn-hotplug up DigitalOcean tun0 1500 1552 10.8.0.6 10.8.0.5 init
Mon Jan 24 11:00:01 2022 daemon.notice netifd: Interface 'OpenVPN' is enabled
Mon Jan 24 11:00:01 2022 daemon.notice netifd: Network device 'tun0' link is up
Mon Jan 24 11:00:01 2022 daemon.notice netifd: Interface 'OpenVPN' has link connectivity
Mon Jan 24 11:00:01 2022 daemon.notice netifd: Interface 'OpenVPN' is setting up now
Mon Jan 24 11:00:01 2022 daemon.notice netifd: Interface 'OpenVPN' is now up
Mon Jan 24 11:00:01 2022 daemon.notice openvpn(DigitalOcean)[3477]: Initialization Sequence Completed
Mon Jan 24 11:00:01 2022 user.notice firewall: Reloading firewall due to ifup of OpenVPN (tun0)

no forwarding through tun0 though (, both OpenWrt host and openvpn server have public ip, I'm trying to forward traffic from lan via tun0, thanks for helping out

12 
53: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 500
    link/[65534] 
    inet 10.8.0.6 peer 10.8.0.5/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::1edb:d601:b600:fc32/64 scope link flags 800 
       valid_lft forever preferred_lft forever

root@OpenWrt:~# ip route list
0.0.0.0/1 via 10.8.0.5 dev tun0 
default via *.*.*.* dev wan  src *.*.*.* 
10.8.0.0/24 via 10.8.0.5 dev tun0 
10.8.0.1 via 10.8.0.5 dev tun0 
10.8.0.5 dev tun0 scope link  src 10.8.0.6 
*.*.*.*/19 dev wan scope link  src *.*.*.* 
128.0.0.0/1 via 10.8.0.5 dev tun0 
192.168.1.0/24 dev br-lan scope link  src 192.168.1.1

stars are router public ip and network

13

Configuration on OpenWrt looks fine. Have you setup the DO server accordingly as well? It should allow forwarding and masquerade.

14

yep, I can connect via network manager from a laptop with no issues, openvpn server host is good, forwarding etc

15

the only log line that caught my eye was

Tue Jan 25 12:13:27 2022 daemon.warn openvpn(DigitalOcean)[7465]: DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
16

It is a warning and it doesn't matter so much as the tunnel is coming up.
You'll need to capture a few packets. From a lan host run a ping to 8.8.4.4
On OpenWrt opkg update; opkg install tcpdump; tcpdump -i tun0 -vn -c 10 host 8.8.4.4
On DO install tcpdump and run tcpdump -i tun0 -vn -c 10 host 8.8.4.4 to verify that you receive the packets and tcpdump -i eth0 -vn -c 10 host 8.8.4.4 to verify that you send them out correctly. I don't know the interfaces on DO, so adjust them accordingly.

17

the most valuable case was when pinging openwrt(10.8.0.6) from vpn server side(10.8.0.1) tcpdump on an openwrt tunnel showed some "port unreachable" errors

tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
12:55:40.485444 IP (tos 0x0, ttl 64, id 3428, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.1 > 10.8.0.6: ICMP echo request, id 17497, seq 8, length 64
12:55:40.485566 IP (tos 0xc0, ttl 64, id 61694, offset 0, flags [none], proto ICMP (1), length 112)
    10.8.0.6 > 10.8.0.1: ICMP 10.8.0.6 protocol 1 port 40674 unreachable, length 92
        IP (tos 0x0, ttl 64, id 3428, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.1 > 10.8.0.6: ICMP echo request, id 17497, seq 8, length 64
12:55:41.509425 IP (tos 0x0, ttl 64, id 3566, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.1 > 10.8.0.6: ICMP echo request, id 17497, seq 9, length 64
12:55:41.509536 IP (tos 0xc0, ttl 64, id 61752, offset 0, flags [none], proto ICMP (1), length 112)
    10.8.0.6 > 10.8.0.1: ICMP 10.8.0.6 protocol 1 port 57987 unreachable, length 92

while it was all good on openvpn side

tcpdump: listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
12:55:33.289451 IP (tos 0x0, ttl 64, id 2314, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.1 > 10.8.0.6: ICMP echo request, id 17497, seq 1, length 64
12:55:34.316839 IP (tos 0x0, ttl 64, id 2467, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.1 > 10.8.0.6: ICMP echo request, id 17497, seq 2, length 64

but there were cases when on both tunnel sides ping caused some activity but in fact all pings were lost.

18

when from the laptop there is some activity on both tun0/eth0 of openvpn server even without pinging, so laptop packets are being routed fine and vpn works actually, some opwnwrt missetup, can't figure out where it could be, does a routing table look correct, metrics etc? didn't do it for a long time, not 100% sure

19

Although you don't help much by doing your own troubleshooting, it seems that packets are stopped at the DO.

20

OpenWrt returning port unreachable because the OpenWrt firewall rejected the ping. If you're making your own zone for the VPN tunnel (with input set to REJECT) and want to ping from outside, it needs a specific "allow ping" rule like wan has. Or you can just put the VPN tunnel into the wan zone instead of making a new zone.

21

it was about routing but I can't get the point, at first - interface setting for openvpn for adding default route didn't work and

0.0.0.0/1 via 10.8.0.5 dev tun0 
128.0.0.0/1 via 10.8.0.5 dev tun0

were added every time, regardless od "add default route" setting, and didn't work.
I managed to remove default via etho and re-add that for tun0 and that fixed routing. Will check deepper what was a problem but looks like routing setup being added by openvpn was not correct.