Messages

Today when upgrading to 21.7 to 21.7.1, I noticed that some of the plugins I had previously installed did have a mention "misconfigured" next to them.

This was happening for
* os-acme-client
* os-dmidecode
* os-dnscrypt-proxy
* os-dyndns

I removed each of them and reinstalled them. Just for people reading this afterwards after a search on a search engine, I didn't have to respecify the configuration, so **it seems** removing and reinstalling them do keep their configuration. This would have been annoying if I had to (esp. for DynDNS on Cloudflare and the LetsEncrypt conf).

Now the "misconfigured" mention is just replaced by "installed" and everything goes fine.

For those of you finding this topic via a search engine, please note I faced this same issue in 2021 with only Firefox. Made a bug report on the plugins repo: https://github.com/opnsense/plugins/issues/2367

Hi there,

I'm debugging the inability for my backup WAN2 (xDSL based) to be used. WAN1 is the default gateway for both IPv4 and IPv6.

Pinging or using curl against the src WAN2 address PPPoE address is now reporting 'no route found' (timing out with curl). The problem appeared with some dot releases from 20.7, but I haven't noticed which one.

Code Select Expand

curl -6 --interface 2a02:a03f:afe7:xxxxxxxxxxxxxxx -k -L -g '[2a00:1450:400e:80d::200e]'

I'm investigating what recent OPNsense changes could have caused this, but I have to admit I'm struggling finding the culprit as changing the default route to WAN2 is still giving the same issue (a far gateway issue?) :/

Does anyone could help me narrowing down the issue?

Trying again, if someone has an idea ;)

My DOCSIS VOO provider is struggling to establish a TCP handshake with SSH connections tried over IPv4 (IPv6 based connections are working fine). This only happens with their latest modem (Technicolor CGA 4233). The culprit is likely a MAC Domain issue on the CMTS I'm connected to.

To avoid this, I want to reroute automatically SSH traffic. Do you know how to do that with OPNsense without having to manually specify a src or dst address (which is a cumbersome process).

Hi there,

I have two WANs. My main connection (WAN1) is using a DOCSIS modem cable which is running into issue with some SSH connections. Because of that, I need to redirect the outgoing SSH traffic to WAN2.

Up to now, I was specifying manually the IPv4 and IPv6 destination addresses in System > Routes > Configuration for each SSH service concerned by the issue.

* Do we have a way to ask OPNsense to route all the SSH based outgoing traffic to WAN2 instead of WAN1?
* If this is not possible easily, do we have a way to route based on a DNS instead of having to specify the IPv4 and IPv6 addresses manually (addresses which change after some time depending on the anycast network I'm in - geolocalized content delivered via variable CDN like GitHub).

Are you seeing the requests being sent in the log?
[...]

Nope. I'm not. As if the link wasn't ready to receive RA paquets when dhcp6c is being launched. This really sounds like a race condition.

From my side, I'm not aware of any BNG issues (and the need to wait to request IPs again) like you described with both of my ISPs, so I don't think this comes from this point. Actually my ISP are still quite open in the sense I could request several IPv4 or IPv6 prefixes and they are not complaining.

[ข่าวกีฬาออนไลน์]

Btw, since I'm still figuring out how the fallback method is working
I wonder how LAN devices tracking the IPv6 PD address range prefix from WAN1
(Global Unicast IPv6 address i.e. 2a02::/8) ข่าวกีฬาออนไลน์
will fallback to WAN2 (the backup WAN) when WAN1 is down.

@Zlapped24 They won't. The gateway won't be magically changing and devices won't be getting the new IPv6 address.

The current patch described in this thread was only the first step: supporting a merged dhcpv6 client config with different interfaces. That's only what the fixes (implemented in 20.7) are doing for now.

Gateway changing and IPv6 address changing will still need to be implemented.

[...]

I then debugged the issue directly on my laptop. I contacted the core network team of my ISP. It appeared this was indeed a problem on their side. Problem fixed =)

[...]

Actually nothing is 100 % correct when I said this was 100% working. After a reboot, I have a race condition and the IPv6 doesn't immediately show up on the xDSL link. I need to manually go in Interfaces > Overview and Reload the xDSL link in order to have an IPv6 address. Any idea to avoid this manual step at each reboot?

Happy to hear :)

MTU should be advertised as 1280, not sure where 516 is coming from. Or is the OPNsense itself violating the MTU constraint?


Cheers,
Franco

I think this is indeed OPNsense (or at least the FreeBSD driver) violating this MTU constraint because the issue doesn't happen with OpenWRT on that same device.

How do you know this should be 1280? It was indeed the value that was sometimes displayed as ifconfig output when 516 wasn't.

Is 1280 the default value for Ethernet reported by DOSCIS cable modems? On my Ethernet link from my xDSL modem, the MTU was 1500.

Back. I have retested my APU2 board on OpenWRT and the problem was similar.

I then debugged the issue directly on my laptop. I contacted the core network team of my ISP. It appeared this was indeed a problem on their side. Problem fixed =)

I confirm that with the 20.7 release (not in dev mode any more) that dhcp6c is working for both of my connections (DOCSIS and xDSL PPPoE).

Retested again with my trick:

Code Select Expand


