[Solved] OpenVPN client connects but cannot talk to server

[nicsure]

Hi and thank you for reading this.

I'll try to break this down as much as possible. I have a working OpenVPN server located on a remote VPS. This server works fine, I can connect to it from OpenVPN Connect from a Windows machine and all is good. Using the same configuration (yes the Windows client is disconnected now) I setup a client config on my OpenWRT router, only thing I changed was to add 'route_nopull' to prevent it from overriding my default gateways. This config successfully connects to the server and obtains both v4 and v6 addresses. At this point, if I attempt to ping the remote server IP of 10.50.1.1 I get no reply. I figured this was some firewall rubbish so I created an unmanaged interface attached to tun0 and created a firewall zone for it. The zone is set to allow everything, I even created two explicit rules to allow everything coming into and going out of the vpn interface. After that I still get no ping reply (Just to confirm here, the VPN server does reply to pings). So now I go to my VPS and setup packet logging for incoming and outgoing ICMP ping packets and discover that ping requests from the client are indeed getting through to the VPS and ping replies are also being sent back. Using 'ifconfig tun0' from the OpenWRT side I can see the TX byte count increasing each time I attempt to ping, however the RX byte count stays at 0, so these ping replies are never getting back through OpenVPN to tun0, this again suggests an incoming firewall issue, but I'm stumped as to what it could be. I've not setup any WAN stuff with this yet, as getting the underlying communication working would be required.
(lzo compression IS disabled on both sides)

Anyone have any ideas what I've done wrong here?

### Open VPN config
config openvpn 'Test1'
        option nobind '1'
        option float '1'
        option client '1'
        option persist_tun '1'
        option persist_key '1'
        option verb '2'
        option comp_lzo 'no'
        option ca '/etc/openvpn/ca.crt'
        option port '8443'
        option proto 'tcp-client'
        option remote 'VPS-IP'
        option resolv_retry 'infinite'
        option key '/etc/openvpn/vpn2.key'
        option cert '/etc/openvpn/vpn2.crt'
        option dh '/etc/openvpn/dh2048.pem'
        option cipher 'AES-256-GCM'
        option mute '20'
        option auth 'SHA512'
        option keepalive '10 120'
        option route_nopull '1'
        option dev 'tun0'
        option remote_cert_tls 'server'

### Network Interface
config interface 'NicsureVPN'
        option ifname 'tun0'
        option proto 'none'

### Firewall
config zone
        option name 'vpn'
        option network 'NicsureVPN'
        option input 'ACCEPT'
        option forward 'ACCEPT'
        option mtu_fix '1'
        option output 'ACCEPT'

config rule
        option target 'ACCEPT'
        option name 'Allow-VPN-In'
        option src 'vpn'
        list proto 'all'

config rule
        option dest 'vpn'
        option name 'Allow-VPN-Out'
        option target 'ACCEPT'
        list proto 'all'

[vgaetera]

Enable masquerading on the VPN zone and check again.

If the problem persists, establish the VPN connection, collect the diagnostics from both VPN server and client, and post it to pastebin.com redacting the private parts:

ip address show; ip route show table all; ip rule show; iptables-save

[nicsure]

I think I discovered the problem. It's to do with lzo compression. Even though I've disabled it, I'm getting errors on the OpenWrt side logs about bad packet IDs. That is generally an indication that some compression mismatching is happening. The logs on the VPS side show no packet id errors. I've double checked the VPS config and it absolutely does not have compression enabled. Oddly, another strange thing is when the client connects, the VPS side logs show this:

2021-02-18 11:51:41 x.x.x.x:50548 peer info: IV_LZO=1
2021-02-18 11:51:41 x.x.x.x:50548 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'

The default for comp-lzo is disabled so the options just isn't present in the server config. But for some reason the logs for the negotiation show that the client does have it enabled. This kinda makes sense, it's like on the OpenWrt side, it believes compression is off so it sends uncompressed packets, they arrive at the VPS and are processed, but (for some reason I can't figure out) the reply packets are being compressed. Maybe some unpredictable behaviour due to strange options that are being misinterpreted somewhere.
...
...
Aaaaaaand that was indeed it. All I had to do was completely remove the comp-lzo line from the client config and it's working fine now.

EDIT: I think I'll report this over on OpenVPN as I don't think it's a UCI problem. Seems that having an explicit option in the client config to disable comp-lzo is causing unpredictable and conflicting behaviours.