16
20.1 Legacy Series / Re: Really a BAD realase.
« on: February 07, 2020, 11:37:08 am »
No he meant definitely to 23.7!!There are these days ....
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
No he meant definitely to 23.7!!There are these days ....
17
20.1 Legacy Series / Re: IPv6RD broken again?
« on: February 02, 2020, 10:41:33 am »
Hi there,
its up and running on my environment. Hard to say what the problem is at your end if you are not providing more details about your config
Br br
its up and running on my environment. Hard to say what the problem is at your end if you are not providing more details about your config
Br br
18
20.1 Legacy Series / Re: Upgrading from 19.7.10 to 20.1
« on: February 02, 2020, 10:36:31 am »
Hi there
Upgrade runs fine on Supermicro X11SBA-LN4F.
Perfect! Thanks to all who made this happen again!
Br br
Upgrade runs fine on Supermicro X11SBA-LN4F.
Perfect! Thanks to all who made this happen again!
Br br
19
German - Deutsch / Re: Problem mit Supermicro X10SDV-TP8F Motherboard
« on: October 10, 2019, 02:37:02 pm »
Bei uns laufen die mit 10G
Br br
Br br
20
German - Deutsch / Re: Problem mit Supermicro X10SDV-TP8F Motherboard
« on: October 10, 2019, 08:13:33 am »
Hi,
Generell ist leider vielfach das SFP+ Thema immer noch so wie Lotteriespielen. Neben den Angaben zu Wellenlänge, Single-/Multimode, ... ist es in der Tat bei den Supermicroboards (und anderen) empfehlenswert, nur getestete SFP+ Module einzusetzen. Speziell mit dem X10SDV(-TLN4F) funktioniert bei uns ein Modul
Supermicro AOC-E10GSFPSR kompatibler BlueOptics SFP+ BO35J856S3D
einwandfrei. Die Ports hängen an einem Netgear Switch, der ebenfalls empfohlene/getestete SFP+ Module für Netgear enthält. Hat bei uns auch 3 Versuche gebraucht bis alles zuverlässig funktioniert hat.
Br br
Generell ist leider vielfach das SFP+ Thema immer noch so wie Lotteriespielen. Neben den Angaben zu Wellenlänge, Single-/Multimode, ... ist es in der Tat bei den Supermicroboards (und anderen) empfehlenswert, nur getestete SFP+ Module einzusetzen. Speziell mit dem X10SDV(-TLN4F) funktioniert bei uns ein Modul
Supermicro AOC-E10GSFPSR kompatibler BlueOptics SFP+ BO35J856S3D
einwandfrei. Die Ports hängen an einem Netgear Switch, der ebenfalls empfohlene/getestete SFP+ Module für Netgear enthält. Hat bei uns auch 3 Versuche gebraucht bis alles zuverlässig funktioniert hat.
Br br
21
19.7 Legacy Series / Re: cant up date to 19.7
« on: July 18, 2019, 08:35:31 pm »
Problem seems to be in the answer to the question:
Proceed with this action? [19.7/y/N]: y
You typed y and should have typed 19.7 if you want to upgrade ...
Br br
Proceed with this action? [19.7/y/N]: y
You typed y and should have typed 19.7 if you want to upgrade ...
Br br
22
German - Deutsch / Re: Magenta TV & IGMP proxy
« on: April 13, 2019, 04:54:06 pm »
Hier gabs mal einen Beitrag dazu - jemand scheint das mal zum laufen gebracht zu haben
https://forum.opnsense.org/index.php?topic=7581.msg40550#msg40550
Im übrigen würde ich empfehlen, den GESAMTEN Netzaufbau anzuschauen; es gibt dann noch Abhängigkeiten mit der Switch config auf dem LAN, ob der switch zB igmpv3 kann und igmp querier passend konfiguriert hat.... Stockende Bilder jedenfalls könnten daran liegen, dass der igmp traffic gebroadcastet wird und dann auf dem LAN Netz zu viel los ist ... Dazu wäre es natürlich hilfreich zu wissen, wie der LAN Aufbau aussieht ...
Br br
https://forum.opnsense.org/index.php?topic=7581.msg40550#msg40550
Im übrigen würde ich empfehlen, den GESAMTEN Netzaufbau anzuschauen; es gibt dann noch Abhängigkeiten mit der Switch config auf dem LAN, ob der switch zB igmpv3 kann und igmp querier passend konfiguriert hat.... Stockende Bilder jedenfalls könnten daran liegen, dass der igmp traffic gebroadcastet wird und dann auf dem LAN Netz zu viel los ist ... Dazu wäre es natürlich hilfreich zu wissen, wie der LAN Aufbau aussieht ...
Br br
23
German - Deutsch / Re: Telekom Entertain/MagentaTV
« on: April 10, 2019, 01:04:55 pm »
Schau mal hier
https://forum.opnsense.org/index.php?topic=7581.msg40627#msg40627
Das scheint jedenfalls mal geklappt zu haben ...
Br br
https://forum.opnsense.org/index.php?topic=7581.msg40627#msg40627
Das scheint jedenfalls mal geklappt zu haben ...
Br br
24
19.1 Legacy Series / Re: Trouble installing NeoRouter
« on: March 15, 2019, 10:43:40 pm »
See basically here how to do:
https://forum.opnsense.org/index.php?topic=2004
You need to replace the old version 15.7 in paths with 19.1 accordingly to use the most recent version
and for the basics here:
https://en.wikipedia.org/wiki/FreeBSD_Ports
https://forum.opnsense.org/index.php?topic=2004
You need to replace the old version 15.7 in paths with 19.1 accordingly to use the most recent version
and for the basics here:
https://en.wikipedia.org/wiki/FreeBSD_Ports
25
19.1 Legacy Series / Re: Trouble installing NeoRouter
« on: March 15, 2019, 09:04:40 pm »
This means that your Neorouter has been compiled with gcc and not with clang. As on OPNsense there is no gcc by default, therefore there is also no libstdc++ (which belongs to the gcc related packages) and therefore the dependency is not found.
See eg https://unix.stackexchange.com/questions/130639/how-do-i-install-the-latest-gcc-on-freebsd
I need to make one correction: you could install gcc which is in /usr/ports/lang/gcc and then you should also have a libstdc++ sorry for that mistake, corrected it above
See eg https://unix.stackexchange.com/questions/130639/how-do-i-install-the-latest-gcc-on-freebsd
I need to make one correction: you could install gcc which is in /usr/ports/lang/gcc and then you should also have a libstdc++ sorry for that mistake, corrected it above
26
19.1 Legacy Series / Re: Trouble installing NeoRouter
« on: March 15, 2019, 05:21:29 pm »
Hi,
I assume that your VPN application is written in C++. The default C++ standard Library on FreeBSD is libc++ and the default compiler is clang. libstdc++ is rather gcc related. gcc is afaik part of the OPNsense standard ports tree.
Br br
I assume that your VPN application is written in C++. The default C++ standard Library on FreeBSD is libc++ and the default compiler is clang. libstdc++ is rather gcc related. gcc is afaik part of the OPNsense standard ports tree.
Br br
27
19.1 Legacy Series / Re: Installation with stopps with kernel Panic
« on: March 05, 2019, 11:20:52 am »28
19.1 Legacy Series / Re: [SOLVED] Upgrade to 19.1.1 - no ipv6 gateway
« on: February 18, 2019, 07:51:15 am »
Hi Marjohn,
I had a 18.7 system properly working with the setting I mentioned (IPv4 and IPv6), I made an Upgrade to 19.1.1 via GUI. When the system comes back, the ipv6 gateway shows offline and all Interfaces have no ipv6 address. Rtsold is not running, dpinger and dhcpv6d are not running and cannot be started. Simple WAN activation/deactivation and/or. reboot of the system did not bring any change. The ipv6 gateway cannot be started manually either.
At this point our conversation started ...
BR br
I had a 18.7 system properly working with the setting I mentioned (IPv4 and IPv6), I made an Upgrade to 19.1.1 via GUI. When the system comes back, the ipv6 gateway shows offline and all Interfaces have no ipv6 address. Rtsold is not running, dpinger and dhcpv6d are not running and cannot be started. Simple WAN activation/deactivation and/or. reboot of the system did not bring any change. The ipv6 gateway cannot be started manually either.
At this point our conversation started ...
BR br
29
19.1 Legacy Series / Re: Upgrade to 19.1.1 - no ipv6 gateway
« on: February 17, 2019, 07:15:39 pm »
I am pretty sure. - I am getting a 56 prefix - and this worked in 18.7 ....
Will double check once again
Br br
[Edit]: Ok: here is what we found.
The fritz box gets an /56 prefix from my ISP
If the tickbox 'Send ipv6 prefix hint' is NOT ticked, the Fritzbox sends an /62 prefix to the Opnsense; this seems to be the default behavior. When the tickbox 'Send ipv6 prefix hint' is ticked, this value can be set in 'the prefix delegation size' field to something different fitting between /56 and /64 accordingly. In my old config, I had this ticked in 18.7 ....
What remains is the changed behavior of the offline ipv6 gateway. The only difference to my old config is now that the 'use IPv4 connectivity' tick box is not active anymore ....
Thanks again marjohn for your real time help - appreciated
Will double check once again
Br br
[Edit]: Ok: here is what we found.
The fritz box gets an /56 prefix from my ISP
If the tickbox 'Send ipv6 prefix hint' is NOT ticked, the Fritzbox sends an /62 prefix to the Opnsense; this seems to be the default behavior. When the tickbox 'Send ipv6 prefix hint' is ticked, this value can be set in 'the prefix delegation size' field to something different fitting between /56 and /64 accordingly. In my old config, I had this ticked in 18.7 ....
What remains is the changed behavior of the offline ipv6 gateway. The only difference to my old config is now that the 'use IPv4 connectivity' tick box is not active anymore ....
Thanks again marjohn for your real time help - appreciated
30
19.1 Legacy Series / Re: Upgrade to 19.1.1 - no ipv6 gateway
« on: February 17, 2019, 06:37:57 pm »
OK - though ....
I am not sure whether this is intended or a somewhat collateral effect:
When I set on WAN interface the prefix delegation size to 62, all is fine:
However, I would assume that this can not be wanted necessarily: Is this size of 62 either hardcoded or calculated out of the number of interfaces?
If not, where can I configure it?
If yes, is my assumption right that Opnsense would not possible to be used as cascaded router with SLACC anymore ...
At least for some of my use cases, this would be very sad ....
Looking forward to any comment
Br br
PS: Not sure whether I missed something but where could I have found the information, that and how the RADV logic has been changed so that the old configs of <= 18.7 can not be obtained 1:1 anymore?
I am not sure whether this is intended or a somewhat collateral effect:
When I set on WAN interface the prefix delegation size to 62, all is fine:
Code: [Select]
Feb 17 18:19:24 OPNsense dhcpd: Copyright 2004-2018 Internet Systems Consortium.
Feb 17 18:19:24 OPNsense dhcpd: All rights reserved.
Feb 17 18:19:24 OPNsense dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Feb 17 18:19:24 OPNsense dhcpd: Wrote 0 NA, 0 TA, 0 PD leases to lease file.
Feb 17 18:19:24 OPNsense dhcpd: Bound to *:547
Feb 17 18:19:24 OPNsense dhcpd: Listening on Socket/9/igb3/2003:e2:XXXX:XXXX::/64
Feb 17 18:19:24 OPNsense dhcpd: Sending on Socket/9/igb3/2003:e2:XXXX:XXXX::/64
Feb 17 18:19:24 OPNsense dhcpd: Listening on Socket/9/igb0/2003:e2:XXXX:XXXX::/64
Feb 17 18:19:24 OPNsense dhcpd: Sending on Socket/9/igb0/2003:e2:XXXX:XXXX::/64
Feb 17 18:19:24 OPNsense dhcpd: Listening on Socket/9/igb2/2003:e2:XXXX:XXXX::/64
Feb 17 18:19:24 OPNsense dhcpd: Sending on Socket/9/igb2/2003:e2:XXXX:XXXX::/64
Feb 17 18:19:24 OPNsense dhcpd: Server starting service.
However, I would assume that this can not be wanted necessarily: Is this size of 62 either hardcoded or calculated out of the number of interfaces?
If not, where can I configure it?
If yes, is my assumption right that Opnsense would not possible to be used as cascaded router with SLACC anymore ...
At least for some of my use cases, this would be very sad ....
Looking forward to any comment
Br br
PS: Not sure whether I missed something but where could I have found the information, that and how the RADV logic has been changed so that the old configs of <= 18.7 can not be obtained 1:1 anymore?