Messages

3. It would be nice if there was a clue in the firewall rules page that indicates that the "Allow IPv6" box isn't checked OR a rule has been applied to block IPv6 traffic. It's a big leap to see IPv6 traffic being blocked, going to the firewall rules page and seeing no rules that would block said traffic and then realizing that one needs to go to "System: Settings: Networking" to verify "Allow IPv6" is checked.

The option turned off while still showing checked in the GUI is an impossible solution, so if we pin down (1) correctly this will likely not be the case. Besides, IPv6 is enabled by default so it works out of the box (I know, except this bug).

The Filewall: Rules list could also show the rules implicitly applied due to other settings, as it is already the case for the Anti-Lockout Rule. I guess the Allow IPv6 setting is not the only setting affecting implicit pf rules.

Thanks for the detailed explanation.

The third slice is a twist of the NanoBSD script that needs to be enabled in order for the script not to crash and burn. It's not used.

So that means that nobody minds if the last slice ends in the middle?

Are there any hardware recommendations from the projects side? The PC Engines' ALIX (one of the most commonly used hardware for pfsense) is for your mentioned reasons not the best choice for OPNsense. The hardware is also already quite "old" and weak, compared to state of the art micro appliances.

Anyone tried OPNsense on PC Engines' newer micro appliance APU?

Great, thanks for the info.

The nano image (OPNsense-15.7.18-OpenSSL-nano-i386.img) is actullay 3999997952 bytes in size, while my 4GB Kingston CF card holds 3997163520 bytes. Interestingly I've a second 4GB CF from Transcend, which holds 4009549824 bytes.

I have no idea if there is a well defined definition for "4GB", but actually I guess I'm not the only one with a CF smaller than the nano image. What does the third slice of the image actually hold? Is there any important data in the last 50MB?

@gpac: which filesystem do you use on your USB pen drive? FAT32 or UFS?
Do you mount the drives manually before each upgrade or did you configure them in the fstab? Is the /etc/fstab persistent between updates?

I've just tried an update from 15.7.18 to 15.7.20 (the fifth time in a row) and failed again. I always end up with a corrupted file system. That time I had two external UFS partitions mounted to /var/cache and /tmp/opnsense-update and previously changed the opnsense-update script to adopt a predictable WORKDIR.

Is there any other way in upgrading to 15.7.20? I guess I'll build my own image and flash it directly to the CF...

Is there any difference between the nano images and the other images manually configured to use a ramdisk for /var and /tmp? Does the nano image use redundant partitions on the storage media, or so?

I've found out that both P2's have the same reqid set in the conn section of ipsec.conf. Unfortunately I don't know what charon does with the reqid, since also the man page is quite silent on that...

       reqid = <number>
         sets  the   reqid for a given connection to   a pre-configured fixed
         value.

I've a IPsec phase 1 entry with three phase 2 entries. Only the first in the list is being established. At the other endpoint I cannot even see OPNsense trying to establish the other P2's. If I swap the P2 entries (just order, no config), the new first P2 entry is being established.

The /usr/local/etc/ipsec.conf file contains all endpoints as configured via the GUI, namely con1-000 up to con1-002. In the IPsec logs i found:

Nov 29 10:30:22    ipsec_starter[87595]: 'con1-001' routed
Nov 29 10:30:22    ipsec_starter[87595]: 'con1-000' routed
Nov 29 10:30:21    ipsec_starter[87595]: configuration 'con1-001' not found
Nov 29 10:30:21    ipsec_starter[87595]: configuration 'con1-000' unrouted

I'm not so deep into charon, which log levels should I raise to get more info on that issue?

I use OPNsense 15.7.18_1-i386 (willing to upgrade to unstable if this would help investigations).