Firewall is showing a lot of "Default deny rule" for IPv6 interface connections

[Sempiterna]

Hi,

I have a strange problem with an IPv6 interface (named in my opnsense as IP6NET). This interface is the interface specific for IPv6 WAN, next to the regular "WAN" interface I use for IPv4. There is also DHCPv6 configured for this interface.

In my network I have a Windows 10 system which receives a DHCPv6 address, and is able to browse IPv6 sites, and is able to connect via IPv6 to my IRC network at port 6667. However, after a minute or so the connection drops. I see in the Opnsense firewall that the connection is allowed, followed by "Default deny rule" blocks for (among others) connections to the same server for port 113 (ident).

After a minute or so, I start seeing the same connection to IRC on port 6667 that had a "pass" before, appearing  in the firewall with a Default deny rule block, after which the IRC connection is disconnected.

This appears to be triggered by firewall rule 10:

@10 block drop in log inet6 all label "02f4bab031b57d1e30553ce08e0ec131"

I also see a lot of Default deny rule hits from this same IPv6 IP on my windows 10 client to addresses on port 80 and 443, which I can browse via IPv6 just fine. Next to the automatically generated rules on the IPv6 interface, I also have one rule that allows all "in" traffic on protocol IPv6* for all source, ports, destinations, etc.

How can I stop the firewall from denying this perfectly fine IPv6 traffic?

Examples from the firewall log where you can see the connection gets a pass (I can connect to 6667), and then after 1.5 minutes the connections to 6667 with the same source and destination gets blocked:

Code Select Expand

IPv6NET Oct 9 18:03:38 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp Default deny rule
IPv6NET Oct 9 18:03:38 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp Default deny rule
IPv6NET Oct 9 18:03:38 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp Default deny rule
IPv6NET Oct 9 18:03:38 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp Default deny rule

IPv6NET Oct 9 18:01:55 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:113 [xxxx:xxx:xxx:4488::5]:49567 tcp Default deny rule
IPv6NET Oct 9 18:01:51 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:113 [xxxx:xxx:xxx:4488::5]:49567 tcp Default deny rule
IPv6NET Oct 9 18:01:49 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:113 [xxxx:xxx:xxx:4488::5]:49567 tcp Default deny rule
IPv6NET Oct 9 18:01:49 fe80::1c97:f31e:7a4:53d8 fe80::d875:32ff:fe3d:fb13 ipv6-icmp IPv6 RFC4890 requirements (ICMP)
IPv6NET Oct 9 18:01:48 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:113 [xxxx:xxx:xxx:4488::5]:49567 tcp Default deny rule
IPv6NET Oct 9 18:01:48 [xxxx:xxx:xxxx:c0:20f:ffff:ffff:2000]:64848 [xxxx:xxx:xxx:4488::5]:6667 tcp let out anything from firewall host itself

[Greelan]

Post the full config for the FW rule on IP6NET

[Sempiterna]

I'm not sure if a screenshot of the custom IPv6NET rule (see attachment) is what you want to see, or an export of for example the ipv6 part of the rules in "/tmp/rules.debug"

[Greelan]

Screenshot is good. Try specifying the WAN IPv6 gateway in the rule, rather than default

[Sempiterna]

I did try that as well earlier today, but that did not make a difference. I didn't think it would either because it is able to set up the connection to irc server on port 6667, but seems to selectively block for example port 113.

During that ~1.5 minutes the connection is live I can see it blcoks some higher ports as well. When the connection drops, it shows a few 6667 port blocks with the default deny rule. I observe the same behaviour on other irc ports and other irc servers.

It's probably also not irc specific as I also see other default deny rule blocks happening on for example port 80 and 443. I don't know where those are coming from, but they do originate from my Windows 10 client (not initiated by myself).

As a bit of background, my setup consists of 3 interfaces:

vtnet0 (ipv4 WAN)
vtnet1 (IPv6NET ipv6 WAN)
  - DHCPv6
em0 (LAN)
  - DHCPv4

The windows 10 client has no connection to ipv4 WAN, but only to IPv6NET and LAN. But it is able to go out over ipv4 via the LAN interface.

[Greelan]

Ah, so your IPv6NET is the WAN interface, rather than an internal interface that you are using only for IPv6 access?

IMO then you need to configure a rule on the LAN interface that forces all IPv6 traffic incoming on that interface to use the IPv6NET gateway

[Sempiterna]

That too does not work (i just tried it). I don't see how LAN would mess up this configuration though.

On my opnsense VM, IPv6NET is a WAN interface that's used only for IPv6, because I technically can't have this IPv6 WAN on the regular WAN interface that holds my IPv4 WAN address. I have DHCPv6 enabled on this IPv6NET interface so that I can give out externally reachable IPv6 addresses.

So basically this windows 10 client VM has an internal DHCP provided IPv4 LAN address (192.168.100.209) on one interface, which it also uses to  access IPv4 websites on the internet (through the IPv4 WAN address on opnsense). And on the other interface is a DHCP provided external IPv6 address that is provided by the DHCPv6 service on opnsense on IPv6NET, and has the opnsense IPv6 address (the static IP on IPv6NET interface) as gateway.

So when I go for example to "whatismyip.com" on that windows 10 client to check what my external IP's are, I see for IPv4 the opnsense WAN address and for IPv6 I see the address I received from DHCP.

[Greelan]

Right, this is not a setup I am familiar with or am confident that should work. Effectively you seem to be seeking to use the same subnet for both the WAN interface and internal clients

[Sempiterna]

I added another interface (IPv6LAN) and set up DHCPv6 on that one on /80 instead of /64. The end result is the same. Somehow some all outward traffic to port 113 is blocked by the default deny rule, the initial connection to port 6667 is allowed (i can connect and interact to the external irc server), but after ~1.5 minutes all the traffic to 6667 that was allowed before, is suddenly blocked by this default deny rule.

It puzzles me why this port 113 is blocked by the deny rule, and why a connection to an ip/port combination is allowed, and then suddenly disallowed shortly after.

Edit:
I solved the irc disconnecting from port 6667 by changing the setting "Firewall Optimization" from "normal" to "conservative". After changing that setting, the connection is no longer being blocked by the "default deny rule". The block on port 113 persists, but now I start to think it may be caused by a firewall config setting as well, instead of a rule.

[Sempiterna]

I thought the problem was solved after setting "Firewall Optimization" from "normal" to "conservative", but this makes the connection disconnect after 15 minutes instead of ~1.

From the Netgate/Pfsense manual which references the optimization settings in more detail, it states that for "tcp.opening No response yet" the setting is 900s or 15 minutes. This would mean that the (initial) connection did not receive a response, eventhough I can use the connection (and get responses on screen) for those full 15 minutes.

( https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html )

Any idea if this behaviour can be controlled some more in this firewall? Or see why (if this is the case) the firewall is not receiving a response, or thinks it has not received one, for 15 minutes.