I only recently discovered that IPv6 doesn't work anymore with my provider init7. My WAN address doesn't get any IP via dhcpv6. I sent them a request, but haven't heard back yet, if they changed something, which i doubt. I don't know if maybe i broke something and didn't realize it yet.
So my current idea is to move to static IP. This seems to work a bit. My clients get an IP, and i can ping the fe80::xxx address of the router. This used to work as well, but i can't ping for instance heise.de
For my configuration see the attachments.
Since you set a static address on WAN I think there will be a static address on WAN. The question is if it works. IF it doesn't work the ISP may block it. That's about it. :)
Cheers,
Franco
Do you know of a reason why i won't get an IP via DHCPv6?
Sorry, not your ISP. As far as I remember Init7 was always very open and chatty about its service. Why do you think they cannot help you?
Cheers,
Franco
Well, haven't heard back from them yet. So maybe they can help me. Was just trying to find a solution in the meantime, especially since it used to work, and now doesn't, and i've only updated my opnsense a few times, nothing else...
So i heard back from my ISP, and they say that they checked everything and from their side all should be fine (as expected). They say the router doesn't request a prefix, i.e. DHCPv6-PD (prefix delegation) is not enabled. Which option would that be. My configuration is as follows:
I've now communicated with the ISP. They say all is fine on their side and they don't see my router requesting a prefix. They said it the prefix must be /48, which i configured.
How can i check in the logs what the router is doing when fetching a prefix? I can find a lot about IPv4 DHCP, but nothing really about IPv6, except for this:
Ok if the ISP says so let's configure it that way? ;)
Prefix delegation size: 48
Request prefix only: checked
Send prefix hint: checked
Best to do a clean reboot. radvd and dhcpv6 daemons can't do much if DHCPv6 on the WAN side is still not set up correctly.
Cheers,
Franco
Hi Franco
So a reboot actually did manage to solve my issue. I get a prefix now.
Something that i don't understand is that the IPs change after a few minutes after the reboot. See my attached images:
And now suddenly the routing doesn't work anymore. Really strange
So i found something in the logs. After a boot all is fine, but then suddenly i get a disconnect and then the connection is lost, but only for ipv6, everything else works as expected:
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="24"] <118>*** OPNsense.lan: OPNsense 24.7.9_1 (amd64) ***
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="25"] <118>
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="26"] <118> GUEST (vlan0.900) -> v4: XX.XXX.XXX.1/24
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="27"] <118> IOT (vlan0.800) -> v4: XX.XXX.XXX.1/24
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="28"] <118> LAN (ix0) -> v4: XX.XXX.XXX.1/24
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="29"] <118> v6/t6: 2a02:XXXXXXXX/64
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="30"] <118> TV7 (igb0) -> v4: XX.XXX.XXX.1/24
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="31"] <118> WAN (ix1) -> v4/DHCP4: XX.XX.XX.XX/25
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="32"] <118> v6/DHCP6: 2a02:XXXXXXXX/64
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="33"] <118> WG1 (wg1) -> v4: XX.XXX.XXX.1/24
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="34"] <118>
<11>1 2024-11-26T11:46:50+01:00 OPNsense.lan flowd_aggregate.py 2561 - [meta sequenceId="35"] flowd aggregate died with message Traceback (most recent call last): File "/usr/local/opnsense/scripts/netflow/flowd_aggregate.py", line 160, in run aggregate_flowd(self.config, do_vacuum) File "/usr/local/opnsense/scripts/netflow/flowd_aggregate.py", line 80, in aggregate_flowd stream_agg_object.add(copy.copy(flow_record)) File "/usr/local/opnsense/scripts/netflow/lib/aggregates/source.py", line 117, in add super(FlowSourceAddrDetails, self).add(flow) File "/usr/local/opnsense/scripts/netflow/lib/aggregates/__init__.py", line 185, in add self._update_cur.execute(self._update_stmt, flow) sqlite3.DatabaseError: database disk image is malformed
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="36"] <118> HTTPS: sha256 XXXXXXXX
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="37"] <118> XXXXXXXX
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="38"] <118> SSH: SHA256 XXXXXXXX (ECDSA)
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="39"] <118> SSH: SHA256 XXXXXXXX (ED25519)
<13>1 2024-11-26T11:46:50+01:00 OPNsense.lan kernel - - [meta sequenceId="40"] <118> SSH: SHA256 XXXXXXXX (RSA)
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="41"] /usr/local/etc/rc.newwanipv6: plugins_configure vpn_map (,wan,lan,inet6)
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="42"] /usr/local/etc/rc.newwanipv6: plugins_configure vpn_map (execute task : ipsec_configure_do(,wan,lan))
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="43"] /usr/local/etc/rc.newwanipv6: plugins_configure vpn_map (execute task : openvpn_configure_do(,wan,lan))
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="44"] /usr/local/etc/rc.newwanipv6: plugins_configure vpn_map (execute task : wireguard_configure_do())
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="45"] /usr/local/etc/rc.newwanipv6: plugins_configure vpn (,wan)
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="46"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (,wan)
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="47"] /usr/local/etc/rc.newwanipv6: plugins_configure vpn (,lan)
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="48"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (,lan)
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="49"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (,wan,lan,inet6)
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="50"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : dhcrelay_configure_if(,wan,lan,inet6))
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="51"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : dnsmasq_configure_do())
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="52"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : igmpproxy_configure_do())
<12>1 2024-11-26T11:46:52+01:00 OPNsense.lan igmpproxy 52173 - [meta sequenceId="53"] select() failure; Errno(4): Interrupted system call
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="54"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : ntpd_configure_do())
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="55"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : opendns_configure_do())
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="56"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : openssh_configure_do(,wan,lan))
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="57"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : unbound_configure_do(,wan,lan))
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="58"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : vxlan_configure_do())
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="59"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : webgui_configure_do(,wan,lan))
<13>1 2024-11-26T11:46:52+01:00 OPNsense.lan opnsense 84713 - [meta sequenceId="60"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip_map (execute task : wireguard_sync())
<13>1 2024-11-26T11:47:20+01:00 OPNsense.lan kernel - - [meta sequenceId="62"] 040.089948 [ 852] iflib_netmap_config txr 8 rxr 8 txd 2048 rxd 2048 rbufsz 2048
<13>1 2024-11-26T11:47:20+01:00 OPNsense.lan kernel - - [meta sequenceId="63"] 040.089962 [ 852] iflib_netmap_config txr 8 rxr 8 txd 2048 rxd 2048 rbufsz 2048
<13>1 2024-11-26T11:47:20+01:00 OPNsense.lan kernel - - [meta sequenceId="64"] 040.089969 [ 852] iflib_netmap_config txr 8 rxr 8 txd 2048 rxd 2048 rbufsz 2048
<13>1 2024-11-26T11:47:20+01:00 OPNsense.lan kernel - - [meta sequenceId="65"] 040.119992 [ 852] iflib_netmap_config txr 8 rxr 8 txd 2048 rxd 2048 rbufsz 2048
<13>1 2024-11-26T11:47:20+01:00 OPNsense.lan kernel - - [meta sequenceId="66"] <6>ix1: link state changed to DOWN
<13>1 2024-11-26T11:47:21+01:00 OPNsense.lan opnsense 48091 - [meta sequenceId="67"] /usr/local/etc/rc.linkup: DEVD: Ethernet detached event for wan(ix1)
<13>1 2024-11-26T11:47:22+01:00 OPNsense.lan opnsense 48091 - [meta sequenceId="68"] /usr/local/etc/rc.linkup: plugins_configure dhcp (,inet6,[lan])
<13>1 2024-11-26T11:47:22+01:00 OPNsense.lan opnsense 48091 - [meta sequenceId="69"] /usr/local/etc/rc.linkup: plugins_configure dhcp (execute task : dhcpd_dhcp_configure(,inet6,[lan]))
<13>1 2024-11-26T11:47:23+01:00 OPNsense.lan kernel - - [meta sequenceId="70"] 042.883130 [ 852] iflib_netmap_config txr 8 rxr 8 txd 2048 rxd 2048 rbufsz 2048
<13>1 2024-11-26T11:47:23+01:00 OPNsense.lan kernel - - [meta sequenceId="71"] 042.883148 [ 852] iflib_netmap_config txr 8 rxr 8 txd 2048 rxd 2048 rbufsz 2048
<13>1 2024-11-26T11:47:23+01:00 OPNsense.lan kernel - - [meta sequenceId="72"] 042.883159 [ 852] iflib_netmap_config txr 8 rxr 8 txd 2048 rxd 2048 rbufsz 2048
<29>1 2024-11-26T11:47:23+01:00 OPNsense.lan dhcp6c 64385 - [meta sequenceId="73"] restarting
<29>1 2024-11-26T11:47:23+01:00 OPNsense.lan dhcp6c 64385 - [meta sequenceId="74"] Bypassing address release because of -n flag
<29>1 2024-11-26T11:47:23+01:00 OPNsense.lan dhcp6c 64385 - [meta sequenceId="75"] remove an address 2a02:XXXXXXXX/128 on ix1
<29>1 2024-11-26T11:47:23+01:00 OPNsense.lan dhcp6c 64385 - [meta sequenceId="76"] Bypassing address release because of -n flag
<29>1 2024-11-26T11:47:23+01:00 OPNsense.lan dhcp6c 64385 - [meta sequenceId="77"] remove an address 2a02:XXXXXXXX/64 on ix0
Ok, so i think i found the issue. After disabling suricata everything was fine. With suricata enabled, after a while i got a
<6>ix1: link state changed to DOWN
Then
dhcp6c 32939 - [meta sequenceId="94"] Sending Solicit
never got an answer. As soon as i disabled suricata again, everything was fine...
There must be some bug with suricata and ipv6.
I found this thread: https://forum.opnsense.org/index.php?topic=7666.30
It has the exact same symptoms from 2018. Has the bug been reanimated?
The bug truly was just a suricata issue. I needed to disable rule:
2030387 ET EXPLOIT Possible CVE-2020-11899 Multicast out-of-bound read
this rule blocked my ipv6 dhcp packages it seems.
Maybe don't run Suricata on WAN?
When I tried it a couple of years ago I limited it strictly to the interfaces connecting publicly reachable servers.
I was under the impression an intrusion detection on WAN makes the most sense. I guess i am wrong here? Shouldn't packets be blocked as early as possible? But sure, LAN also sends packets which can be defined as bad and thus need to be blocked.
I´m facing the same problem. I was running IPv6 for over one year with any problem. Yesterday, after a reboot (without any config change, last update was a week ago without any reboot), IPv6 is not working anymore. My CheckMK is read on IPv6-Checks. After reboot IPv6 is working for some minutes and then it´s not working anymore.
Fun fact: I don´t have suricata activated. In which log did you find the problem?
I see IPv6 is assigned on the interfaces correctly. Even on my clients, I see the correct IPv6, but it doesn´t get through. Browsing wieistmeineip.de only gives me back my IPv4.
Any idea what it could be?
Oh my... well i don't know what i should say... All my ideas on what could be the issue were negated in the end. Perhaps you can view the diffs/changes of your configs and find something that did change? Are you using a different ISP? I think i also once had the wrong prefix configured, which certainly also caused issues.
To link the issues together:
https://github.com/opnsense/core/issues/8091
https://github.com/opnsense/core/issues/8091#issuecomment-2500992558
Regarding running suricata on WAN, that is not best practice.
If there is a NAT happening, Suricata is better suited on interfaces after the NAT.
Ok, thanks for the information. I've put suricata on the LAN and VLAN interfaces
And don't forget to adjust HOME_NET in advanced Suricata settings if you have a different "privat" range.
Cheers,
Franco
Hey,
I only use one ISP and have the issue, even if suricata is not enabled:
Quote from: franco on November 28, 2024, 11:14:36 AM
And don't forget to adjust HOME_NET in advanced Suricata settings if you have a different "privat" range.
Right, but what about IPv6?
Even if suricata is not enabled on my firewall, I had to change the interface from WAN to something different and after a reboot the problem went away and IPv6 is working. This is strage behaviour, because when a plugin is not activated it should not pay attention to its settings.
Quote from: eitch on November 28, 2024, 12:57:21 PM
Quote from: franco on November 28, 2024, 11:14:36 AM
And don't forget to adjust HOME_NET in advanced Suricata settings if you have a different "privat" range.
Right, but what about IPv6?
Good question. As far as I know HOME_NET only has IPv4 default ranges and I don't know how IPv6 is supposed to be handled here.
Cheers,
Franco
Quote from: groove21 on November 29, 2024, 09:22:35 AM
Even if suricata is not enabled on my firewall, I had to change the interface from WAN to something different and after a reboot the problem went away and IPv6 is working. This is strage behaviour, because when a plugin is not activated it should not pay attention to its settings.
I think to start with you should not be cross-posting issues that you already know are not relevant here because when the service isn't used it can't be the same problem?
Cheers,
Franco
I think "Home networks" is only important if there is some sort of NAT involved.
E.g., if you would do NAT66 from GUA to ULA, you would put your ULAs there too. But for GUAs its not important since nothing gets translated.
Quote from: Monviech (Cedrik) on November 28, 2024, 09:46:48 AM
Regarding running suricata on WAN, that is not best practice.
If there is a NAT happening, Suricata is better suited on interfaces after the NAT.
While I get that running Suricata on WAN is not best practice, how is it supposed to find any intrusions happening on the firewall itself? In that case, there would only be traffic directed outside. On the other interfaces, suricata could only see malicious internal agents.
I wonder the exact same thing
This begs the question how such an intrusion would look like. Since the suricata ruleset is open source, the ruleset can be avoided by bad actors because they are not dumb either.
If you get targeted by more than bots you need other mechanisms like syslogs and you have to spend time to look at the evaluation of these logs each day.
Its not like turning on IDS/IPS is a switch on and forget thing. Its just a filter with very big holes to sift out some more common attacks. But not any targeted attacks that want to actually harm you and have effort and money involved.
It makes sense what you say.
Do not get me wrong, I do not believe in IDS anyway and do not use it. Most of the time, when I tried to use anything like it, I found myself in having to configure it in very much detail.
That is, unless I just enabled all potential rules, accepting to have way too many false positives and thereby causing outages. Not a good alternative, either.