Messages

It was no OPNsense problem, it was a routing Problem of IPv6 before the OPNsense.

Just for reference: The OPNsense is running on a Proxmox host on a hetzner dedicated server. When following the setup described in hetzner wiki https://community.hetzner.com/tutorials/install-and-configure-proxmox_ve/de for routed setup, the Proxmox host automatically adds a route to an internal vmbridge. Use "ip -6 r" to check. This route causes the trouble. Manually deleting the route on the Proxmox host solves the issue, but needs to be deleted manually after ever reboot.

To prevent this behaviour, edit  /etc/network/interfaces:

        pre-up sysctl -w net.ipv6.conf.default.accept_ra=0
        pre-up sysctl -w net.ipv6.conf.default.autoconf=0

        pre-up sysctl -w net.ipv6.conf.all.autoconf=0
        pre-up sysctl -w net.ipv6.conf.all.forwarding=1


It is important to add ...default... with only ...all... it did not work.

Thank you for verifying that the rule needs to be set in WAN interface.

It is a very strange behaviour as this also happens with ssh access on port 22, so the problem should not only be related to HTTP/3.

Even if I delte all the inbound rules on WAN or DMZ (as non of them work anyway) and try to connect via ssh to the IPv6 of our server in the DMZ, the connection attepts are only shown on the DMZ interface, not on the WAN interface - but as stated - in reverse order.

Thanks for you reply. Setting the rule on the WAN interface did not help.

Are you sure it needs to be set on the WAN and not the DMZ? In firewall logs live view the connection attempt hits on DMZ and not WAN, though source and destination are inverted as described in the first post.

[It seems that the "source" and "destination" are inverted?!]

Hi,

we are currently adding IPv6 to our setup. The basics work well so far. The OPNsense gets its IPv6 /56 net, RA is working and all the clients and servers succesfully get their IPv6 "global" and "unique local" addresses from /64 subnets and can surf the internet (IPv6 and IPv4) without any problems. The clients and servers also can get pingend by their global IPv6s from the internet, so far so good.

Problems start when trying to open inbound ports from the internet for our servers in the DMZ. We added a firewall rule to the DMZ:

--
Action: pass
Interface: DMZ
Direction: in
IP Version: IPv6
Protocol: TCP
Source: any
Destination: <global IPv6 address of web server in DMZ>
Destination port range: 80
--

The connection to port 80 from the internet does not work and the live view of the firewall log shows this:

--
State: Block
Interface: DMZ
Direction: in
Source: <global IPv6 address of web server in DMZ>:80
Destination: <global IPv6 address of internet client trying to connect>:17619
Label: Default deny / state violation rule
--

It seems that the "source" and "destination" are inverted?! I do not understand why and what to do here to get inbound connections working. I hope that someone can give me a hint regarding this issue.

Version: 23.7.10_1
Architecture: amd64

Feature request: https://github.com/opnsense/plugins/issues/3274

Hi,

some smart host providers allow authentication via certificate instead of IP or user/password. E.g. O365 outlook connector supports this.

To make this work the following settings in postfix conf need to be set for outgoing connections:
postconf -e "smtp_tls_cert_file = <cert file>"
postconf -e "smtp_tls_key_file = <cert key>"

As I can see, currently the certificate selected in the GUI only applies to inbound connections:
postconf -e "smtpd_tls_cert_file = <cert file>"
postconf -e "smtpd_tls_key_file = <cert key>"

Am I missing something or may there be a chance to add this support?
Thank you.
Fred

Thank you!

via console: "opnsense-patch -c plugins cc0605386cc" solved it

Hi, I think there is a bug with the nginx plugin version 1.28_2 on OPNsense 22.7_4. (updated from 22.1.10_4).

I have "Basic Authentication" enabled on a "location" and assigned  a "Basic Credentials List". When accessing the URL the basic auth form pops up and credentials can be entered. But even when entering correct credentioals, the popup reappears.

In this moment a system firmware error is thrown:
---
PHP Fatal error:  Uncaught ArgumentCountError: crypt() expects exactly 2 arguments, 1 given in /usr/local/opnsense/scripts/nginx/setup.php:231
Stack trace:
#0 /usr/local/opnsense/scripts/nginx/setup.php(231): crypt('<here goes the password>')
#1 {main}
  thrown in /usr/local/opnsense/scripts/nginx/setup.php on line 231
---

At the same time also nginx reports an error:
---
*18413 user "<here goes the user name>" was not found in "/var/db/nginx/auth/d0c4603...
---

Maybe someone can look into this. Thanks.