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/openvpn.pid #DAN prepare OpenVPN for listening on blue and orange
;local XXX.XXX.XXX.XXX
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
tls-server
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
server 10.102.94.0 255.255.255.0
tun-mtu 1472
mssfix 0
keepalive 10 60
status-version 1
status /var/run/ovpnserver.log 30
ncp-disable
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
persist-key
persist-tun
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
tls-client
client
nobind
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 xxx.xxx.xxx.xxx name #mssfix 0
I am pretty confident that neither DROP_NEWNOTSYN nor DROP_CTINVALID cause any noticeable, if even measurable, performance impact.
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.
