Messages

Hi franco,

nope it does - i am running two identical hardwares, one with 17.7.7_1 and one with 17.7.8.. This is seen only on the 17.7.8 engine.

Br br

Hi there,

after upgrading to 17.7.8, ipv6 gateway monitoring is not working after reboot anymore. apinger.conf does not contain any target ... entry for the ipv6 gateway, only vor ipv4.

Simply restarting apinger does not help in my case.

Fix has been by going into system->gateways->all, then go into the config page for the ipv6 gateway and press Save. Then restart apinger and the target .... entry is in apinger.conf again. however, it is wrong one address (Link local WAN interface not Link Local WAN gateway).

With the next automatic restart, it went back to the correct values again

I can reproduce this when rebooting

Br br

Hi there,

I am running a configuration like

FritzBox<-->opnsense (dmz interface) <--> web server with dyndns.

The web server acts as a public subdomain (sub.example.com)  and shall now get an ssl certificate via letsencrypt. As I have a dual stack running, Dyndns takes the ipv6 address of the Fritzbox as the ipv6 subdomain address. So far so good.

Due to the fact that Dyndns now offers ipv4 AND ipv6 a  DNS AAAA record iss created for the domain and therefore lets encrypts certbot is using ipv6 for certificate installation and renewal; obviously fallback to ipv4 is still not working in case that there is no answer from the server from ipv6. Currently certbot is failing as it does not reach the servers directory via ipv6

As with public ipv6 addresses NAT is no longer the valid method, how do I tell opnsense, that it should 'forward' the Fritzbox ipv6 address to the (public ?) ipv6 address of the webserver?

Looking forward to your reply

Br br

[EDIT] For those who are interested: The workaround is to configure the dyndns client on the FritzBox to update ipv4 only; this eliminates the AAAA record in DNS and letsencrypt is using Ipv4. To do so (here for dyn.com) Goto the Fritzbox in Internet->Freigaben->Dyndns and select user defined;  then put the following URL in the field:
https://members.dyndns.org/nic/update?hostname<DOMAIN>&myip<ipaddr>&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
Click apply and then wait for 5 min; the AAAA record has been disappeared; certbot renew then runs fine ....

Hi all,

there is a two year long running thread in pfsense wrt to the X11SBA-LN4F Mainboard

https://forum.pfsense.org/index.php?topic=98230.0.

There also some backgrounds are described (see inputs from user 'engineer')

I have been affected too from this and saw precisely the same issue:
(see also here: https://forum.opnsense.org/index.php?topic=5063.0)

after a few weeks of stable operations, I got a watchdog timer reset on at least one NIC (most WAN) and then the entire machine crashed. No debug output, if there were luck, SOMETIMES an watchdog reset message has been thrown to console (only visible in debug mode)

I RMA the board to Supermicro (which was HW Rev. 1.1) and got a new one with HW Rev. 1.2 and a BIOS Update to 1.0c.

Since then, the entire machine is absolutely stable, I have an uptime of 180 days by now and no crash since then at all.

I bought meanwhile a second board, same revision, same BIOS and made the same experience ....

So a check could be worthwhile (if you have this board running what I assume from your description (tbc)) which HW version you have and which Bios Version. Perhaps an RMA/update might also be helpful for you

Br br

Super, thats great!

No further error also on my productive environment, stable gw monitoring and static routes to DNS;

Br br

 :)

I let it run in my productive environment up to then and let you know if something particular happens too

BR Br

Thanks Franco,

as from my perspective this change is a very basic enabler to all users who are working with ipv6 in conjunction with dual stack providers and a standard router/modem like fritzbox et al towards the ISPs the sooner the better ....
if not that some new findings leave some doubt that this code has the required stability ...

BR C

Hi there,

17.7.4 updates also unbound to new version 1.6.6. However, unbound is not restarted after the update so that still 1.6.5 is running - is this by intention?

Br br

... one question - the code is not contained in 17.7.4?

Br br

Hi Franco,

As easy as that - so far no further error!

And even more - so far the first Sense ever which does now supporting fill ipv6 across four networks at least for my current (pretty straight) config at a dual stack ISP

Br br

Hi Franco,

Hm .... DNS still does not work

could it be that line 905 which is

Code Select Expand


