Messages

Hi mattlf, I don't have a public IP range to test this but I think, from older posts I read, that you have to declare the additional public IPs of your range as VIPs (virtual IPs).

Btw: can anyone confirm that when setting the ICMP ID to 8 it does work, or is it only me?

patient0, I can confirm that using ID 8 works, as you stated.

One can suspect that the problem may be related to the use of the wrong variable being that the ICMP type of the ping is also 8.

Here is another possible fixed bug that may be related to this problem https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701

I think that this is only a matter of some configuration change between 24.7 and 25.1, but I didn't investigate it yet.

Well, it may not be a configuration problem at all.

Hi patient0, the ID is not the same as the type. This is an echo request packet:

Code Select Expand

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type (8)   |   Code (0)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Checksum (16 bits)       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Identifier (ID) (16 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Sequence Number (16 bits)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Data (variable)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As it happens with TCP/UDP with the port number (session number) the ID plays that roll on ICMP echo requests.

The fact that the ID is not changed within pf means that there can only exists one ICMP echo request with each ID when it leaves the router through WAN because there can be only one state with the public source IP and a certain ID.

The first process that makes the ping with that ID will be the one that could get the way out. The subsequent ones wont get their way because they can't be routed if there is already an existing state with the same ID.

I think that this is only a matter of some configuration change between 24.7 and 25.1, but I didn't investigate it yet.

Hi d00b2020, I made some tests and could see the described behavior.

Thank you Patrick. I have it already on a 32 GB thick provisioned vmdk.

Cheers

First of all, thanks to all the OPNSense Team.

This time I had to reinstall to move to ZFS, so I exported the configuration with RRD data included and made a full install on a ZFS pool.
The config import was done during installation with the configuration importer from a USB drive.
After the first boot, I reinstalled the plugins and then everything worked fine.
All of this was done on a a VMWare ESXi virtual machine. Now I'm able to use ZFS snapshots instead of ESXi ones.

A really really great work of OPNSense developers.
Thank you and cheers...

Hi. I'm testing OPNsense 25.1.b_20. Installed from DVD over a previous 24.7.11 VM.

In my case I first exported the configuration and then imported it on the newly installed box during installation with a pendrive.
Everything was just fine without errors. The only thing I had to fix was reinstall the devel versions of the plugins I were testing.
VMWare tools plugin is working just fine. The other two, ndproxy and tailscale didn't work so I disabled them for now.
I've tested the snapshot feature and is really excellent. I have this feature from the hypervisor but I think that is much better to use it natively on ZFS.
I've tested to switch the active snapshot during boot and it works fine.

One thing I could ask is the option to generate a snapshot automatically before an update, if it is not already there.

Dark theme is fine for me. I know that it could take some time to get used to this kind of changes, but it doesn't differs too much from the cicada theme I'm using on my main box.

The certificate dashboard looks fine, I'll wait to test it with my main router.

Thanks to the OPNSense team for the great work and cheers....

and I am a FreeBSD evangelist

You deserve an applause for this phrase, but with this new blog I think we can not applause anymore.

I had this case years ago.. I mean, I'm on the same case that @logi.

Some years ago (two or three) my ISP started to assign IPs v6 but no PD. My workaround was to use NAT and subnet the /64 address they assigned.
I know that NAT is almost forbidden in IPv6 but I didn't find anything better yet. It passes all IPv6 tests out there and it works fine.
Forget to use IPv6 on Android because it needs SLAAC and SLAAC needs a /64 net. But works flawlessly on the rest of the cases.

The animated background is really annoying  ;D

If you press the pencil button at the upper right cornet it will show two more buttons, one to add widgets and the other to restore the default layout.
Try to restore the defaults and may be the ghost widget will disappear.

I had this kind of problem while testing 24.7 betas... I assumed that it was because the lack of resources on my testing environment.
Celeron 11 or 12 years old... I was running a virtual router and managed it by a virtual desktop.... veeeeery slow, but enough for testing purposes.
Now that I've updated my main router I didn't see this error anymore.

Upgraded the main box and is working fine.

Tested almost everything and is functional.

Was able to replicate the old dashboard layout with some minor differences, but it looks very very good.