[solved] IPv6 firewall log - Source and Destination are inverted

[fred.bloggs]

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

[tiermutter]

No idea why it is inverted in log, but allowing inbound v6 should be done on WAN interface even if the destination is in LAN / DMZ.

[fred.bloggs]

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.

[meyergru]

When you inspect the block log entries more closely, you may find that those are indeed blocks because of state violations for the answers going out, which also explains why they seem to have inverse source and destinations.

Sometimes, there are early ACK packets that cause this. Also, HTTP/3 is a problem - I have not yet found how to enable that with OpnSense.

And yes, you have to open the IPv6 ports on the WAN port.

[fred.bloggs]

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.

[meyergru]

You can enable logging in your incoming WAN allow rule to see if it is triggered at all.

[fred.bloggs]

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.