$ curl -6 --interface 2a02:[IPv6 address of the PPPoE] -k -L google.com
[...]
$ curl -6 --interface 2a02:[IPv6 address of the DOCIS modem bridge] -k -L google.com
[...]


and both replied correctly.

Enforcing the MTU override for the DOCSIS based connection at VOO (Belgium) is still required though otherwise OPNsense was still setting the MTU to 516 that breaks the IPv6 minimum requirements.

Well, it's true that up to now I have been spoofing the MACs from my WANs, but it has always worked like this before since I have this APU2 (end of 2017).

I have just unset the spoofing, rebooted. Even if the NIC is now using the real HW MAC address, I still don't get any IPv6 DHCP answer.

Also, for the record, previously in the 20.7.x dev config I had, the "prevent release" DHCPv6 setting was set. I unset it as well without much results :/

How can I see if this could come from a pending existing DHCPv6 lease that hasn't expired?

I have reinstalled my system under a fresh 20.7 in order to avoid issues caused from the previous development tests I performed.

Now, I'm unable to get an IPv6 address on igb1 (modem cable based).

While radvdump reports RA paquets asking me to send an IPv6 sollicit DHCP client request (cf. M flag set to on):

Code Select Expand


interface igb1
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag on;
        AdvOtherConfigFlag on;
        AdvReachableTime 3600000;
        AdvRetransTimer 0;
        AdvCurHopLimit 64;
        AdvDefaultLifetime 9000;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvSourceLLAddress on;
        AdvLinkMTU 1500;
}; # End of interface definition


The DHCP request is not getting an offer:

Code Select Expand


2020-08-11T15:07:19 dhcp6c[36699]: reset a timer on igb1, state=SOLICIT, timeo=5, retrans=35350
2020-08-11T15:07:19 dhcp6c[36699]: send solicit to ff02::1:2%igb1
2020-08-11T15:07:19 dhcp6c[36699]: set IA_PD
2020-08-11T15:07:19 dhcp6c[36699]: set IA_PD prefix
2020-08-11T15:07:19 dhcp6c[36699]: set option request (len 4)
2020-08-11T15:07:19 dhcp6c[36699]: set elapsed time (len 2)
2020-08-11T15:07:19 dhcp6c[36699]: set identity association
2020-08-11T15:07:19 dhcp6c[36699]: set client ID (len 14)
2020-08-11T15:07:19 dhcp6c[36699]: Sending Solicit
2020-08-11T15:07:01 dhcp6c[36699]: reset a timer on igb1, state=SOLICIT, timeo=4, retrans=17047
2020-08-11T15:07:01 dhcp6c[36699]: send solicit to ff02::1:2%igb1
2020-08-11T15:07:01 dhcp6c[36699]: set IA_PD
2020-08-11T15:07:01 dhcp6c[36699]: set IA_PD prefix
2020-08-11T15:07:01 dhcp6c[36699]: set option request (len 4)
2020-08-11T15:07:01 dhcp6c[36699]: set elapsed time (len 2)
2020-08-11T15:07:01 dhcp6c[36699]: set identity association
2020-08-11T15:07:01 dhcp6c[36699]: set client ID (len 14)
2020-08-11T15:07:01 dhcp6c[36699]: Sending Solicit
2020-08-11T15:06:53 dhcp6c[36699]: reset a timer on igb1, state=SOLICIT, timeo=3, retrans=8494


The stripped down version of dhcp6c.conf:

Code Select Expand


root@portal:/home/wget # cat /var/etc/dhcp6c.conf
interface igb1 {
  send ia-na 2; # request stateful address
  send ia-pd 2; # request prefix delegation
  request domain-name-servers;
  request domain-name;
  script "/var/etc/dhcp6c_opt1_script.sh"; # we'd like some nameservers please
};
id-assoc na 2 { };
id-assoc pd 2 {
  prefix ::/64 infinity;
};


This time I ensured the MTU + MSS were correct, so I don't think this comes from this side. Any direction would be great to have.

I found the culprit :) Not related to Sensei at all. And I completely removed Sensei to make sure =)

Firefox and a bunch of other browsers have removed support for TLS 1.0 and 1.1. It appears the subdomain[1] ipv6-test.com is using to test for ICMPv6 reachability is only using TLS up to 1.1 which means the resource is not being loaded.

I'll reach I sent an email to ipv6-test's maintainers to let them know about the issue.

[1] https://v6.ipv6-test.com:8443/

Do you still need testers? I happen to have 3 ISPs and an extra APU2, I could test w/o killing my own internet via an extra cable and dsl, both that do dhcpv6 pd.

Hi there.

An additional test would be wise to have.

From my side, my xDSL and DOCIS based are both receiving an IPv6 address now.

But it appears the xDSL has issues and I need to reload the interface manually afterwards in order to be sure to have an IPv6 on it. Could you test this out? (confirming or disconfirm my issue)

For those falling on this thread using a search engine, the fact that you are not on HardenedBSD 12 and are still on HardenedBSD 11 (FreeBSD 11 based) when you try to upgrade from 20.1 to a dev version of 20.7 is intended.

Like specified on Twitter, due to early showstoppers in the 11.2 -> 12.1 upgrade process, the devs missed the deadline when they froze the code base.

According to that same tweet, the ability to upgrade to a HardenedBSD 12 kernel will be offered with the next RC expected this week or the next ones.