Topics

1

24.7 Production Series / OpenVPN Instances - Buffer Size / TLS Version Minimum / NetBIOS

« on: August 27, 2024, 04:44:19 am »

Hello! Posting first before submitting a feature request... Looking at migrating my OpenVPN servers over from legacy to Instances. I'm noticing a few advanced options I use are missing and curious if anyone else feels they should be included.

Buffer size: I always set sndbuf + rcvbuf as well as push them to the client. This is extremely important for mitigating bandwidth bottlenecks, especially on faster and/or higher latency connections. Would it make sense to request an option for each with a text box where the value can be entered in bytes, with an accompanying checkbox to push the custom value to clients? Essentially achieve an affect similar to:

sndbuf 2097152
push "sndbuf 2097152"
rcvbuf 2097152
push "rcvbuf 2097152"

TLS Version Minimum: The option I use to meet compliancy policy requirements & prevent TLS downgrade attacks. Would it make sense for this to be a drop down option w/ 1.2, 1.3, and Highest as options? This would achieve something similar to the following:

# Use 1.2
tls-version-min 1.2
# Use 1.3
tls-version-min 1.3
# Use Highest Supported
tls-version-min 0.0 or-highest

Disable NetBIOS: And last, the push options list would be a good place for this. Disable NetBIOS name lookups to cut down on VPN traffic. Maybe called "push disable-nbt". This would achieve the following:

push "dhcp-option DISABLE-NBT"


I request your feedback on the above. Thank you!

2

24.1 Legacy Series / Copy Multiple Firewall Rules

« on: April 07, 2024, 11:06:48 pm »

Is it possible to copy multiple firewall rules to a different interface? I know you can copy a single rule one at a time.

I've searched all over, and tried many things in the GUI.

3

High availability / CARP DHCP Cluster - Failover Split Ignored

« on: December 30, 2023, 10:09:27 pm »

I have a 2 node DHCP CARP cluster setup. I only want the primary handing out leases (whichever happens to be primary at the time) so I've set the Failover split to 256. XMLRPC Sync has replicated the Failover split value of 256 to the secondary node (the text help states it will be ignored on the secondary so this should be fine, but the text help also says to leave the value blank on the secondary which XMLRPC Sync does not do.)

However, it seems both the primary and backup are still handing out DHCP leases. I tried fixing this by setting the response delay on the backup, but that value gets wiped out as soon as the config gets synced from the primary so that won't work.

Any idea how I can get only the primary to hand out DHCP leases via the Failover split value?

4

Development and Code Review / [Plugin / Base Package Request] - haveged

« on: March 06, 2018, 01:32:36 am »

Either as an optional plugin, or adding it as part of the base install, I think this would bring a lot to the table, security (and performance) wise...

This daemon generates an impressive amount of unpredictable and unmonitorable entropy, at an even more impressive load (or lack of it) on the system. In all cases, it ends up being significantly more efficient, and produces significantly better entropy (more unique randomness), than the stock kernel RNG.

It does this by reading internal volatile hardware states. This translates to having equally high speed and quality entropy, on both physical and virtual instances. These hardware states are virtualized by all hypervisors, and so give virtual machines even more benefit, as virtual hardware has notoriously poorer entropy, than physical hardware, using traditional RNG's.

Benefits (especially on virtual instances), off the top of my head:
- All security certs generated become much more secure (SA, Server, User, Web, etc. certificates)
- Any process that waits for a specific amount of unique entropy before starting / continuing
- Reducing random delays and pauses for the entire system, when entropy is needed
- Enhancing the security of all systems using encryption (Web server, IPSEC, OpenVPN, SSH, HTTPS, etc.)

Many, many more...

A very large number of cloud based hosting providers are recommending this be installed in virtual instances.

Some specific software packages recommend this be installed when using virtual instances, especially where web servers / crypto / entropy is involved (ie Ubiquiti UniFi), clearing up service start delays, usage delays, etc.

Some other BYOD firewall's / UTM's already use haveged, ie Sophos UTM.

http://www.issihosts.com/haveged/
http://www.irisa.fr/caps/projects/hipsor/

5

18.1 Legacy Series / Kernel Panic When Using Certain Scheduler Types

« on: November 09, 2017, 06:05:00 am »

