Openvpn tls sniffing at the WAN - Block certain ip address from the internet / WAN

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi All,

I'm trying to block certain ip address/ranges from the WAN interface with the firewall function in openwrt. I see in the logging that the openvpn TLS connection is triggered (udp port 1194) and this is continuesly going on from certain IP's from USA / Africa, etc. I'm not located there, so a block of ip ranges should be OK. What i tried;

root@OpenWrt:~# nft list table inet fw4
* snip, not relevant* 
chain input_wan {
                ip saddr { 50.250.236.0/22, 164.160.88.0/22 } counter packets 56 bytes 2352 jump handle_reject comment "!fw4: block-sniffers"

And i see in the system log;

logread;

Tue Feb 20 16:29:40 2024 daemon.err openvpn(server)[2102]: 164.160.88.x:8888 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Feb 20 16:29:40 2024 daemon.err openvpn(server)[2102]: 164.160.88.x:8888 TLS Error: TLS handshake failed
Tue Feb 20 16:29:40 2024 daemon.notice openvpn(server)[2102]: 164.160.88.x:8888 SIGUSR1[soft,tls-error] received, client-instance restarting
Tue Feb 20 16:29:42 2024 daemon.notice openvpn(server)[2102]: 164.160.88.x:8888 TLS: Initial packet from [AF_INET]164.160.88.x:8888, sid=xxxxxxx xxxxxxx

It seems connections are still coming in ..even after a block on the WAN side for the whole ip range. Any tips / advice for further troubleshooting?

Thanks

2

It is strange that those IP addresses are not blocked did you restart the router?

To harden OpenVPN you can add tls-crypt, this stops an attack very early in the authentication process

3

The router is indeed restarted, i'm thinking it could be due to the priority in fw4: I think my block rule is in the pre chain section.Might be that openvpn is earlier in the set?

The possible positions for nftables snippets are:

Position Meaning
ruleset-pre At the very beginning, before the fw4 table definition
ruleset-post At the very end, after the fw4 table definition
table-pre At the beginning of the fw4 table, before any chain definition
table-post At the end of the fw4 table, after all chains definition
chain-pre At the beginning of $chain (defined in option chain), before rules in this chain
chain-post At the end of $chain (defined in option chain), after rules in this chain
4

Digged into this, but that's not the right way i believe. So to break it down :wink:
OSI Layer story ..UDP/TCP/ANY protocol - DROP goes before next layers in the OSI (TLS handshake etc.). Right. I see counters increase in the rule, but also traffic arriving. So i believe the DROP is not Dropping traffic, but just marking them/flagging/ counting it?

5

I think also in nft, the rule which is hit first will take priority so make sure the block rule is before the the allow rule for the port.

In LuCi you can move the rules by clicking on the
afbeelding

6

Hi, Some research further;

  1. /etc/init.d/network restart is needed (i think?) to reload the network stack after firewall changes are made
  2. in the logging i see still existing connections coming in from ip ranges just added to the block list. However, after a compleet reload of the router it seems to be clear.

So after adding ip ranges to the firewall block rule, i appearently need a full reboot of the router due to caching / sessions.