Messages

Opnsense und Modem ist unschuldig - scheint eine verbuggte Juniper-Firmware am Access-Concentrator zu sein, die bei der Telekom gerade in die Breiten schlägt...

Also ich bin jetzt mit meinem Latein so ziemlich am Ende..

Mein Opnsense-Installation funktionierte an dem DSL-Anschluss bis zum 13.01. durchgehen fehlerfrei, dann bekam ich ohne Änderung an Konfiguration oder Verkabelung regelmäßig ein LCP-Terminate Request jede 6900/7200 sec, also sofortige Neueinwahl,  neue IP-Adresse, etc.

Das sieht dann so im ppps.log

Code Select Expand

Jan 20 09:16:06 OPNsense ppp: [wan] IFACE: Up event
Jan 20 09:16:06 OPNsense ppp: [wan] IFACE: Rename interface ng0 to pppoe0
Jan 20 09:16:06 OPNsense ppp: [wan] IPV6CP: rec'd Configure Ack #21 (Ack-Sent)
Jan 20 09:16:06 OPNsense ppp: [wan] IPV6CP: state change Ack-Sent --> Opened
Jan 20 09:16:06 OPNsense ppp: [wan] IPV6CP: LayerUp
Jan 20 09:16:06 OPNsense ppp: [wan]   XXX
Jan 20 11:11:06 OPNsense ppp: [wan_link0] LCP: rec'd Terminate Request #105 (Opened)
Jan 20 11:11:06 OPNsense ppp: [wan_link0] LCP: state change Opened --> Stopping
Jan 20 11:11:06 OPNsense ppp: [wan_link0] Link: Leave bundle "wan"
Jan 20 11:11:06 OPNsense ppp: [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps
Jan 20 11:11:06 OPNsense ppp: [wan] IPCP: Close event
Jan 20 11:11:06 OPNsense ppp: [wan] IPCP: state change Opened --> Closing
Jan 20 11:11:06 OPNsense ppp: [wan] IPCP: SendTerminateReq #44
Jan 20 11:11:06 OPNsense ppp: [wan] IPCP: LayerDown
Jan 20 11:11:06 OPNsense ppp: [wan] IPV6CP: Close event
Jan 20 11:11:06 OPNsense ppp: [wan] IPV6CP: state change Opened --> Closing
Jan 20 11:11:06 OPNsense ppp: [wan] IPV6CP: SendTerminateReq #22
Jan 20 11:11:06 OPNsense ppp: [wan] IPV6CP: LayerDown
Jan 20 11:11:06 OPNsense ppp: [wan] IFACE: Down event
Jan 20 11:11:06 OPNsense ppp: [wan] IFACE: Rename interface pppoe0 to pppoe0
Jan 20 11:11:06 OPNsense ppp: [wan] IPCP: Down event
Jan 20 11:11:06 OPNsense ppp: [wan] IPCP: LayerFinish
Jan 20 11:11:06 OPNsense ppp: [wan] IPCP: state change Closing --> Initial
Jan 20 11:11:06 OPNsense ppp: [wan] IPV6CP: Down event
Jan 20 11:11:06 OPNsense ppp: [wan] IPV6CP: LayerFinish
Jan 20 11:11:06 OPNsense ppp: [wan] Bundle: No NCPs left. Closing links...
Jan 20 11:11:06 OPNsense ppp: [wan] IPV6CP: state change Closing --> Initial
Jan 20 11:11:06 OPNsense ppp: [wan_link0] LCP: SendTerminateAck #22
Jan 20 11:11:06 OPNsense ppp: [wan_link0] LCP: LayerDown
Jan 20 11:11:06 OPNsense ppp: [wan_link0] PPPoE: connection closed

Der TCPdump an der Sensebox-loggt folgendes auf der LCP-Schicht, siehe Attachment.

Da ich auf meiner Seite nichts geändert habe, habe ich bei der Telekom gleich ein Störungsticket eröffnet. Kann man aufgrund des Sachverhaltes ausschliessen, dass es an mir liegt.

Ein anderer User hatte im Onlinekosten-Forum dasselbe Problem (haargenau dieselbe 6900/7200s-Symptomatik) hier: https://www.onlinekosten.de/forum/showthread.php?p=2508765
Der Anwender hat allerdings eine Fritzbox, wo das Problem aus heiterem Himmel eintrat.

Die Telekom will mir jetzt einen Techniker rausschicken, der wohl etwas überfordert vor meinem Draytek Modem und Opnsense-Firewall stehen wird, um voreilig draus zu schliessen, dass es das unbekannte Etwas sein muss, dass den Fehler verursacht ;)