Assigning certain scheduler types to pipes in the traffic shaper, causes the system to kernel panic and immediately reboot. I didn't even get a crash dump, any of the multiple times this happened.

The message(s) you will find in the system log before the panic, will be very similar to this:

Code: [Select]

heap_extract: empty heap [random memory address hex value]
The higher the volume of traffic being processed, the sooner the panic. So, if you have a very high traffic load on an OPNsense instance already, you won't have time to read the system log from the WebGUI. The most you will see is the above message being output to the console. The most consistent way to trigger (reproduce) the panic, in my case, was to hit the bandwidth limit on any of the pipes in question. This would trigger a kernel panic in a few seconds, if not less. If you are testing, set an arbitrarily low limit on a pipe, and push some traffic to hit the set limit.

I have tracked it down to the way byte based scheduling algorithms work in ipfw. My fix for this issue, was to:

- Unplug or disable interfaces to stop traffic flowing through the shaper.
- Temporarily disable all pipes + queues, apply, reboot (this stops the kernel panics).
- Plug in or enable interfaces from first step.
- Change the scheduler type for all pipes, to a packet based algorithm (rather than byte based), I chose Deficit Round Robin here, for example.
- Enable all pipes + queues, apply, reboot.

Everything should be just fine now. If you still get heap_extract messages, double check that you didn't miss the scheduler type change on any pipes.

The biggest issue with all of this, from my standpoint, is that the default "you never see it unless you toggle the advanced slider" scheduler type, is Weighted Fair Queuing. Weighted Fair Queuing is indeed a byte based algorithm, and is responsible for causing this kernel panic on the hardware in question.

My best guess, is that some network interface drivers misreport byte rates, feed invalid values into an unchecked Weighted Fair Queuing function, and since ipfw shaping algorithms are all kernel modules, we get a panic. As changing to a packet based algorithm stopped the kernel panics, I would guess the drivers in question are at least reporting packet rates correctly, or, the packet rate functions are checked. I base this guess on the fact that I have multiple production OPNsense VM's running, that pair vmxnet3 interfaces with Weighted Fair Queuing pipes, and have yet to see a single kernel panic on any of them.

Given the above fix worked, without changing anything else at all, I would guess a change to ipfw's WFQ code is responsible? Even if it happens to be a coding issue elsewhere in the base system, relying on values from NIC drivers anything outside of ipfw's control, unchecked, in the kernel, seems like a bad idea. Case in point.

To me, this screams "fix upstream". I would bet vanilla FreeBSD suffers from the same issue. Personally, I lack the understanding of the FreeBSD source code to properly get a fix pushed upstream, or even attention drawn to the proper source code points. Hopefully someone who does, does.

Simply reply to this thread if I can offer any more information than I already have. I will do what I can.

Worst case scenario, this thread will exist for anyone else seeing the above issue on OPNsense, or FreeBSD, in the future.

| Hardware Used |
- Dell Dimension 5150 (Intel Pentium D CPU 2.80GHz, 945G chipset)
- 1x Intel 82801GB 10/100 Ethernet (using fxp driver)
- 1x 3Com 3c905C-TX Fast Etherlink XL (using xl driver)
- SanDisk SDSSDA120G SSD (boot device in AHCI mode)

| Software Used |
- OPNsense 17.7.7_1-amd64 (panic experienced on multiple versions of 17.7)

6

17.7 Legacy Series / tcp (ACK) Rules In Traffic Shaper Not Working

« on: September 21, 2017, 02:09:14 am »

Using iperf3 to test traffic shaper rules. Everything is working, except my one tcp (ACK packets only) rule. It matches absolutely every iperf3 TCP stream, if it's positioned at the top of the rule set.

If I reposition said ACK rule to the bottom of the rule set, everything works as it should (ie correct traffic into the correct queues).

I have to imagine this is a bug, as you would normally want to catch ACK's and prioritize them towards the top of a rule set. Even if you didn't, it still shouldn't be matching all TCP traffic.

This should be very easy to reproduce...

Simply make a rule bound to WAN, tcp (ACK packets only), any:any any:any, direction out, place at or near the top of your rule set. It will match all outbound WAN traffic, regardless of the ACK flag being set or not.

Any help and/or sanity checks are appreciated!