Messages

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.

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.

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 Expand

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 Expand

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.

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 Expand

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.

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.