if (is_linklocal($gw['gateway']) && !strstr($gw['gateway'], '%') === false) {



should look like either

Code Select Expand


if (is_linklocal($gw['gateway']) && !strstr($gw['gateway'], '%')) {


OR

Code Select Expand


if (is_linklocal($gw['gateway']) && strpos($gw['gateway'], '%') === false) {

?

BR br

Thanks Franco,

have now installed both patches, will report whether they solve the issue ....

Br br

Thanks Franco,

This is exactely what I tried to say:

Monitor and DNS both are calling /sbin/route out of system_host_route() and if your ipv6 gateway is link local and does not contain a %$interface after the LL address, then the command ends in an error message; but indeed monitor and DNS both serving different purposes :)

Beyond of that I don't use explicit static routes. My understanding is that configured DNS servers are added to the routing table statically when the system is started !?

I also suggested - instead of my really somewhat odd hack  ::) -  to code it on the callers side - appreciated; Never the less my dirty hack show that adding the %$interface thing solves the problem ....

Apologies if I have expressed myself too complicated ....

Br br

Hi Franco,

apologies I was not sure whether it is really related as the same error message is also appearing for the route to the ipv6 DNS service

Code Select Expand


Sep 24 12:17:49 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: IP renewal is starting on 'igb1'
Sep 24 12:17:49 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: On (IP address: fe80::217:3fff:XXXX:XXXX) (interface: WAN[wan]) (real interface: igb1).
Sep 24 12:17:53 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/route add -host -'inet6' '2001:470:20::2' 'fe80::3631:c4ff:XXXX:XXXX'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add host 2001:470:20::2: gateway fe80::3631:c4ff:XXXX:XXXX fib 0: Network is unreachable'
Sep 24 12:17:53 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 192.168.X.X
Sep 24 11:42:57 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: The command '/sbin/route add -host -'inet6' '2001:470:20::2' 'fe80::3631:c4ff:XXXX:XXXX'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add host 2001:470:20::2: gateway fe80::3631:c4ff:XXXX:XXXX fib 0: Network is unreachable'sr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::3631:c4ff:XXXX:XXXX

The problem is obviously somewhat broader: function system_host_route() is also called to make the static routes for the DNS service in system.inc, 224ff; it this was the reason

• That I opened up a new topic  :D
• that I extended the function directly ;)

When I understand your patch correctly, then you address the problem with the monitor, the DNS problem will not benefit from it. Still therefore the suggestion to patch it like handing over a $interface parameter to system_host_route(); then you can also use the 'right one' and not as dirty as I did ....

Just my 10 cents ....

Br br

After some more analysis work, it seems to be related to https://forum.opnsense.org/index.php?topic=6028.0)

It affects the function system_host_route in /usr/local/etc/inc/system.inc which is called for the routes to DNS servers and monitors.

Code Select Expand


function system_host_route($host, $gateway, $delete = true, $add = true)
{
    if (is_ipaddrv4($gateway)) {
        $family = 'inet';
    } elseif (is_ipaddrv6($gateway)) {
        $family = 'inet6';
    } else {
        return;
    }

    if ($delete) {
        mwexecf('/sbin/route delete -host -%s %s', array($family, $host), true);
    }

    if ($add) {
-->        /* Added by bringha for ipv6   */
-->        if ($family == "inet6" && (is_linklocal($gateway))) {
-->            $interface = get_real_interface("wan");
-->            $gateway .= "%{$interface}";
-->        }
        mwexecf('/sbin/route add -host -%s %s %s', array($family, $host, $gateway));
    }
}



I added the lines ---> for my workaround to get access to the ipv6 dns servers  I have configured (otherwise the route is not added) and the monitor (for the latter the error message is related to).

This might not be the best code. I would think that it is better to add the parameter $interface to the function when called. Then it is consistent to e.g. all the other routing functions again (e.g. system_default_route($gateway, $interface = null, $delete = true, $add = true)). The callers need to be adapted then in system.inc and in gwlb.inc accordingly.

Anyway, with this patch, the log file looks much better

Code Select Expand


Sep 24 20:23:37 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: IP renewal is starting on 'igb1'
Sep 24 20:23:37 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: On (IP address: fe80::217:3fff:XXXX:XXXX) (interface: WAN[wan]) (real interface: igb1).
Sep 24 20:23:42 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv4 default route to 192.168.X.X
Sep 24 20:23:42 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: ROUTING: setting IPv6 default route to fe80::3631:c4ff:XXXX:XXXX
Sep 24 20:23:42 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: Removing static route for monitor fe80::3631:c4ff:XXXX:XXXX%igb1 via fe80::3631:c4ff:XXXX:XXXX
Sep 24 20:23:42 OPNsense opnsense: /usr/local/etc/rc.newwanipv6: Adding static route for monitor fe80::3631:c4ff:XXXX:XXXX%igb1 via fe80::3631:c4ff:XXXX:XXXX


Br br