Messages

Can anyone recommend an inexpensive access point that won't add a terrible number of cords/cables to my rat's nest of wires?

At home, I am using Zyxel hardware for switches/APs, because I can easily install OpenWRT on those boxes due to their freely accessible serial port. By using OpenWRT, I don't need to get accustomed to a new user interface...  ;) I guess Zyxel's reputation is not the best, but the devices are doing a good job in my case.

As AP, I am using the Zyxel NWA 50AX.

PS: I just noticed that there are OpenWRT images available for some mikrotik devices as well.

A bit late to the show, but with regards to the discussion part on using one device as a FW/AP, I use virtualization (Xen) with PCI passthrough for this. The hardware is an APU4D4. The host (Dom0 in Xen speak) is running vanilla Debian. The WiFi card is passed through to a VM (DomU) running OpenWRT, the OPNsense firewall is running in a seperate VM. Both are connected via a software bridge.

There are drawbacks to this solution, i. e. added complexity at a single point of failure or an (theoretically?) increased security risk, but in my case, it works quite well.

Na, bei der FritzBox musste ich gar keine Zugangsdaten eintragen, da reichte es, Telekom als Provider einzutragen, dann funktionierte alles. Die Zugangsdaten konnten der Fritte nicht bekannt sein, die kam direkt von einem anderen Anschluss von 1&1. Ich habe auch schon mehrfach gelesen, dass die Telekom die Zugangsdaten nicht mehr kontrolliert, u. a. in der ct.

Edit: Hier der Link zum ct-Artikel: https://www.heise.de/select/ct/2020/2/1578238295698254

Warum es bei mir nicht klappte, weiß ich nicht. Vielleicht erwartet die Telekom zwar nicht die Daten, aber ein bestimmtes Format muss eingehalten werden?

Bei mir funktioniert PPPoE auch mit der neuesten Firmware-Version 3.8.5 (Version 7) auf der Draytek Vigor 130 am Telekom-Anschluss. VLAN-Tag wird durch OPNsense gesetzt.

Ich bin erst kürzlich von einer FritzBox 7412 wegen Synchronisationsproblemen auf eine gebrauchte Draytek Vigor 130 umgestiegen und habe erstmal die neueste Firmware inkl. Factory Reset installiert. Dann habe ich die Konfiguration vorgenommen.

Ich habe ein paar Schleifen gedreht, bis ich die richtigen Zugangsdaten in OPNsense eingetragen hatte. Eigentlich war ich davon ausgegangen, dass die Zugangsdaten der Telekom inzwischen egal sind, aber dem war dann doch nicht so, mit den korrekten Daten funktioniert seitdem alles.

Another update: Meanwhile, I'm on OPNsense 23.1.9. Also, I changed my setup and made the downstream router (OpenWRT) into an access point without any routing tasks. This means prefix delegation is not necessary anymore. I therefore can't tell if the original issue has been solved. Anyway, the nightly new IPv6 prefixes arrive at the clients much faster than before.

Sidenote: I have the impression that getting rid of the additional downstream router has made everything a bit "snappier", i. e. DNS lookups, browsing, etc. seem to be a little bit faster. Also, I'm having less complex setup with regards to routing, no double NAT, no double firewall rules etc. Many of my network devices still run OpenWRT, but without routing tasks.

Thank to the team for this nice piece of open source software!

It seems that I am having similar issue, now in 23.1.7_3 (might have been there earlier). Today, I didn't receive the IPv6 prefix in my LAN net. dhcpd6 was not running. When trying to start it manually, I got the following error message:

Code Select Expand

/usr/local/etc/rc.newwanipv6: The command '/usr/local/sbin/dhcpd -6 -user dhcpd -group dhcpd -chroot /var/dhcpd -cf /etc/dhcpdv6.conf -pf /var/run/dhcpdv6.pid xn0 xn2' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.4.3-P1 Copyright 2004-2022 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Config file: /etc/dhcpdv6.conf Database file: /var/db/dhcpd6.leases PID file: /var/run/dhcpdv6.pid Wrote 0 NA, 0 TA, 0 PD leases to lease file. Can't bind to dhcp address: Address already in use Please make sure there is no other dhcp server running and that there's no entry for dhcp or bootp in /etc/inetd.conf. Also make sure you are not running HP JetAdmin software, which includes a bootp server. If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging. exiting.'

dhcrelay6 was running. When i stopped dhcrelay6, I could start dhcpd6, and the prefix got delegated.

Just an information for the afterworld: I am on 23.1.5_4 right now. The situation regarding IPv6 prefix update seems to be stable. There is still some delay until the new prefix is delegated each night. I estimate this delay to be 1-2 hours, and that seems a little long to me. Other than that, IPv6 is working reliably.

