Messages

I think it's a hostwatch issue. I disabled the service completely, restartet the ONT once more and then tried a few restarts of the opnsense appliance. So far, PPPoE works as expected and gets an address after reboot. I'll keep it disabled for now.

Is this something that should be mentioned on the bugtracker etc.?

Yeah, I tried to disable/enable the WAN interface but that didn't do the trick. Rebooting again doesn't work either. It's stuck until I restart the ONT. But like I said, this wasn't an issue with 25.7 and isn't an issue with Mikrotik RouterOS on this device.

At first I thought it has something to do with hostwatch because it started with the newer hostwatch versions but that doesn't really make sense because disabling neighbour discovery doesn't do the trick once wan is stuck.

I'm a bit out of options here.

Yes, "os-realtek-re" is used, but this wasn't an issue with the 25.7 series. I had it running with 25.7 for months without issues. I can't get my head around it why it is needed to reboot the ONT to get everything back up and running. :(

Is there anything else I can do to help debug this?

I've got some issues with my PPPoE-Setup with the 26.1 series. Afair, this wasn't an issue with the RCs but started with the final 26.1 and is still present with 26.1.1. I'm not entirely sure what I'm looking at or how to debug this.

I use PPPoE with VLAN 7 on a fibre connection provided by Deutsche Glasfaser but with 1&1 as the ISP. Everytime I reboot my appliance it doesn't come up with an ip address on the wan interface. I have to restart the ONT to get it working again.

Log is attached but I don't see anything really unusual at first sight.

Does this mean the existing ISC-DHCP configurations for IPv4 and IPv6 will be "imported" into the plugin, so I won't need to do any configuration changes?

Yes, exactly.

As I'm remaining on ISC-DHCP, will I need to make any changes to "Track interface" as I'll need ISC-DHCPv6 and Radvd to autostart.

As I understand it, you don't need to change anything manually. The "Track Interface" option is still there (marked as "legacy" thoguh), and works as expected.

Würde die Anleitung für TV7 nicht auch auf MagentaTV zutreffen? Ich hab's selbst noch nicht getestet...

https://forum.opnsense.org/index.php?topic=17865.msg81028#msg81028

That is one of the many reasons we canceled all our landline telephony contracts with Telekom. Internet connection, great, this works just fine and stable as expected. But after the shutdown of ISDN we decided to switch our telephony away from Telekom. So far, we don't regret the decision at all.

I'm still convinced that Telekom isn't able to provide VoIP 100% standard compliant to its customers... Or they make it at least really complicated to use ones own hardware. I've gained experience with Sipgate, Easybell, Telekom, 1&1, QSC over the years and none of the others was as complicated or error-prone as Telekom.

This doesn't help you at all but maybe you should think about changing your telephony provider in the future.

I'm not sure how to achieve this without any known DNS entries from Telekom. But you are a business customer, shouldn't they tell you which DNS servers to use? I'm pretty sure that we received a list of at least three nameservers for our CompanyConnect line at work. Have you asked Telekom business support about that? Maybe "Telekom hilft!" social media team can get you the information that is needed in this case...

Other than that I'm a bit at a loss now.

If I'm correct you are a Telekom Deutschland customer? If that's the case you don't need their DNS servers (or do you use SIP-Trunk etc.?) at all. I'm currently using a SVDSL connection from Telekom and I've configured the Cloudflare DNS servers as the only DNS without provider override.

IIRC all you need is to configure your VoIP settings with a real username and a password. I think it's called "MyLogin" in the Telekom customer center.

€dit: You have to disable the automatic login for your VDSL connection, but I think that's the case already. What device do you use as modem for the VDSL connection?

After disabling the automatic login, you can't use "anonymous@t-online.de" for VoIP anymore. You have to specify your login credentials in your VoIP device and you are good to go. I'll take a look at my configuration when I'm back home.

Bottom line is, I can't think of a scenario where Telekom DNS servers are manadtory for VoIP...

At least I can confirm this behavior, even if I don't have a solution. My workaround for now is IPv6 via Tunnelbroker from Hurricane Electric. This works just fine. I can recommend this if you are in desperate need for an IPv6 connection. :)

Du könntest dir die Implementierung von Softether anschauen, die spricht viele Protokolle: https://www.softether.org/

Oder testweise mal den VPN-Client von Securepoint probieren, der basiert aber zu Teilen auch auf OpenVPN: https://www.securepoint.de/produkte/utm-firewalls/vpn-client.html

So bug is acknowledged but will be fixed at a later date?

Since the Upgrade to 18.1 I've got a strange issue with my openvpn server configuration. The GUI has issues to connect to the daemon, see screenshot and logfile

Code Select Expand

Feb 10 10:27:59 OPNsense openvpn[25551]: OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jan 22 2018
Feb 10 10:27:59 OPNsense openvpn[25551]: library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
Feb 10 10:27:59 OPNsense openvpn[26175]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock
Feb 10 10:27:59 OPNsense openvpn[26175]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Feb 10 10:27:59 OPNsense openvpn[26175]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 10 10:27:59 OPNsense openvpn[26175]: Diffie-Hellman initialized with 2048 bit key
Feb 10 10:27:59 OPNsense openvpn[26175]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Feb 10 10:27:59 OPNsense openvpn[26175]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Feb 10 10:27:59 OPNsense openvpn[26175]: ROUTE_GATEWAY x.y.z/255.255.255.255 IFACE=pppoe0 HWADDR=00:00:00:00:00:00
Feb 10 10:27:59 OPNsense openvpn[26175]: TUN/TAP device ovpns1 exists previously, keep at program end
Feb 10 10:27:59 OPNsense openvpn[26175]: Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16)
Feb 10 10:27:59 OPNsense openvpn[26175]: Exiting due to fatal error
Feb 10 10:29:25 OPNsense openvpn[79034]: OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jan 22 2018
Feb 10 10:29:25 OPNsense openvpn[79034]: library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
Feb 10 10:29:25 OPNsense openvpn[79210]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock
Feb 10 10:29:25 OPNsense openvpn[79210]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Feb 10 10:29:25 OPNsense openvpn[79210]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 10 10:29:25 OPNsense openvpn[79210]: Diffie-Hellman initialized with 2048 bit key
Feb 10 10:29:25 OPNsense openvpn[79210]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Feb 10 10:29:25 OPNsense openvpn[79210]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Feb 10 10:29:25 OPNsense openvpn[79210]: ROUTE_GATEWAY x.y.z/255.255.255.255 IFACE=pppoe0 HWADDR=00:00:00:00:00:00
Feb 10 10:29:25 OPNsense openvpn[79210]: TUN/TAP device ovpns1 exists previously, keep at program end
Feb 10 10:29:25 OPNsense openvpn[79210]: Cannot open TUN/TAP dev /dev/tun1: No such file or directory (errno=2)
Feb 10 10:29:25 OPNsense openvpn[79210]: Exiting due to fatal error
Feb 10 10:34:31 OPNsense openvpn[40849]: OpenVPN 2.4.4 amd64-portbld-freebsd11.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jan 22 2018
Feb 10 10:34:31 OPNsense openvpn[40849]: library versions: OpenSSL 1.0.2n  7 Dec 2017, LZO 2.10
Feb 10 10:34:31 OPNsense openvpn[40991]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock
Feb 10 10:34:31 OPNsense openvpn[40991]: WARNING: using --duplicate-cn and --client-config-dir together is probably not what you want
Feb 10 10:34:31 OPNsense openvpn[40991]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 10 10:34:31 OPNsense openvpn[40991]: Diffie-Hellman initialized with 2048 bit key
Feb 10 10:34:31 OPNsense openvpn[40991]: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Feb 10 10:34:31 OPNsense openvpn[40991]: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Feb 10 10:34:31 OPNsense openvpn[40991]: ROUTE_GATEWAY x.y.z/255.255.255.255 IFACE=pppoe0 HWADDR=00:00:00:00:00:00
Feb 10 10:34:31 OPNsense openvpn[40991]: TUN/TAP device ovpns1 exists previously, keep at program end
Feb 10 10:34:31 OPNsense openvpn[40991]: TUN/TAP device /dev/tun1 opened
Feb 10 10:34:31 OPNsense openvpn[40991]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Feb 10 10:34:31 OPNsense openvpn[40991]: /sbin/ifconfig ovpns1 10.0.8.1 10.0.8.2 mtu 1500 netmask 255.255.255.255 up
Feb 10 10:34:32 OPNsense openvpn[40991]: /usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup ovpns1 1500 1622 10.0.8.1 10.0.8.2 init
Feb 10 10:34:32 OPNsense openvpn[40991]: /sbin/route add -net 10.0.8.0 10.0.8.2 255.255.255.0
Feb 10 10:34:32 OPNsense openvpn[40991]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Feb 10 10:34:32 OPNsense openvpn[40991]: Socket Buffers: R=[42080->42080] S=[57344->57344]
Feb 10 10:34:32 OPNsense openvpn[40991]: UDPv4 link local (bound): [AF_INET]x.y.z
Feb 10 10:34:32 OPNsense openvpn[40991]: UDPv4 link remote: [AF_UNSPEC]
Feb 10 10:34:32 OPNsense openvpn[40991]: MULTI: multi_init called, r=256 v=256
Feb 10 10:34:32 OPNsense openvpn[40991]: IFCONFIG POOL: base=10.0.8.4 size=62, ipv6=0
Feb 10 10:34:32 OPNsense openvpn[40991]: Initialization Sequence Completed

The connection itself from my client to the server works fine, no errors etc. I'm not sure how to fix that. Any suggestions? Thanks in advance.

And what should be done to upgrade to the neweset revision auf 18.1b? Which command should I use?

Thank you :) Got a bit irritated though because I thought I've blocked the downgrade correctly. I didn't know that it won't work for the webinterafce.