Messages

Hi,
just to be  on the safe side, did you create rules to allow the traffic between the nets? Per default IIRC the firewall will block al traffic.

I think someone from the team already fixed that.
I just searched for updates and there is a new Postfix release available.
Updated it --> all is fine.

Thank you!

After the upgrade to 25.1.2 postfix does not start anymore.

In the Log I only see:

28cafc05-69bf-4067-8fa6-be5124013484] Script action failed with Command 'postmap /usr/local/etc/postfix/transport ' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/actions/script_output.py", line 78, in execute subprocess.check_call(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.11/subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command 'postmap /usr/local/etc/postfix/transport ' returned non-zero exit status 1.


Any help is appreiciated.

Is it safe for those that have external DB?

I can only share that for me, using an external elastic database it works without problems. But I have to admit I am a home user and I can rebuild the box easily (proxmox snapshot).
So in case you use opnsense on a business relevant machine I would recommend waiting for an official announcement.

For me it worked after the upgrade.
My setup is using a remote elastichsearch database and upgrading Opnsense did not defunctionalize zenarmour.

Fixed it by choosing an encryption protocol instead of setting the encryption to default

Hi,
after applying the hotfix 24.7.4_1 on my two Opnsense boxes during the IpSec negotiation I see the error:

Code Select Expand


"parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]"
received NO_PROPOSAL_CHOSEN notify error

Any ideas if there is some conection to the update?

I had exactly the same issue with a digicert certificate. When I imported it it showed up as self signed, although the Digicert issuein CA is my Authorities store.
After some try and error this is how I solved it:

• Import the certificate it will show up as self signed.
• Edit the certificate make sure the action is is set to "Reissue and Replace certificate and make sure you select the correct CA
• Click Save --> You will get an error
• Change the Action to "Create a certificate Signing Request" and Save. You should now see the certificate with the correct CA
• Click on edit and select "Import Certificate (Signed by CA) it should be the only option
• Save it.

After this you should see the certificate with the correct CA assigned.

I am of course just guessing, but based on what you shared you see that traffic is reaching your WAN interface and then is dropped/blocked. So I personally do not think that the ISP is blocking you, as you might not be able to see anything in this case.
Are you sure that you are not behind some carrier grade natting and got in an IPrange for private usage with your WAN  port, as this then would trigger the default rules.

Not all of them.
Some are servers, some are mobiles. Some are VM's and some are physical

Glad to hear that!

I faced a similar issue and it turned out that after the update to 24.1 haproxy simply was working listening on all IP interfaces for port 443.
That is the only option for me as I am getting a dynamic IP Address on my WAN port so I cannot bind Haproxy to a specific one and had to us e0.0.0.0:443

So the first workaround was to move the admin website to a different port than 443

Then I fixed it by implementing a VIP where I used port forward to redirect all traffic for 443 to a different port on that VIP and then used haproxy to proxy that.

See:
https://github.com/opnsense/plugins/issues/722

Most important thing here was to redirect port 443 in the Nat to a different Port on the VIP for example 40443 and then bind haproxy to that IP/port

When I review my setup, I see the same devices being "discovered" as new devices over and over again although the devices themselves remain the same. It might be that the IP Address is changing but in an environment with DHCP that should be expected.
Is there any intention to make this more reliable?
At the moment it is impossible to create a Policy to block untrusted devices and assume all new devices are untrusted.

Hi,
maybe you face the issue described here:
https://forum.opnsense.org/index.php?topic=38435.0

Got that franco, thank you for clarification