Ich bin der Meinung, dass die Gegenstelle schuld ist, wir werden sehen...

das hier klingt sehr vielversprechend:

https://github.com/opnsense/core/issues/3240

Wobei ich nicht verstehe, warum ein "prevent release" zu diesem Verhalten führt...

ich werde es morgen testen, muss in die heia...

So und schon wieder vom IPv6 abgeschnitten, wegen DSL-Modem-Reboot. Es ist mir nicht gelungen, dass die internen IFs die aktuelle Prefix übernehmen. Die dümpeln mit der alten Prefix rum, pppoe0 reconnecten bringt auch nix - nur ein Reboot der Opnsense schaffte Abhilfe....

Hat da jemand was funktionierendes am Laufen und kann helfen?

Also meine Q570G6 läuft noch an einem 25/5 VDSL (bald hoffentlich 250/40) und läuft auf locker auf den ersten GB Ram. Dabei läuft noch ntopng und redis-db. Mit surricata habe ich noch keine Erfahrung gemacht, was die zieht, sollte aber sich nicht wesentlich auf dem RAM-Verbrauch auswirken.

Leider muss man sich die Optimierungen, was die HW angeht, ein bischen querlesen und ausprobieren. Am DSL habe ich die besten Erfahrungen gemacht, wenn man die PPPOE tunables nimmt, die man relativ häufig in Zusammenhang mit pf/Opnsense und FreeBSD findet.

Ich hab bei der HW folgende tunables eingerichtet:

dev.igb.0.eee_disabled   EEE deakt.   1   
dev.igb.1.eee_disabled   EEE deakt.   1   
dev.igb.2.eee_disabled   EEE deakt.   1   
dev.igb.3.eee_disabled   EEE deakt.   1   
dev.igb.4.eee_disabled   EEE deakt.   1   
dev.igb.5.eee_disabled   EEE deakt.   1   
net.isr.dispatch              deferred   
kern.ipc.nmbclusters      1000000   
net.isr.maxthreads      -1   
machdep.hyperthreading_allowed      0

Wobei eigentlich nur net.isr.dispatch einen Workaround darstellt, der PPPOE und FreeBSDs-Schwäche mit der Prozessor-Affinität mit sich bringt. Dieser sorgt für einen wesentlich fluffigeren Aufbau der Webseiten und gefühlt für eine gleichmässigere Auslastung der Kerne.
Die Queue-Depth der I211 habe ich mit net.isr.maxthreads -1 noch angepasst auf die tatsächlich vorhandenen Kerne und das HT abgestellt, da sich virtuelle Kerne in Verbindung mit NICs eher behindern und für 20% Einbussen sorgen können.
Der Block mit EEE deakt. habe ich von ThomasKrenns-Seiten, die NICs sollen sich mit aktiviertem EEE disconnected haben, konnte ich aber nicht feststellen in meiner kurzen Zeit, bevor ich es mal sicherheitshalber aktiviert habe.

Ach und ja, powerd würde ich in den Einstellungen auf 'hiadaptive' stellen, damit die CPU Nutzen der Turbofrequenz auch ausleben kann.

Viel Spass mit dem Qotom - die Schattenseite der Firma ist wohl die nicht vorhandene Produktpflege.. das Produkt ist noch nicht mal gelistet auf der HP und Firmware leider Fehlanzeige. Aber es läuft ja zuverlässig - was soll man sich also beschweren.

Man, these Qotoms really suck in their passive cooling design.

A massive copperblock without fins with perfectly aligned contact-to the exterior case and cpu would be ideal!

A light pressure must be possible between both to hold the sandwhich together to better conduct heat. In between a thin layer of your preferred compound, and you would be seeing temps way lower.

Perfect would be a heat-pipe construction, because their aluminium fins on the case are well suited for that to work, but in Qotom's design they are kept well underperforming!

Anyway, anything that's get rid of that gum-layer and replaces it with metal-to-metal connection would be pristine for cooling!

Um mir selbst mal zu antworten, ich habe meine Dualstack IPv4 und IPv6 Gateways, da sie beide nicht pingbar sind, mit externen Adressen hinterlegt. Klappt auch gut, bis eine Zwangstrennung passiert.

Das scheint problematisch für den DHCPv6c über IPv4 zu werden, daher habe ich die externe Adresse entfernt und das GW als "immer up" deklariert. Nun denke ich läufts!

