OpenVPN Dropped Packets

I’m seeing DROP_NEWNOTSYN and DROP_CTINVALID events in my ipFire Firewall Log related to OpenVPN Road warrior connections (tun0). ipFire is acting as the OpenVPN server.

Users are not complaining, but I suspect that performance is suffering. Ideas?

Here’s the /var/ipfire/ovpn/server.conf file:

#OpenVPN Server conf

daemon openvpnserver
writepid /var/run/
#DAN prepare OpenVPN for listening on blue and orange
dev tun
proto udp
port 1194
script-security 3
ifconfig-pool-persist /var/ipfire/ovpn/ovpn-leases.db 3600
client-config-dir /var/ipfire/ovpn/ccd
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /var/ipfire/ovpn/ca/dh1024.pem
tun-mtu 1472
mssfix 0
keepalive 10 60
status-version 1
status /var/run/ovpnserver.log 30
cipher AES-256-CBC
auth SHA512
tls-version-min 1.2
tls-auth /var/ipfire/ovpn/certs/ta.key
max-clients 100
tls-verify /usr/lib/openvpn/verify
crl-verify /var/ipfire/ovpn/crls/cacrl.pem
user nobody
group nobody
verb 5
#- Log clients connecting/disconnecting
client-connect “/usr/sbin/openvpn-metrics client-connect”
client-disconnect “/usr/sbin/openvpn-metrics client-disconnect”

#Start of custom directives
#from server.conf.local

Here’s a client.conf file:

#OpenVPN Client conf
dev tun
proto udp
#tun-mtu 1472
remote XXX.XXX.XXX.XXX 1194
pkcs12 username.p12
cipher AES-256-CBC
auth SHA512
tls-auth ta.key
verb 3
remote-cert-tls server
verify-x509-name name
#mssfix 0


I am pretty confident that neither DROP_NEWNOTSYN nor DROP_CTINVALID cause any noticeable, if even measurable, performance impact. :slight_smile:

Both are not security-critical as well, and can occur at a decent amount even if very clean and tidy networks. For OpenVPN roadwarriors, I would expect them even more, since intermittent connection failures are a common root cause.

For example, if a device using an OpenVPN connection to your IPFire is using a cellular connection or a flaky WiFi, IPFire might not receive some packets in the middle of a connection, but the device never realises that. Hence, from IPFire’s perspective, a network packet might been “new”, but does not have a SYN flag - because it was never meant to initiate a new connection in the first place. The more unstable the connection is, the more likely is this to happen.

To cut it short: Don’t worry about these, unless their volume goes up by magnitudes. :slight_smile:

Thanks, and best regards,
Peter Müller

1 Like

John - just so you know I’ve seen ~102,000 DROP_CTINVALID messages in the past 30 days.

And ~50,000 DROP_NEWNOTSYN messages in a month.

This is on a small home network (<25 devices).

That’s reassuring, however, these events seem to be related to problems I’m having which I described here: Firewall log entries CT_INVALID - #11 by krause.

I’m still troubleshooting this matter. I’ve ordered a new router to test whether the TP-Link ER605 is the problem. Perhaps I should open a new thread?

I think you meant to point to your post which is Post 12:

Are you ordering the new router to fix DROP_NEWNOTSYN / DROP_CTINVALID? If so then I don’t think that will fix anything.

That sounds fine.

And we can close this post if your OpenVPN questions are answered…