is there any possibility to exclude an IPv4-address indicated by it’s dynamic DNS-entry (e.g. ‘example.dyndns.org’) instead of it’s number (dsl-pool, changes a least daily) from beeing scanned by the IDS/IPS? Any solution, even manual workaround, is welcome, if it’s safe on reboot/upgrade.
Background:
I would like to increase vpn-throughput (~7%) and reduce cpu-usage (~10%) on connections to dynamic peers. These improvements were experimentally achieved by manually adding the current address (temporary) to the exception list.
What you’re saying is very interesting, but I have some bad news. By default, IPFire doesn’t do this in either IDS or Firewall Objects (which would be great if it did). In the Firewall, there’s a rather clumsy workaround: creating the object from the WUI and then editing the corresponding file and manually modifying the URL. This works, but for it to work, you have to restart the Firewall for it to resolve the IP (it doesn’t do this by default).
In the case of the IDS, I’m thinking of creating a Bash script to resolve the URL and place it in a file. Then, in the same script or in another file, modify the corresponding line where IPFire adds the exclusions (logically, formatting it to have the same format as IPFre). In that file where the IP from the name resolution is saved, I could save the previous one so I can also delete it and avoid filling the configuration file with old IPs.
You can either put these scripts in the Crontab or in /etc/fcron.daily, for example.
It’s a bit messy, but it’s what I can think of quickly.
I’m sure another forum member knows more than I do and can help you better.
There are a couple of improvements coming in IPFire Core Update 196 that you might be interested in - both aimed at improving WireGuard performance.
1. Backported TCP performance patch:
We’ve added a kernel patch originally from Linux 6.13. It enables BIG TCP GSO support for WireGuard, which allows for larger packet aggregation during encryption and transmission. This can lead to about a 15% improvement in TCP stream throughput.
2. Threaded NAPI for WireGuard interfaces:
CU196 also includes this change to enable threaded NAPI for each WireGuard interface. This lets the kernel handle network traffic processing in separate threads per interface.
On systems with multiple tunnels or higher throughput, this should make a huge difference — in one example (see Jason Donenfeld’s slides in the second link), throughput went from ~13 Gbps to ~48 Gbps, thanks to better CPU balancing.
first of all I would like to add, that IFire is already able to resolve the DDNS entry and track the corresponding IPv4-address in the WIO module. I thought about chances to forward this inormation, which is updated in short periods (5 min), to the exception list. But I understand that this and any similar solution proposed by @roberto is complicated (for me) and likely leads to further problems.
The announcements that @ag makes are interesting indeed and they could overcompensate the effect that I try to avoid. For the moment my observation is, that IDS/IPS adds additional cpu load, that could be avoided in those cases in which you know your (own) vpn-peers and fully trust them.
The most interesting point in my opinion is, that we use multiple (at least 2) wireguard vpn-connections on every IPFire machine in parallel, so that we can expect to benefit from the improvements.
Its odd the way they set up example.dynamicdns,org because when I look at their dhcp dns record they set the lease 7 days but checks for updates every 10 nminutes.
nslookup -debug example.dyndns.org
Server: 127.0.0.53
Address: 127.0.0.53#53
------------
QUESTIONS:
example.dyndns.org, type = A, class = IN
ANSWERS:
-> example.dyndns.org
internet address = 82.153.225.199
ttl = 300
AUTHORITY RECORDS:
ADDITIONAL RECORDS:
------------
Non-authoritative answer:
Name: example.dyndns.org
Address: 82.153.225.199
------------
QUESTIONS:
example.dyndns.org, type = AAAA, class = IN
ANSWERS:
AUTHORITY RECORDS:
-> dyndns.org
origin = ns1.dyndns.org
mail addr = hostmaster.dyndns.org
serial = 1313069687
refresh = 600
retry = 300
expire = 604800
minimum = 600
ttl = 100
ADDITIONAL RECORDS:
------------
But as in regards to performance issues with VPN services, its always been better to run a separate server for the VPN instead of running it on the edge device.
I’ve created a script (since I find this very interesting) that resolves to the fully qualified domain name (FQDN) defined in the “HOSTNAME=” line and modifies the object created in “Firewall Groups” → “Host” by changing the name defined in “Name” in the TARGET_ALIAS= line.
BTW: DHCP is not a name resolution service. It generates IPs for devices, identified by MAC, belonging to a certain network, identified by network interface.
I can’t remember the technical name for it, but what you query on the server using nslookup is a dhcp dns record. Which is not in the same format and it would throw an error on executing whois linux command because its not a standard dns record.
