[SOLVED] All IPv6 traffic "Default deny / state violation rule"

[Formikachu]

I am new to OPNSense and I'm encountering a problem with IPv6. I have found a few different threads and a github issue describing the problem, but no resolution. I am using OPNSense 24.7.

The problem is that IPv6 traffic that originates on the LAN interface gets blocked by the default rule "Default deny / state violation rule" and does not traverse to the WAN interface. IPv6 traffic that originates on the WAN interface - for example, a ping test - works fine. These circumstances are consistent while watching the Live View of the Firewall logs.

I have made no changes to the default rules in any way. The system is configured to use 172.16.1.0/24 as its IP scheme, and I am using a local DNS on 172.16.1.5 (a pi hole).

IPv4 traffic works fine. IPv6 traffic works fine locally, i.e. over my (very simple) LAN. IPv6 is "Allowed" in the OPNSense settings - if I uncheck that box, the logs change to reflect this.

I found this github issue: https://github.com/opnsense/core/issues/6435 which describes my problem. But there does not appear to be a resolution. Based on this issue I tried using OPNSense 22.7 to see if that would make a difference; it did not.

It feels as though there's some kind of change to the order of the rules I need to make, but I am at the edge of my knowledge with regards to this issue, and I am concerned that one bad choice will open my firewall to the outside world.

I apologize for my ignorance, and hope that someone is able to shed some light on this subject. If you would like additional diagnostic information, please let me know.

[dseven]

Are you getting a delegated prefix from your ISP?

How is your LAN interface configured for IPv6? Tracking WAN? Static? ...

When the traffic is blocked, does it have an internet routable source address from your delegated prefix?

Is the "Default allow LAN IPv6 to any rule" for your LAN interface in place and enabled?

[Formikachu]

Thank you for your reply. Answers:

Are you getting a delegated prefix from your ISP? Yes, a /64. I can perform IPv6 operations (the ping tests) from the WAN interface just fine.

How is your LAN interface configured for IPv6? Tracking WAN? Static? ... I left it set to the default, "Track Interface". I've tried SLAAC too, to no effect.

When the traffic is blocked, does it have an internet routable source address from your delegated prefix? I am unsure how to answer this question. The source addresses are generally IPv6 Private IPs, e.g. starting with 2600:1700:a412. For example, here is a ping from my workstation to microsoft.com:

Code: [Select]

lan 2024-11-19T17:21:18-08:00 2600:1700:a412:8020:d8bf:324d:xxxx:xxxx 2603:1030:b:3::152 ipv6-icmp Default deny / state violation rule
Traffic that originates on the WAN adapter does have a public IPv6 address.

Should OPNSense be assigning a public IPv6 IP to my workstation in this context? My understanding of IPv6 is limited, so I apologize if this is a dumb question.

Is the "Default allow LAN IPv6 to any rule" for your LAN interface in place and enabled? Yes. It is at the bottom of the stack of auto-generated rules, along with the IPv4 rule that does the same thing.

Thank you again for your reply, I really appreciate it.

[kryptonian]

Should OPNSense be assigning a public IPv6 IP to my workstation in this context? My understanding of IPv6 is limited, so I apologize if this is a dumb question.

That depends on if you have configured router advertisements, but if you only really get a single /64, then you might need to enable DHCPv6.

[dseven]

Being able to ping from the WAN interface doesn't mean that you have a delegated prefix - it just means that your WAN interface has a routable IPv6 address. For LAN hosts to work (without NAT) requires a delegated prefix that your router (OPNsense) can use for your LAN(s). It'd generally be larger than /64, but maybe not always. Take a look at Interfaces -> Overview, click on the magnifier next to your WAN interface, and look for "Dynamic IPv6 prefix received". By having your LAN interface track your WAN interface, it should be able to use the delegated prefix, and it sounds like that's actually working for you (as you appear to have a routable address on your LAN client).

So why is the traffic getting blocked? Something that makes me slightly suspicious is that "lan" is in lower case in the log that you pasted, where I believe that the default is upper-case "LAN". Did you create/assign an additional "lan" interface??

[Formikachu]

Thank you for continuing to help me!

click on the magnifier next to your WAN interface, and look for "Dynamic IPv6 prefix received". Ah-ha. This might be part of the problem, I apologize; I was wrong about the prefix size.

Code: [Select]

Dynamic IPv6 prefix received 2001:5a8:xxxx:xxx::/56
I also show that prefix assigned to the LAN interface under "Routes" on the same screen. What's weird is I don't remember seeing this before, but maybe this is all a prefix mismatch.

I changed my Prefix delegation size to 56 on the WAN interface, restarted OPNSense, and now my workstation is getting an address in that 2001 scope. That's progress. But I still can't ping external IPv6 addresses from my workstation - and they continue to show a 2600 address as their origin in the logs:

Code: [Select]

2024-11-20T10:14:08-08:00 2600:1700:a412:8020:d8bf:324d:zzzz:zzzz 2603:1030:c02:8::14 ipv6-icmp Default deny / state violation rule
I can ping the 2001 address assigned to the WAN adapter from my workstation. It does not show up in the Live Log View.

Did you create/assign an additional "lan" interface?? I don't believe so. The only two interfaces I created were during initial (command line) setup, LAN and WAN. The identifier is "lan" in the Interfaces > [LAN] screen.

[dseven]

Your clients may be still using the prefix that was advertised before - see if you can reset them somehow - maybe disable/enable the network interface, unplug/replug cable, etc.....

[Formikachu]

Your clients may be still using the prefix that was advertised before - see if you can reset them somehow - maybe disable/enable the network interface, unplug/replug cable, etc.....

I gave that a shot, no luck. Everything points to the logs being correct - a firewall rule is blocking the traffic - and it appears to be those 2600 addresses. I thought those 2600 addresses were local private IPv6 addresses. They are not; those are the old AT&T addresses, and they're clearly screwing things up. I'm going to investigate getting rid of those, if you have any other ideas, please let me know.

I donated to the OPNsense project as a thank you for your help, dseven.

[Captain Awesome]

Is the "Default allow LAN IPv6 to any rule" for your LAN interface in place and enabled? Yes. It is at the bottom of the stack of auto-generated rules, along with the IPv4 rule that does the same thing.

Check the setting at the bottom of Interfaces -> Settings regarding the "Allow IPv6" checkbox too

[Formikachu]

I figured it out. Perhaps this will help someone in the future.

My DD-WRT wifi access point was, somehow, caching the old 2600 addresses from AT&T and handing them out. I have no DHCP or other services configured on the AP; just solely handles wireless duties. But I could delete the addresses in netsh on Windows, and they'd pop right back up every time.

I have no idea how or why, but as soon as I unplugged that device for a bit, the 2600 addresses vanished and IPv6 works across the board. Nor did they return when I powered the AP back up.

I also fundamentally didn't understand IPv6 number assignments, thinking those 2600 addresses were "private" like 192.168, etc. They are "private" in that they were part of the prefix handed out by AT&T's CPE for local subnets, but are still assigned IP spaces. So when I saw them showing up in the OPNsense logs, I didn't realize what the problem really was (that it was correctly blocking IP addresses it was not responsible for).

So there were two problems: I was not assigning the correct prefix (/56), which dseven showed me how to find; and I had a rogue device doing Bad Things on my network.

Thank you everyone who chimed in. It works!!! And I'm getting the 10 gig speeds I'm paying for, thanks to OPNsense.