Bei mir in einem ähnlichen Setup dauert es einige Zeit (ca. 1-2 Stunden), bis die Downstream-Geräte nach der OPNsense-Box das richtige Präfix erhalten. Wenn das Präfix sich ändert, erhalten die Downstream-Geräte noch eine Weile das deprecated-Präfix, dann funktioniert IPv6 nicht richtig. Vielleicht ist das ja bei Dir auch der Fall? Bei

Code Select Expand

ens3 steht jedenfalls bei den Global-IPv6-Adressen "deprecated"...

Siehe auch: https://forum.opnsense.org/index.php?topic=32313.0

I updated to 23.1.2 two days ago.

Today, regular disconnect (and therefore new IPv6 prefix) happened at about 4:00 A.M. IPv6 connectivity came up at about 6 A.M. Everything seemed to be working o.k. during the day.

Then another (unregular) disconnect happened at around 21:00 due to some DSL issue. After reconnect (and new IPv6 prefix), IPv6 connectivity was lost again. I checked the OPNsense system, and it showed in WAN interface and in DHCPv6 the deprecated prefix. The WAN interface itself had an IPv6 address from the new, correct range, it was just the prefix which was deprecated. After approx. one hour, I restarted the WAN interface, and IPv6 connectivity was restored. The prefix was from the correct range. I verified by manually requesting a new IPv6 prefix in the DSL router, with the exact same behavior. Default routes stay in place, no issue there.

TL;DR: It seems that upstream IPv6 prefix updates take around two hours to reach the downstream systems. This seems quite long to me. Is there a way to speed up this process?

I reverted to 22.7.11_1, prefix delegation is working again.

Things have not changed, I am rebooting OPNsense each morning to get IPv6 PD working again. Enabling "Interfaces: Settings: Prevent release" does not help.

Therefore, I am planning to revert to 22.7. Are there any specific logs and/or files I need to save to compare behavior in 22.7 and 23.1 and help finding the cause for my issue?

I am also using a Deutsche Telekom DSL line with nightly forced disconnect, and I am also having an issue with IPv6. OPNsense assigns wrong (deprecated) IPv6 prefixes for delegation to downstream routers with DHCPv6 after each disconnect. IPv6 addresses assigned directly by OPNsense seem to be fine.

My situation is different to the one described here because I am using an additional modem/router (FritzBox) for establishing the DLS connection , so I am not using the PPPoE function in OPNsense. OPNsense is connected to the LAN port of the FritzBox.

Things have been working fine until OPNsense 22.7.x, with the upgrade to 23.1, I need to reboot OPNsense each morning. (At least I didn't find another fix, simply restarting DHCPv6 doesn't help.) It seems there is some issue with detecting the IPv6 change in OPNsense 23.1 and then changing the delegated prefix.

I originally described my issue here: https://forum.opnsense.org/index.php?topic=32313.0 I am not sure if it is related to what is being discussed in this thread, but it sounds as if it could be.

I have DSL internet with forced disconnect (access is provided by a DLS modem, not via PPPoE) and get new IPv6 address and prefix after each nightly reconnect. Since an update to 23.1, I am having issues with DHCPv6 PD after a disconnect. The obsolete IPv6 prefix is somehow still delegated, whereas downstream routers get a correct IPv6 address. Downstream clients (behind the downstream router) hence don't get a correct IPv6 address and have no IPv6 connectivity.  In my logs, I can find an error, I don't know if it is related:

Code Select Expand

/usr/local/opnsense/scripts/dhcp/prefixes.php: The command '/sbin/route add -inet6 '2003:d2:2018:f4e1::/60' '2003:d2:2018:f4d1:xxxx:xxxx:xxxx:xxxx'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add net 2003:d2:2018:f4e1::/60: gateway 2003:d2:2018:f4d1:xxxx:xxxx:xxxx:xxxx fib 0: Network is unreachable'

I suspect that OPNsense somehow misses the prefix change.

Restarting the DHCPv6 service doesn't fix the issue. Rebooting OPNsense solves the issue until some unknwon time after the next disconnect.

Other reported issues which might be related:

https://forum.opnsense.org/index.php?topic=32259.0
https://forum.opnsense.org/index.php?topic=32263.0

Anything I can do to help fix this issue?

I can't confirm that at least for Debian kernel linux-image-4.19.0-20-amd64 although I am on current opnsense 22.7. The last working kernel version for me is linux-image-4.19.0-18-amd64.

I'm now at kernel 5.10.0-20-amd64 and OPNsense 22.7.11, and everything is working flawlessly. You state that you are on OPNsense 22.7. Perhaps upgrading OPNsense helps? As I've written, for me, it only started working again with later versions of OPNsense (e. g. 22.7.7).

If that doesn't help, perhaps trying a newer kernel (e. g. 5.x) is also worth a try?

Since 22.7.7 (at least that is the version where I noticed the change), this issue seems to have disappeared. I have the standard Debian Bullseye kernel 5.10.0-19-amd64 installed on Dom0, and OPNsense is running normally, all interfaces are up. No special kernel is needed anymore. Fingers crossed. :-)