Also bei mir habe ich wohl dasgleiche Problem, ich habs neulig im englischen Bereich geposted: https://forum.opnsense.org/index.php?topic=14714.0

Wenn das wie im Post beschrieben, eine Einwahl der persistenten Verbindung durch eine Zwangstrennung oder DSL-Modem Disconnect/Neustart erneut aufgebaut wird, wird zwar dem PPPOE-Interface korrekt das Prefix ausgehändigt, aber der DHCPv6-Service läuft nicht mehr und läßt sich auch nicht mehr starten. Ich nehme mal an, dass der zuständig ist, den LANs über TrackInterface den IP-Bereich zuzuteilen und das RouterAdvertisment entsprechend anzupassen. Der eigentliche DHCPv6-server im LAN wird nicht benutzt/ist inaktiv an der Sense.

Bei mir findet die Einwahl über T-Online hinter dem DSLmodem statt. Wenn ich danach das PPPOE-Interface ohne Änderung abspeichere wird eine Neueinwahl initiiert, bei der es fehlerfrei klappt.

Es ist vielleicht ein Timing-Problem, dass nur passiert, wenn die Verbindung "abreißt" und dann wieder neuaufgebaut werden soll, da sehe ich den einzigen Unterschied aus Sicht der Firewall.

Grüße

I noticed yesterday after I rebooted my dsl-modem, that both my internal IPv6-tracking interfaces were not getting IPv6-adresses through my dial-up interface (PPPoE). IPv4 was fine. This also happens when my ISP forces a disconnect every once a while, requiring an automatic redial.
The delegated prefix (56) is correctly handed out on the adapter though.

To restore IPv6 functionality I usually open the dial-up interface details, save without any changes, and apply it. Then the IPv6 addresses get handed out on the tracking interfaces.

Currently running on the latest 19.7.5. build.

What can I do to make this more reliable?

Hi,

I have a problem after having upgraded to 19.7.3.

My configuration is still fairly out of the box, my LAN-side is using two separate VLANs next to its untagged main-traffic. I got notification, that my telephone is dead, my VOIP-vlan was not letting packets to the inside. I checked the VOIP-VLAN and no traffic was going to the internet. LAN was okay. I rebooted the firewall and afterwards I could not reach the firewall even from LAN-area anymore.
So I needed to hook the machine to a monitor and ran the uninstall steps, I have found in this thread:

Code Select Expand

service eastpect onestop
service elasticsearch onestop
pkg delete elasticsearch5
pkg delete os-sensei
rm -rf /var/db/elasticsearch/nodes/*

Though I remember that one pkg wasnt found, might be another name, but afterwards I had immediate access and running internet to all interfaces.

Is there still something missing for uninstallation? The configuration files is also having a lot of sensei parts in it, would I have to reinstall sensei, to run its uninstallation from the GUI, or is there even a manual way?

Thanks!

I am new to Sensei - I have just installed it and I wander around the menu.

Is it normal that there are no web-categories in web-controls, no entries in app-controls and security? I cannot even add something in security or app-controls?

Thanks for clarification!

I would like to add up, that if you use IPv6 destination/source rules won't match an IPv4-rule, you would better be off setting both rules for up/down to any/any and setting only the direction correct in the rule.
This way it controls the full WAN-line.

yeah, but they don't count up for the total bandwidth for which my maximum-bandwidth rule is set...

qos-rules are obeyed once they hit any rule, just like firewall rules, qos rules should work different.

So, I can easily have qos-rules for different subnets active, but I don't see a way to limit a maximum-bandwidth for the wan-connection, with different limits or costs for subnets.

Two rules must come in effect for each subnet, main limit AND then subnet limit, and that can't be accomplished with it, as far as I reckon now.

Or is there a way?

Hello there,

I am new in this place, and I am enjoying the project so far very much!

But, as always, there comes questions in mind, when trying to accomodate a firewall to your special needs.

I am using a simple upload/download-pipe with a 95% bandwidth-throttle on my main LAN, for bufferbloat-congestion avoidance with a shaper. now I would like to add a limiter for my guest-lan that reserves a special amount of the bandwidth for the users, that also follows the main-bandwidth-pipe.

Imho this would ask for sort-of nested pipes, which don't exist yet, or have I overlooked something?

Hi there,

I am wondering, if there's a way to automate a restart of the strongswan service after successful cert renewal.
I cannot find a way to do that by the means of the plugins' automation function...

Thanks!
Don