IPv6 Firewall blocks traffic and logs show destination as source

[CrunchPeach]

Hello,

I just setup IPv6 and I got a reverse proxy behind OPNsense, which address is (for the example) 2001:db8::1/128.

When I open the firewall on port 443 to 2001:db8::1, I can access the website returned by the server when connected from WAN (such as via LTE).

Now I got a subrouter, to which OPNsense delegates a prefix, so I got a subnet, let's say 2001:db9::/64 and I can ping and access internet via IPv6. When a device (2001:db9::1/128) from this subnet tries to access the server, it doesn't work, and I can see in OPNsense's firewall logs that the query is blocked.

IPv4 uses NAT reflection to achieve this, but since IPv6 is globally routable, there isn't such settings.

However, the firewall logs say that the source is [2001:db8::1]:443 and the destination is [2001:db9::1]:random_port and this makes no sense. They should be inverted.

The same problem happens when I try to ssh to it. The source is [2001:db8::1]:22 and destination is [2001:db9::1]:random_port (as seen in the screenshot).

I disabled the firewall and it works. The rule matching the block is "Default deny / state violation rule", I tried to add a "pass" rule from [2001:db8::1]:any to [2001:db9::1]:any, I tried to create a rule with both addresses switched, but nothing worked.

I have no idea why this is happening and I don't understand at all. Does anyone have any idea?

Thank you!

[Patrick M. Hausen]

However, the firewall logs say that the source is [2001:db8::1]:443 and the destination is [2001:db9::1]:random_port and this makes no sense. They should be inverted.

The reverse proxy is sending the reply packet to your OPNsense instead of the sub-router, because it has got only the default route pointing towards OPNsense. OPNsense has not seen the initial SYN and treats the SYN/ACK as a new packet with source and destination as you see and a state violation.

Firewall > Settings > Advanced > Static route filtering

[CrunchPeach]

That makes sense.

However Static route filtering didn't solve it, I had to add a route to the sub-router on the reverse proxy.

Also, shouldn't creating a rule manually allow OPNsense to route the packet to the sub-router?

[Patrick M. Hausen]

A rule with state type "none" might work (advanced settings in the rule).