Dec 21, 2020

Why is the WiFi reception not as good as it should be?

If you are unhappy with the performance of the WiFi ensure you are using Selfnet WiFi (Name of the WiFi is "Selfnet"). If you are running your own WiFi check the tips below.

We do hear the feedback about slow network speeds quite often - in particular for devices relying on WiFi.
Here we would like to elaborate on why this is the case and - more importantly - what you can do to change that. We do our best to save the tech talk. If you like to just see solutions - read on. If the text gets too technical just stop reading and reach out to us (e-mail / chat / office hours in a Corona-free time) and we will be more than happy to explain.
Practical solutions - if you are just interested in these - are marked in bold in this article..

Wait, Selfnet runs the network and that's what sucks. What's my part here?
To get this out the door as early as possible: At least half of your experience in the WiFi is something you can (and should?) influence.

Our network is somewhat different to WiFi at home

First of all we need to distinguish one very important part: There is WiFi run by Selfnet in some dormitories and there are thousands of other WiFis. Click here to check if your dormitory is equipped with WiFi operated by Selfnet. That WiFi is simply called "Selfnet".
And then there is WiFi run by many of our members. That's what we call "user WiFi" and it is almost as diverse as our members are. We will try to help with both kinds of WiFi here.

In both cases one more thing should be understood: A student dormitory is what is sometimes called a "densely populated environment".
From technical point of view that means we have a lot of WiFi devices per square meter in the dormitories. (and out-side of them connecting through windows, and on the roof and even in parking lots...)
Just to give you an idea: Most of the students have more than 5 device simultaneously connected to WiFi. And in the same way as you treat your room mates with respect and consider "live and let live" the motto of a reasonable human interaction, so do your devices.
It seems that quite a few students forget how many WiFi devices they actually use. There is the obvious laptop, smartphone, iPad and the occasional watch being connected. But what about your Alexa, your smart home speaker, your TV, your game console(s), your smart light bulb, .... yes these are all there. Most of them all the time.

And yes, they do interfere with one another. Why? Because they do share time on the WiFi network. - That is called air-time.
Very much in the same way as in good old public radio broadcasts, two speakers cannot talk at the same time and be understood. They do speak alternating. One after the other. And that is what your devices do. And even worse they cannot talk and listen at the same time.
However unlike most humans, many of your devices still talk without any active connection / conversation. They check for updates and new messages, they report statistics, ensure the correct time is displayed and just make sure every other device knows they are still there in order to still receive messages.
That brings me to the first piece of advice:
When you are not at home consider switching of some of your devices.
Effect: Medium, plus you are being nice to your room mates.

Yes, you likely do not need to do this at your parents house. And that is nice.
Please keep in mind that in the student dormitories lots of these devices are used in a smaller, denser, environment. Just consider how many devices you are using and how many device your room mates are using. Does that sum up to 30? 40? 42?
Whatever the count might be - it is very likely higher than at your home.

On different frequencies - Or why you should avoid 2.4GHz

As mentioned above, there are 2.4GHz WiFis and 5.0GHz WiFis. And the later ones are the ones to use.
On a 2.4GHz WiFi the maximum number for WiFis in parallel without causing effects - or interference - for the other WiFis is 3. Now a quick look at the number of WiFis you can see at the moment will very likely show more than 3.
Interference does not mean that you cannot connect. It means you need to share with even more parties "be even nicer / more polite to other devices". Imagine the difference between having one sibling and seven siblings.
To make things worse 2.4GHz is a very popular frequency. You have already counted the number of devices using WiFi for you and your room mates. Now add those with Bluetooth.
Why? Because it is relying the same frequency and Bluetooth usually has priority over WiFi. And while you're at it - please add microwaves, smart home devices (yes, all of them) and remote door openers and all other kinds of remote controls.
Yes, these devices are all on 2.4GHz. Why? - Because device manufacturers can use this frequency free of charge. (Ok, for the microwave oven that's a lie - here you cannot use a different frequency)
Use 5.0GHz WiFi wherever you can. See below an how to do it.
Effect: Highest

If you care use 5.0GHz WiFi that provides you with at least 9 different networks free of interference. There can be more as we can adjust the "channel size".
Knowing if your device actually is connected to a 5.0 GHz network is not as simple. Yes, there are standards for this, but we spare you with that.
For most up-to-date operating systems it is relatively save to assume that they will prefer 5.0GHz WiFi if available. One exception to that rule: iPhones and iPads. However, several devices cannot use 5.0 GHz WiFi. And here are some popular ones that cannot do it: iPhones generation 4 and older, several amazon echo devices (yes, the 2020 entry model still cannot do it; however all of the fireTV devices can do it), older Google / Nest speaker and streaming sticks, many smartphones released prior to 2019, almost all smart home devices, including the Sonos smart speakers and streaming speakers.
Do not run your own WiFi if there is Selfnet WiFi in your dormitory.
Effect: High

If you are operating your own WiFi router or access point

We are sorry but for several reasons there is no Selfnet WiFi in every building. And for those of you in buildings with Selfnet WiFi who still run their own WiFi: Just don't. (unless you absolutely have to). However if you are forced to operate your own WiFi here are some tips on what to do:
1. Switch off 2.4GHz WiFi
Even if you are not using it, it still does consume air-time.
2. If you have to run a 2.4GHz WiFi because one of your devices does not support 5.0GHz: Just change it to the one standard that you do need.
We see a lot of older WiFi standards around the dormitories. If you have a WiFi router that is running WiFi for 20 year-old devices, you probably do not need it. However it is usually active by default.
The problem is that these older - and slower standards - waste even more air-time. Reason for this is, that your WiFi router / access point sends out little messages saying "here I am connect if you dare" and these are sent with the slowest standard it is configured to support.
Look for a supported WiFi Standard (802.11) of N or even better AC (please avoid using b/g/n or g/n - remember, configurations which list several letters will use the slowest one to say "here am I")
3. Nice persons don't scream - please reduce the signal strength
Yes, this is totally counter-intuitive, because what you want is a strong WiFi connection. You should do it anyway.
Having your WiFi signal on full power all the time is the equivalent of having a screaming conversation across the dormitory while all widows and doors are open and everyone in the dormitory is at home. You can have your conversation if you are the only one doing it, but imagine everyone doing it.
4. If you are using 2.4GHz WiFi: For god's sake stop using channel 1
There are 12 channels available for 2.4GHz WiFi in Germany. Most - especially cheaper - WiFi routers / access points are by default configured to use WiFi on channel 1.
Many people do not bother to change that. All your messages do queue up at channel 1 now (remember one is talking at a time and that is not a one per WiFi but one per frequency)... We aren't all trying to use the same door of the train why trying this for WiFi?
Use "automatic" or channels 5 or 9. Note: Some routers provide channels 13 and 14. However these are legally not available for public use in Germany.

One last point with regards to the signal strength: Your smartphone or laptop show you some bars to indicate the reception quality of the WiFi. That indicates your device has a good at reception. It does not tell you anything about sending / transmitting rates.
Especially for our WiFi access points we can tell you that the antennas are really, really good. That ensures that you receive the WiFi. However the antennas - especially in smartphones and tablets - are way smaller than in the access points.
As a comparison imagine you are having a conversation and the other person is using a megaphone. You can hear the other person from far away. But even if you are screaming you might not be loud enough for the other person to understand what you're saying. Same here. Therefore:
If signal is just at 30 - 50% reception strength: Change the location. Sometimes 30cm make a huge difference in reception.
Effect: Medium

One last piece of advice: Cables are a blessing

Use a cable for stationary devices
Effect: Very high
Sure, you do not want to use a cable to connect your smartphone but what about your game console? Or your smart speaker, or your Laptop while you are sitting at your desk?
Connecting with a network cable (given the cable is not broken) provides up to 1GBit/s. That is more than most WiFi can do. Even if when there is just one device connected.

We do hope this helps a bit to get a better connection to the WiFi network. In case you have questions on how to do one or the other thing mentioned here - please reach out via e-mail / chat or visit us during the office hours once Corona-restrictions are lifted.

Cheers,
Your Selfnet-Team

And for those interested here are some very useful details:
1. List of WiFi-Standards for 2.4 GHz and 5.0 GHz 2. Which 2.4GHz Channels do not overlap or interfere 3. Example signal strength in an apartment - see how small changes in location make a huge difference

For our network to run smoothly there are a lot of different things to do: management of the equipment (including buying new stuff and getting service), taking care of servers for the network or additional services, debugging problems like this or connecting new dormitories to our network.

If you want to volunteer, it doesn't matter if you are a pro or a starter: Selfnet offers the opportunity to learn everything required. If you are interested in technical stuff, programming, public relations, project management or anything else: We would be glad to welcome you in our team! Just visit our support hours (once the office hours are re-opened).

The Selfnet-Team

Deutsche Übersetzung

Warum ist der WLAN-Empfang nicht so gut wie er sein sollte?

Wenn du mit Empfang und Geschwindigkeit des WLANs unzufrieden bist, solltest du zunächst sicherstellen, dass du das Selfnet WLAN verwendest (SSID, also der Name des WLANs ist "Selfnet"). Auch für den Betrieb eines eigenen WLANs findest du im Folgenden Tipps zum Verbessern der Performance.

Wir erhalten häufig Feedback zu langsamen Netzwerkgeschwindigkeiten - vor allem bezüglich via WLAN verbundener Geräte.
In diesem Artikel werden wir Ursachen dafür erklären und - wichtiger - was du dagegen unternehmen kannst. Das Technik-Gerede versuchen wir dabei auf ein Minimum zu beschränken. Solltest du dich nur für die Lösungen interessieren, lies weiter. Wenn der Text zu technisch wird, kannst du mit dem Lesen aufhören und uns direkt kontaktieren, zum Beispiel via E-Mail, Chat oder, in einer Zeit nach Corona, auch wieder zu unseren Supportzeiten. Wir werden unser bestes tun, die Thematik zu erklären.

Praktische Lösungsansätze - falls du nur an diesen interessiert bist - sind in diesem Artikel fett markiert.
Moment mal, Selfnet betreibt das Netzwerk, was soll ich also machen?
Eines vorweg: die WLAN-Performance kannst (und solltest?) du zum Großteil selbst beeinflussen.

Unser Netzwerk unterscheidet sich vom WLAN Zuhause

Zunächst muss eine wichtige Unterscheidung getroffen werden: Es gibt das von Selfnet betriebene WLAN und es gibt tausende andere WLANs.
Klicke hier um nachzusehen, ob Selfnet-WLAN in deinem Wohnheim verfügbar ist Dieses WLAN heißt einfach "Selfnet".
Darüber hinaus gibt es von unseren Mitgliedern betriebene WLANs, die so unterschiedlich sind wie unsere Mitglieder selbst. Diese nennen wir "User Wifi". Im Folgenden werden wir versuchen euch mit beiden WLAN-Arten zu helfen.

In beiden Fällen muss zunächst verstanden werden, dass Studentenwohnheime eine Umgebung mit hoher Bevölkerungsdichte sind.
Aus technischer Sicht bedeutet dies eine hohe Anzahl von WLAN-Geräten pro Quadratmeter in den Wohnheimen. (und auch außerhalb, zum Beispiel auf dem Dach oder auf dem Parkplatz...)
Um dir eine grobe Vorstellung zu geben: Die meisten Studierenden besitzen über 5 Geräte, die dauerhaft mit dem WLAN verbunden sind. Und genauso wie du deine Mitbewohner und Mitbewohnerinnen mit Respekt behandelst und "leben und leben lassen" als vernünftiges Motto für menschliche Interaktion betrachtest, tun dies auch deine Geräte.
Viele Studierende vergessen scheinbar, wie viele WLAN-Geräte sie tatsächlich verwenden. Dazu zählen die offensichtlichen Geräte wie Laptop, Smartphone, iPad und gelegentlich auch mit dem Internet verbundene Uhren. Aber was ist mit deiner Alexa, deinen Smart Home Lautsprechern, deinem Fernseher, deinen Spielekonsolen, deiner smarten Glühbirne...? All diese Geräte sind mit dem WLAN verbunden. Die meisten davon dauerhaft.

Und ja, diese Geräte beeinträchtigen sich gegenseitig. Warum? Sie teilen sich Zeit im WLAN Netzwerk. Dies wird als Airtime bezeichnet.
So wie beim guten alten Radio Rundfunk, wo auch nicht zwei Sprecher gleichzeitig reden und verstanden werden können. Sie sprechen abwechselnd. Einer nach dem Anderem. Deine Geräte verhalten sich genauso. Und erschwerend kommt dazu, dass sie nicht gleichzeitig reden und zuhören können.
Anders als die meisten Menschen reden deine Geräte jedoch auch ohne einer aktiven Verbindung/Unterhaltung. Sie sehen nach Updates und neuen Nachrichten, senden Statistiken, stellen sicher dass die korrekte Zeit angezeigt wird oder teilen anderen Geräten mit, immernoch da und für den Empfang von Nachrichten bereit zu sein. Womit wir beim ersten Tipp angekommen sind:
Schalte ein paar deiner Geräte ab, wenn du nicht Zuhause bist.
Effekt: mittel, und du tust deinen Mitbewohnerinnen und Mitbewohnern einen Gefallen

Vermutlich musst du das nicht bei deinen Eltern Zuhause tun. Und das ist gut.
Aber denke daran, dass in Studentenwohnheimen eine Menge solcher Geräte in einer kleineren Umgebung genutzt werden. Überlege wie viele Geräte du und deine Mitbewohner und Mitbewohnerinnen verwenden. Zusammengerechnet ergibt das 30? 40? 42?
Wie viele Geräte es auch immer seien mögen - es sind wahrscheinlich mehr als bei dir Zuhause.

Auf einer anderen Wellenlänge - Oder warum du 2,4GHz vermeiden solltest

Wie bereits genannt, werden zwei Frequenzen für WLAN: 2,4GHz und 5GHz. Und zweiteres sollte verwendet werden.
Die maximale Anzahl an 2,4GHz WLANs, die parallel betrieben werden können ohne sich gegenseitig zu beeinflussen oder zu stören, beträgt 3. Wenn du nach siehst, wie viele WLANs du im Moment sehen kannst, ist die Anzahl höchstwahrscheinlich größer als 3.
Stören sich zwei WLANs bedeutet dies nicht, dass du nicht mit diesen verbinden kannst. Es bedeutet jedoch, dass du mit noch mehr Parteien teilen musst, "noch höflicher zu anderen Geräten seien musst". Stell es dir vor wie den Unterschied dazwischen sieben oder nur einen Geschwister zu haben.
Erschwerend kommt dazu, dass 2,4GHz eine sehr beliebte Frequenz ist. Du hast bereits die Anzahl an WLAN-Geräten für dich und deine Mitbewohnerinnen und Mitbewohner ermittelt. Nun addiere dazu die Anzahl an Bluetooth-Geräten.
Warum? Bluetooth verwendet die selbe Frequenz und hat darüber hinaus in der Regel eine höhere Priorität als WLAN. Und wenn du schon dabei bist, kannst du auch gleich Mikrowellen, Smart-Home-Geräte (ja, alle) und Fernbedienungen aller Arten dazu zählen.
Ja, all diese Geräte verwenden 2,4GHz. Warum? Weil Hersteller dieser Geräte diese Frequenz kostenfrei nutzen können. (Ok, bei Mikrowellen stimmt das nicht, hier keine anderen Frequenzen verwendet werden.)
Verwende, wenn möglich, 5.0GHz. Siehe unten wie das geht.
Effekt: am höchsten

5.0GHz ermöglicht den parallelen betrieb von mindestens 9 unterschiedlichen WLAN-Netzwerken ohne das diese sich gegenseitig stören. Diese Anzahl kann durch anpassen der "Kanalbreite" erhöht werden.
Herauszufinden, ob dein Gerät mit einem 5.0GHz Netzwerk verbunden ist, ist nicht so einfach. Ja, es gibt Standards dafür, aber wir ersparen dir das.
Bei den meisten aktuellen Betriebssystemen kann davon ausgegangen werden, dass sie, wenn möglich, 5.0GHz WLAN bevorzugen. Als Ausnahme sind dabei jedoch iPhones und iPads zu nennen.
Einige Geräte können 5.0GHz WLAN jedoch nicht verwenden. Beispiele für verbreitete Geräte, die dazu nicht in der Lage sind, sind iPhone der Generation 4 und älter, einige Amazon Echo Geräte (ja, Einsteigermodelle aus 2020 können es immernoch nicht, FireTV-Geräte sind hingegen 5.0GHz-fähig), ältere Google/Nest Lautsprecher und Streaming Sticks, viele vor 2019 veröffentlichte Smartphones und fast alle Smart Home Geräte, einschließlich Sonos Smartspeaker und Streaming Speakers.
Betreibe nicht dein eigenes WLAN wenn Selfnet WLAN in deinem Studentenwohnheim verfügbar ist.
Effekt: hoch

Betrieb eines eigenen WLAN Routers oder Access Points

Es tut uns Leid, aber aus mehreren Gründen ist Selfnet WLAN nicht in allen Gebäuden verfügbar. Und an diejenigen, die trotz Selfnet WLAN ihr eigenes WLAN betreiben: bitte, hört auf (außer es geht nicht anders)
Falls du doch dein eigenes WLAN betreiben musst, sind hier ein paar Tipps:
1. Schalte 2.4GHz ab
Selbst wenn du es nicht verwendest, kostet es trotzdem Airtime. 2. Wenn du 2.4GHz WLAN benötigst weil eines deiner Geräte 5.0GHz nicht unterstützt: Konfiguriere es nur für den Standard, den du benötigst.
Wir sehen eine Menge an alten WLAN Standards in den Studentenwohnheimen. Wenn du deinen WLAN-Router für 20 Jahre alte Geräte betreibst, benötigst du das wahrscheinlich nicht. In den Standardeinstellungen ist es in der Regel jedoch trotzdem aktiviert.
Das Problem dieser alten, und langsameren Standards ist, dass sie noch mehr Airtime verschwenden. Das liegt daran, dass dein Router/Access Point kurze "Verbinde dich mit mir, wenn du dich traust"-Nachrichten verschickt und diese mit dem langsamsten Standard, der unterstützt wird, übertragen werden.
Kontrolliere, ob deine Geräte WLAN Standard (802.11) N oder, besser, AC unterstützen. (Bitte vermeide b/g/n oder g/n - Denke daran, Konfigurationen, die mehrere Buchstaben aufführen, verwenden den langsamsten Standard für "Hier bin ich"-Nachrichten)
3. Nette Leute Schreien nicht - bitte reduziere die Signalstärke
Ja, das wirkt kontraintuitiv, du willst ja eine starke WLAN-Verbindung. Du solltest es trotzdem tun.
Das WLAN-Signal auf volle Stärke zu stellen ist in etwa so, als würdest du dich quer über das Studentenwohnheim schreiend unterhalten, während alle Fenster und Türen geöffnet und alle Bewohner und Bewohnerinnen Zuhause sind. Solange du die einzige Person bist, die das tut, funktioniert das, aber stelle die vor jeder würde das tun.
4. Wenn du 2,4GHz verwendest: Um Himmels Willen, höre auf Kanal 1 zu verwenden
In Deutschland sind 12 2,4GHz Kanäle verfügbar. Die meisten, vor allem günstige Router und Access Points verwenden in der Standardeinstellung Kanal 1.
Die meisten Leute ändern das nicht. Deine Nachrichten reihen sich nun alle in Kanal 1 in die Warteschlange (erinnere dich, nur ein Gerät kann gleichzeitig reden. Das ist ein Gerät pro Frequenz, nicht pro WLAN)... Wir versuchen nicht alle durch die selbe Tür in einen Zug einzusteigen, warum sollten wir das mit WLAN versuchen?
Verwende "automatisch", Kanal 5 oder Kanal 9. Anmerkung: Manche Router bieten die Kanäle 13 und 14 an. In Deutschland sind diese jedoch nicht zur öffentlichen Verwendung freigegeben.

Ein letzter Punkt bezüglich der Signalstärke: Dein Smartphone oder Laptop zeigt dir Striche an, um die Qualität deiner Verbindung darzustellen. Dies gibt nur die Empfangsqualität an. Es sagt nichts über die Sendegeschwindigkeit aus.
Wir wissen, dass die Antennen in unseren Access Points wirklich, wirklich gut sind. Dies stellt sicher, dass du WLAN empfängst. Die Antennen in Smartphones und und Tablets sind hingegen viel kleiner als die in den Access Points.
Als Vergleich kannst du dir vorstellen, eine Unterhaltung mit einer Person mit einem Megaphon zu führen. Du kannst diese Person zwar auch aus großer Entfernung hören, aber selbst wenn du schreist bist du vielleicht nicht Laut genug um verstanden zu werden. Hier gilt das selbe. Daher:
Wenn die Signalstärke nur bei 30 - 50% liegt: Ändere deine Position. Schon 30cm können manchmal einen großen Unterschied machen.
Effekt: mittel

Ein letzter Ratschlag: Kabel sind ein Segen

Nutze Kabel für stationäre Geräte
Effekt: sehr hoch

Klar, du kannst kein Kabel für dein Smartphone verwenden. Aber was ist mit deiner Spielekonsole? Oder deinem Smartspeaker? Oder deinem Laptop, während du am Schreibtisch sitzt?
Dich mit einem Kabel zu verbinden gibt dir 1GBit/s (vorausgesetzt das Kabel ist nicht kaputt). Das ist eine höhere Geschwindigkeit als die meisten WLANs bieten können, selbst wenn sie mit nur einem Gerät verbunden sind.

Wir hoffen wir konnten dir ein wenig helfen, deine WLAN-Verbindung zu verbessern. Falls du Fragen hast, wie du die hier aufgeführten Vorschläge umsetzen kannst, schreibe uns via E-Mail/Chat oder besuche unsere Supportstunden nachdem die Corona-Einschränkungen aufgehoben wurden.

Viele Grüße
Dein Selfnet Team

Hier sind noch ein paar nützliche Details für die, die sich dafür interessieren: 1. Eine Liste mit WLAN-Standards für 2,4GHz und 5,0GHz 2. Welche 2,4GHz Kanäle überschneiden und stören sich nicht 3. Beispiel Signalstärke in einer Wohnung - Welchen großen Unterschied ein kleine Positionsänderung haben kann

Möchtest du in Zukunft bei Selfnet mitmachen und dich ehrenamtlich um solche und andere interessante technische Dinge kümmern? Um das Wohnheimsnetz ordentlich zu betreiben gibt es viele verschiedene Dinge zu tun: Verwaltung der Hardware (inkl. Neukauf von Hardware und mit dem Hersteller bezüglich Service arbeiten), Verwaltung von Servern und anderen Netzwerkdiensten, Analyse von Problemen oder neue Wohnheime an das Wohnheimnetzwerk anschließen.

Wenn du mitmachen möchtest geht es nicht um Vorwissen. Wichtiger ist es Spaß zu haben und noch etwas sinnvolles/praktisches neben dem Studium zu tun. Wenn du dich für Technik, Softwareentwicklung, Öffentlichkeitsarbeit, Projektmanagement oder vieles andere interessierst: Wir freuen uns dich bei uns begrüßen zu dürfen! Besuche einfach eine unserer Sprechstunden, (sobald diese wieder stattfinden.).

Das Selfnet-Team

posted at 00:00 by Oli · Blog · wifi

Nov 30, 2020

How to DOS yourself

Deutsche Übersetzung weiter unten.

Maybe you have noticed it throughout last weekend - we had several issues with our network stability.

Friday we started upgrading software on several core routers. That's why we first thought the necessary reboots caused the problems. But the interruptions did not stop after the update was complete and even got worse.

A reason were several messages like this

vaih-core-1 dc-pfe: PANIC PANIC PANIC PANIC PANIC PANIC

or this

vaih-core-2 fpc0 SCHED: Thread 24 (PIC Periodic) ran for 1914 ms without yielding

This caused lags, unresponsive and even unreachable devices. As we are using routing protocols to manage our traffic (OSPF and BGP) which require constant communication between the devices. As a result our devices can select the optimal path to send packets. So the unresponsive devices caused routing changes in the network protocols as the backups links took over.

As soon as the backup links took over the affected devices became reachable again and the routing changed back to the primary path. This repeated between 3 and 20 times and took between 30 seconds and 20 Minutes.

Finding the the Root Cause

The logs showed an activation of the devices DDoS-Protection measures, repeating messages like the ones above and dying OSPF- or BGP-connections.

The sporadic nature of this problem made it complicated to debug. You needed to be permanently present to notice the problem when it started and before it was over to run several commands to obtain log files and debug information.

First we thought there was a configuration difference between our two NAT servers, as the traffic was handled by one device when we started upgrading and by the other afterwards. But we could disregard this theory shortly after since the other device showed the same behaviour.

Another possible cause could have been the connection between the routers and the NAT servers but we were also able to verify that the setup was correct.

Directly after the incident started, it was more or less obvious for us the DDoS-Protection was just a symptom but not the cause. It was the same as with the Juriper-Bug. So we followed the same investigation pattern: Looking at the packets sent through the NAT when the lags started.

The result were a lot of packets to "event.selfnet.de", the public IPv4 NAT-Address for the wireless network we use at public events. Around 2.2% of the 3 seconds we took as a sample were directed to this IP. It was a mixture of UDP and a lot of NTP packets. This caused some concern. UDP could be explained with some former unknown - still active - access point. But there should be nobody using this IP for NTP updates.

So we looked at the source of the packets. Some were from a german vServer provider but the NTP-Packets originated mainly from China-Telecom... weird, why should they go around the globe to call us for a NTP update...

Solving the mystery

So now we wanted to verify it is legitimate traffic and found out: A simple ping to the public IPv4 Address returned with an error message "TTL expired" -- which should not happen in a local network...

Further lookups showed IP-Packets bouncing between our core routers (in the internal network) and the edge routers (in the external networks).

The edge routers sent the packets to our NAT (where they should go), but the NAT did not "translate" them. We expect those packets to be translated to the address of the host that opened the connection. Since there was no open connection, the packets should be dropped. But here, the NAT did forwrad the packets without translation. So an IPv4 packet arrived in our core network, that had a public IPv4 address as destination. Since we only use private address space inside the network, the routers have no route for this. So the packet gets forwarded in the direction of the default-route, which is: to the internet. So the packet gets sent back, though the NAT again. This time, the packet isn't expected to be translated, because it didn't originate inside our network and already has a public source address (from China Telecom). So our edge router receives the packet, and we start over. So these packets go back and forth, tens or maybe even hundrets of times, until their time-to-live expires.

To make matters worse all of that happened with 40 GBit/s between the devices while the packets still needed to be processed by the cores routing engine. So the "DDoS Violations" were correct, we DDoS'ed ourself with 40 GBit/s...

After this the pattern was clear to us: All IPs of our pool for internal SNAT (like the "Event" wireless network) were routed in a loop as the NAT did just forward them, even when there was no valid state from an internal IP.

So one packet from an external address was multiplied into (up to) 255 of them which were transmitted with 40 GBit/s between the devices. If you think about our observation before: We had 4000 Packets in 3 seconds. This times 255 translates to roughly a million packets in our internal network... Well, sounds reasonable the DDoS-Protection tried to protect the routing engine of the devices and it became unreachable.

But as the routing engine stopped responding, this caused the BGP- and OSPF-Sessions to die. This started a domino effect: Routing switched to the backup paths, other routers were impacted and when the first device became responsive again (since the load suddenly disappeared), the routing started to switch back to the primary connections - and caused the whole loop again.

The Fix

Finally we knew what we had to do: The packets that do not translate at the NAT should be dropped at the end of handling them.

The fix was applied yesterday around 9 p.m. and since then we haven't detect another larger disruption.

For the ultimate reason we can only speculate: * Was it the new Software? Is there a command or anything which is interpreted in a different way? * Did the reboot of our device change something? * Did somebody try to scan our network for vulnerabilities? * ...?

For now we can not say what is more likely. We can only say that our NAT was not configured in the correct way.

And the moral of the story? Do not trust your own NAT if you already have a history!

Thanks to all of our members who helped in any way to solve this problem. We also apologize to all users of our network, as it wasn't quite stable during the period of recognizing the bug and debugging it.

Do you want to participate in taking care of such problems in the future? For our network to run smoothly there are a lot of different things to do: management of the equipment (including buying new stuff and getting service), taking care of servers for the network or additional services, debugging problems like this or connecting new dormitories to our network.

The Selfnet-Team

Deutsche Übersetzung

Wie man sich selbst per DOS angreift

Eventuell hat es der ein oder andere am Wochenende mitbekommen: Wir hatten einige Probleme was die Stabilität der Verbindungen im Netzwerk anging.

Am Freitag hatten wir einige Software-Upgrades auf unseren Core-Routern durchgeführt, weshalb wir dies erst auf die neue Software und die Neustarts im Netz schoben. Doch die Ausfälle hörten auch nach dem Abschluss der Arbeiten nicht auf.

Der Grund waren einige Meldungen unserer Core-Geräte wie diese

vaih-core-1 dc-pfe: PANIC PANIC PANIC PANIC PANIC PANIC

oder auch diese

vaih-core-2 fpc0 SCHED: Thread 24 (PIC Periodic) ran for 1914 ms without yielding

Bei dem Betrieb der Geräte äußerte es sich dabei so, dass diese stockten, nicht mehr reagierten und dann teilweise auch nicht mehr erreichbar waren. Das führte dann wiederum dazu, dass das Routing im Netzwerk auf die Backup-Wege umschwenkte.

Kurz danach war das Gerät dann wieder erreichbar und das Routing schwenkte wieder auf die Hauptleitungen. Das ganze wiederholte sich dann teilweise 3-20 mal über eine Zeitspanne von teilweise nur 30 Sekunden bis 20 Minuten.

Ursachenforschung

In den Logs sah man teilweise die DDOS-Protection anschlagen, wiederholende Meldungen wie die oben und sterbende OSPF-/BGP-Prozesse.

Problematisch war das sehr sporadisch Auftreten des Problems, was die Fehlersuche nicht so einfach machte, da man dauerhaft am Gerät sein musste um während einer Unterbrechung noch Befehle abzusetzen oder Log-Dateien auszulesen, bevor diese wieder vorbei war.

Anfangs war eine Vermutung, dass es eine Diskrepanz zwischen unseren beiden NAT-Servern gibt, da vor den Systemupgrades der Traffic über das eine Gerät ging, danach über das andere. Dies wurde kurz danach aber bereits widerlegt, da auch das andere Gerät die Probleme zeigte.

Da dies nicht die Ursache war ein weiteres mögliches Problem die Verbindung zwischen den Routern und dem NAT, aber auch das konnte ausgeschlossen werden.

Von Beginn an war relativ klar, dass die aktivierte DDOS-Protection nur ein Symptom und nicht die eigentliche Ursache war, da es bei dem Juriper-Bug ähnlich aussah. Also haben wir wie bei jenem Bug auf dem NAT die Pakete die weitergeleitet wurden mal angesehen als sich ein weiterer Ausfall ankündigte.

Das Ergebnis waren viele Pakete an event.selfnet.de, die öffentliche IPV4 NAT-Adresse für u.a. das Event-WLAN. Insgesamt 2,2% bei den knappen 3 Sekunden die wir uns ansahen. Die Pakete bestanden aus UDP Paketen mit kaum Inhalt und relativ viel NTP. Das machte uns schon etwas stutzig. UDP könnte man sich eventuell noch erklären wenn irgendwo das WLAN noch aktiv wäre, auch wenn kein Event ist, aber NTP-Anfragen sollten da nicht aktiv hin geleitet werden.

Also haben wir uns angesehen, wo die Pakete herkamen. Einige Pakete kamen von einem vServer-Anbieter in Deutschland und die NTP-Pakete hauptsächlich von der China-Telecom. Hmmm... komisch, wieso sollten die bei uns NTP machen wollen...

Des Rätsels Lösung

Daraufhin wollten wir verifizieren, ob der Traffic überhaupt legitim ist und stellten fest, dass ein Ping an die öffentliche IP mit der Meldung "TTL expired" zurück kam. Das sollte im lokalen Netzwerk eher nicht so sein...

Beim weiteren Betrachten fiel dann auf, dass die IP-Pakete zwischen unseren Core-Routern (dem internen Netz) und den Edge-Routern (dem externen Netz) Ping-Pong spielten.

Der Edge-Router schickte die IP-Pakete zum NAT (wo sie ja auch hin sollten), das NAT hat diese aber nicht "übersetzt" auf eine interne IP aber schickte es trotzdem weiter und der Core schickte das ganze wieder zurück zum NAT, da die IP ja durchs NAT musste.

Und das ganze mit 40 GBit/s wobei die IP-Pakete zum Routing an die Routing-Engine weitergeleitet werden mussten. Im Endeffekt war das mit dem "DDOS-Violations" also schon richtig, wir haben unsere Router selbst mit 40GBit/s gedost...

Daraufhin ist das Muster auch deutlich erkennbar geworden: Alle IPs aus dem Bereich für die internen SNAT-Dienste (wie eben das Event-WLAN) wurden im Kreis geschickt, da das NAT diese einfach weiterleitete, wenn es keinen passenden State von intern gab, zu den man die Anfrage zurück übersetzen könnte.

Damit wurde aus einem IP-Paket von extern eben bis zu 255 die mit 40 GBit/s zwischen den Geräten hin und her flogen. Wenn man nun noch bedenkt dass es in dem kurzen Zeitraum den wir uns ansahen knapp 4000 solcher IP-Pakete von extern waren kommt man auf etwa eine Million IP-Pakete intern... Irgendwo verständlich, dass dann der DDOS-Schutz anspringt und die Routing-Engine nicht mehr erreichbar ist.

Das die Routing-Engine der Geräte nicht mehr erreichbar war sorgte dann letztendlich dafür, dass die OSPF- und BGP-Sessions ausliefen. Das sorgte dann dominomäßig dafür dass dann im Routing viel umgestellt wurde und teilweise das Problem einfach den nächsten Router traf. Wenn die Routing-Engine wieder erreichbar war, gings wieder zurück auf Ursprung und wenn dann immernoch so viele IP-Pakete da waren, waren wir wieder am Anfang des Kreises und alles begann von neuem.

Der Fix

Nachdem wir dies erkannt hatten konnten wir die Pakete die nicht zum NAT passen am Ende der NAT-Regeln einfach verwerfen.

Dieser Fix wurde gestern Abend ~21 Uhr eingespielt und seitdem konnte wir keine weiteren großen Ausfälle feststellen.

Über die Ursache kann man nun nur spekulieren: * War die neue Software schuld? Wird irgendwas anders interpretiert? * Hat der Neustart der Geräte etwas ausgelöst? * Hat jemand versucht herauszufinden ob unser Netz verwundbar ist? * ...?

Momentan kann man hier denke ich keine genauere Aussage treffen als die, dass letztendlich unser NAT falsch konfiguriert war.

Und die Moral von der Geschicht? Trau deinem eigenen NAT nicht!

Wir danken hiermit allen Mitgliedern, die bei der Fehlersuche und Problemlösung beteiligt waren. Auch wollen wir uns bei den Mitgliedern entschuldigen, die während dieser Zeit nicht auf die übliche Stabilität des Wohnheimnetzwerks zählen konnten.

Das Selfnet-Team

posted at 00:00 by Michael · Blog · network

Jun 04, 2020

Tale of the JuRIPer-Bug

Deutsche Übersetzung weiter unten.

Since the beginning of January we've had several problems with one of our core routers which seemed related to the outages in September last year. We can now say: This problem has finally been solved.

But let's start at the beginning. On Friday, September 6th of 2019 the Selfnet core network was completely offline for a few hours. The reason back then was a firmware problem after we installed our new Juniper EX4600 which could be solved by downgrading to an older version and waiting for another update (see the article Outage RFO for September 6th/7th, 2019).

Before Christmas 2019 we changed to a newer version (after having successfully tested it for some time) as the old version would no longer be maintained. Everything seemed to be fine so we mentally marked the problem as done. But damn were we wrong...

On Friday (again a Friday...) January 24th, 2020 around 7:20AM, the core network broke down completely. When we noticed that and after some of our volunteers arrived onsite we could stabilize the network around 9:30 AM. As we just installed a new NAT server the evening before we assumed there was something wrong with it. We thought it had been overwhelmed by the traffic of our members in the morning. So we switched to the older backup NAT hardware and set the new one aside for debugging.

Then we began to notice similarities to the problem observed in September, but since the software upgrade in December the active user traffic was not routed via this stack of hardware. So it seemed like we had the same bug all over again.

Meanwhile we collected logs and engaged with our device manufacturer Juniper for a solution.

The main problem with this type of bug is a bit ironical: The router was not completely broken, so the network did not failover to the redundant hardware. Our network control plane was in a kind of zombie state, half dead and half alive.

Message from syslogd at Jan 25 12:56:25  ...
dc-pfe: SCHED: Thread 11 (Ethernet) ran for 1441 ms without
yielding
Message from syslogd at Jan 25 12:56:25  ...
dc-pfe: Scheduler Oinker
Message from syslogd at Jan 25 12:56:25  ...
dc-pfe: Frame 0: sp = 0x21bc9fa0, pc = 0x8048b2a
Message from syslogd at Jan 25 12:56:25  ...
dc-pfe: Frame 1: sp = 0x21bc9fb0, pc = 0x80567cf

It just gave messages like this, having a 99% CPU utilization of the packet forwarding engine (especially the fxpc process) and dumped core images of the software. Then after a while, it would start working again for a moment until breaking down again.

We tried switching to an even newer major software version and hoped for the bug to be eradicated there. It looked good... for a while.

But then it happened again and again, usually around 4AM and 8PM, which was interesting since there were no obvious connections to user traffic peaks. It just started from one moment to another and then the link between the core and the NAT would be saturated with packets. Furthermore as the issue caused high CPU load on the affected device it made debugging difficult and caused additional latencies in the whole network, affecting our storage cluster which in return caused degraded performance for most other services (support systems, radius, ...).

Further debugging seemed to show that the device's internal ddos-protection triggers shortly before an outage. We tried to investigate this but couldn't find any conclusive reason what tripped the ddos protections. So finally we migrated the main traffic to another device and just switched back to our affected device when we were actively debugging it.

While collecting debugging logs we noticed one IP-address that had a lot of traffic to our core router shortly before any outage. We analyzed this traffic and finally found a packet that caused a bridging loop between NAT server and core device! The originating IP was Netscout Arbor, which is a service scanning the entire internet for vulnerabilities and reporting them. Well, seems we found one....

With that information we were even able to reproduce the packet (see below for our script to test yourself): it is an UDP packet to port 520 which is the common port for the Routing Information Protocol (RIP). We don't use that protocol and it should not have been active. Our tests showed that port 521 (RIPng) was also affected. The packet didn't even have to contain anything but zeroes, so no routing information itself was handled. Just receiving the packet caused the problem.

The core router would reply to this input packet from the Internet with the exact same packet, including the exact same source and destination MAC, TTL and so on. We were a bit confused about this, as at least the source and destination MAC should have been changed and the TTL decreased. The NAT server would look at the packet returned from the core router and route it back to the core, as the destination MAC still was the one of the core device and it should go there, right? And as the NAT is in transparent mode it did not decrease the TTL of the packet as well, so it never timed out and pinged between core and NAT forever.

Example Packet:

<Ether  dst=f0:4b:3a:a2:b2:3f src=a8:d0:e5:5c:1b:00 type=0x800
 |<IP  version=4 ihl=5 tos=0x0 len=52 id=54321 flags= frag=0 ttl=242 proto=udp src=146.88.240.4 dst=141.70.124.114 options=[]
 |<UDP  sport=55377 dport=521 len=32 chksum=0x0
 |<Raw  load='\ x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00' |>>>>

We even set up a testlab and could confirm that the problem occurs with a fresh installation in minimal configuration as well. We also experimented with different software release versions and made a discovery: in earlier versions this bug did not occur and the packet would just be ignored by the device (as it should) but newer versions showed this bug:

17.1R3.6 - normal behaviour
17.2R3.4 - normal behaviour
17.3R3.10 - normal behaviour
18.1R2.6 - normal behaviour
18.1R3-S8 - bug occured
19.3R2.9 - bug occured

So the problem seems to be introduced somewhere after 18.1R2.6 and before 18.1R3-S8. Which is kind of a problem because 18.1R3-S8 is the JTAC recommended version (according to Juniper KB21476 at that time).

Considering that we could also trigger it from anywhere over the internet (we tested it from one of our member's DSL), it seemed quite serious and could possibly affect many users with transparent firewalls, worldwide. We reported the findings with our small script (kill_core.py to Juniper and escalated the issue. We weren't even sure about the true scope as Juniper uses a unified system on all of their devices so other models could be also affected like the QFX5100 which uses the same base hardware (?). We could not confirm this as we don't own one of these devices though.

Meanwhile we implemented some firewall filters to protect our devices from the bug. It was quite simple as you just need to implement a filter on the lo0-loopback interface to prevent those UDP packets from going into the routing engine. After this hotfix the devices worked without a problem... until we discovered that the bug could also be triggered by sending an IPv6 UDP packet to the IPv4 ports. We assume that it took longer to recognize this issue as the address space is way larger and Arbor has a higher scan interval.

Since then we also changed the configuration of our NAT/transparent firewall setup so that it replaces the source MAC on outgoing packets in any case which should prevent problems like this flood in the future.

After some time we received the confirmation of Juniper labs being able to reproduce the bug but the information regarding the trigger or root cause is confidential and could not be disclosed. But nevertheless JTAC is now informed and can help customers reporting similar problems. Juniper also told us that there will be a new software version having this bug fixed which is released in May 2020.

According to Juniper the following versions should have the issue fixed:

18.4R1-S5
18.4R3
19.2R2
19.3R3
19.4R2
18.3R3-S1
18.2R3-S3
17.3R3-S7
18.1R3-S9
18.4R2-S3
19.1R3
19.1R2-S1
20.1DCB
18.1R3-S10

The Selfnet-Team

Deutsche Übersetzung

Die Fabel des JuRIPer-Bugs

Anfang diesen Jahres hatten wir immer wieder Probleme mit unseren Core-Routern, die mit den Ausfällen vom September 2019 in Verbindung stehen. Jetzt können wir sagen: Das Problem wurde endlich gelöst.

Aber fangen wir von vorne an. Es ist Freitag der 6. September 2019 und das Core-Netz von Selfnet ist für mehrere Stunden offline. Der Grund hierfür sind Probleme mit der Router-Firmware auf den von uns am Vortag neu verbauten Juniper EX4600. Das Problem konnte durch ein Downgrade auf eine ältere Firmware Version kurzfristig behoben werden. Wir haben das Problem bei Juniper (Hersteller) gemeldet und dann darauf gewartet, dass es entsprechende Updates gibt (siehe Artikel Bericht über die Ausfälle vom Freitag und Samstag (6. und 7.9.)).

Vor Weihnachten 2019 haben wir dann eine neuere Version der Firmware installiert, nachdem wir diese einige Zeit getestet hatten und die alte Version der Firmware von Juniper nicht mehr unterstützt wurde. Alles schien in Ordnung zu sein, weshalb wir das Problem gedanklich als erledigt markiert haben. Damit lagen wir gewaltig falsch...

Am Freitag (wieder ein Freitag...), den 24. Januar 2020 um ca. 7:20 Uhr morgens fiel das Core-Netz wieder komplett aus. Als wir dies festgestellt und einige Mitglieder sich vor Ort darum gekümmert haben, konnten wir das Netz wieder stabilisieren.

Da wir am Vorabend einen neuen NAT-Server verbaut hatten, gingen wir davon aus, dass der neue Server das Problem sei und haben den Traffic auf das alte NAT umgeschwenkt und den neuen Server erstmal für weitere Analysen beiseite gestellt.

Am gleichen Tag später fielen uns immer mehr Ähnlichkeiten zum Problem vom September 2019 auf. Seit des Firmware-Updates im Dezember 2019 wurde der Datenverkehr nicht mehr über die neuen EX4600, sondern die alten Juniper EX4500 geroutet. Es schien alles so zu sein wie im September 2019.

Zwischenzeitlich haben wir Fehler-Logdateien gesammelt und Kontakt zum Hersteller Juniper aufgenommen.

Das Hauptproblem dieses Bugs ist etwas ironisch: Der Router war nicht komplett "kaputt", also wurde nicht automatisch auf einen alternativen, anderen Backup-Router umgestellt. Die control plane unseres Netzwerks war sozusagen wie ein Zombie: irgendwie tot, aber eben nicht ganz.

Message from syslogd at Jan 25 12:56:25  ...
dc-pfe: SCHED: Thread 11 (Ethernet) ran for 1441 ms without
yielding
Message from syslogd at Jan 25 12:56:25  ...
dc-pfe: Scheduler Oinker
Message from syslogd at Jan 25 12:56:25  ...
dc-pfe: Frame 0: sp = 0x21bc9fa0, pc = 0x8048b2a
Message from syslogd at Jan 25 12:56:25  ...
dc-pfe: Frame 1: sp = 0x21bc9fb0, pc = 0x80567cf

Der Router hat uns nur Meldungen wie diese gegeben, die CPU Auslastung der Paketweiterleitung (packet forwarding engine) war bei 99% (speziell der fxpc Prozess) und es wurden immer wieder Coredumps der Software ausgegeben. Nach einer Weile fing es dann wieder für einen Moment an zu funktionieren, nur um dann direkt wieder umzufallen.

Auch der Versuch auf eine noch neuere Firmware Version upzudaten - in der Hoffnung, dass der Bug dort nicht auftritt - hat nur kurzfristig geholfen. Zumindest hat es für eine Weile gut ausgesehen...

Aber es kam immer wieder und wieder zu Ausfällen. Üblicherweise zwischen 4 Uhr Morgens und 8 Uhr Abends, was interessant ist, da wir während dieser Zeit normalerweise keine offensichtlichen Lastspitzen im Netz haben. Es passierte einfach vom einen auf den anderen Moment und der Link zwischen den Cores und unserem NAT war plötzlich komplett voll. Zusätzlich - weil das Problem zu sehr hoher CPU Auslastung führt - war die Fehlersuche natürlich sehr umständlich und zeitaufwändig, was weitere Ausfälle wie z.B. von unserem Storage Cluster nach sich zog (und dementsprechend auch andere Systeme wie das Ticketsystem (support@selfnet.de), RADIUS (WLAN), ... negativ beeinflusst hat).

Die weitere Fehlersuche erbrachte, dass die interne Erkennung der Core-Router für DDoS Angriffe einen "Selbstschutz" vor solchen Angriffen ausgelöst hat. Allerdings konnten wir keinerlei Hinweise darauf finden, was das ausgelöst hat. Schlussendlich haben wir den primären Datenverkehr auf einen anderen (älteren) Router (EX4500) umgeleitet und haben nur, wenn wir aktiv bei der Fehlersuche waren, den Datenverkehr wieder auf die betroffenen Geräte geroutet.

Als wir weitere Logs gesammelt hatten, ist uns kurz vor einem Totalausfall eine IP-Adresse mit sehr viel Datenverkehr zu unserem Core-Router aufgefallen. Wir haben den Datenverkehr analysiert und haben schlussendlich ein Paket gefunden das zwischen unserer Firewall und dem Core-Router eine Schleife produziert hatte. Die Absender-IP-Adresse war die von Netscout Arbor. Das ist einer von diversen Scannerdiensten, die das gesamte Internet auf Sicherheitslücken abscannen und (üblicherweise) dann bei den Organisationen, bei denen Sie eine Sicherheitslücke finden, Bescheid geben. Es scheint so, als hätte Netscout Arbor nicht nur eine Sicherheitslücke gefunden, sondern diese auch direkt ausgelöst ...

Mit diesen Informationen konnten wir das Problem mit einem selbst erstellten Paket reproduzieren (siehe das Skript weiter unten): Es handelt sich um ein UDP Paket mit dem Zielport 520, was der standardisierte Port für das Routing Information Protocol (RIP) ist. Irgendwie ziemlich ironisch, da es sich hierbei um ein recht antikes Protokoll aus den Urzeiten des Internets handelt. Zusätzlich nutzen wir das Protokoll nicht einmal und es hätte auf unseren Routern (da nicht konfiguriert) auch nicht aktiv sein dürfen. Unsere Tests zeigten, dass Port 521 (RIPng) auch betroffen war. Das Paket musste nicht einmal irgendwelche Routing-Informationen beinhalten - Nullen reichen völlig aus. Der bloße Empfang des Pakets genügt, um das Problem zu erzeugen.

Der Router antwortet auf das eingehende Paket vom Internet mit exakt dem selben Paket, inklusive der exakt gleichen Quell-/Ziel-MAC-Adressen, TTL und so weiter. Das hat uns erst einmal etwas irritiert, da zumindest die Quell- und Ziel-MAC-Adressen geändert und die TTL reduziert werden müssten. Der NAT-Server sieht sich das Paket an und schickt das Paket (Ethernet-Frame) natürlich wieder postwendend an den Core zurück. Da unser NAT transparent ist, wird auch nicht die TTL reduziert, also gibt es für das Paket auch nie einen Timeout...

Beispiel eines Pakets:

<Ether  dst=f0:4b:3a:a2:b2:3f src=a8:d0:e5:5c:1b:00 type=0x800
 |<IP  version=4 ihl=5 tos=0x0 len=52 id=54321 flags= frag=0 ttl=242 proto=udp src=146.88.240.4 dst=141.70.124.114 options=[]
 |<UDP  sport=55377 dport=521 len=32 chksum=0x0
 |<Raw  load='\ x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00' |>>>>

Wir haben dann ein Testlabor aufgebaut, um festzustellen, ob mit einer frischen Installation der Firmware und einer minimalen Konfiguration das Problem weiterhin auftritt (tat es). Zusätzlich haben wir verschiedene Versionen der JunOS Firmware durchprobiert, um festzustellen, in welchen Versionen der Bug auftaucht. In älteren Versionen trat der Bug nicht auf und das von uns präparierte Paket wurde - wie es sein sollte - einfach verworfen und in neueren Versionen trat der Bug auf:

17.1R3.6 - normales Verhalten
17.2R3.4 - normales Verhalten
17.3R3.10 - normales Verhalten
18.1R2.6 - normales Verhalten
18.1R3-S8 - betroffen vom Bug
19.3R2.9 - betroffen vom Bug

Es scheint, als wenn das Problem irgendwann nach 18.1R2.6 und vor 18.1R3-S8 aufgetreten ist. Das ist natürlich ein Problem, da zu dieser Zeit die Firmware Version 18.1R3-S8 laut JTAC die empfohlene Version war (siehe Juniper KB21476).

Bedenkt man, dass wir das Problem von "irgendwo" aus den Tiefen des Internets heraus provozieren konnten (eines unserer Mitglieder hat es von zu Hause über seinen DSL-Zugang probiert), schien es uns, als wäre dies ein eher kritisches Problem, welches potentiell viele Nutzer mit transparentem NAT weltweit betreffen könnte. Unsere Erkenntnisse haben wir mitsamt des Scripts von unten (kill_core.py an Juniper weiter geleitet und den entsprechenden Case bei Juniper mehrfach eskaliert, damit eine Lösung möglichst schnell herbeigeführt wird. Wir sind nicht sicher welche Verbreitung der Bug wirklich hat, da Juniper mit JunOS eine einheitliche Plattform auf den meisten seiner Geräte verwendet - es könnten also auch andere Modelle wie z.B. QFX5100 betroffen sein, die prinzipiell ähnliche Hardware verwenden (?). Wir konnten dies aber nicht verifizieren, da wir diese Geräte nicht besitzen.

Zwischenzeitlich haben wir entsprechende NAT-Regeln erstellt, die unsere Geräte vor dem Auslöser des Bugs schützen. Dies war recht simpel, da ein einfacher Filter auf dem lo0-loopback Interface ausreicht, damit diese UDP Pakete nicht zur Routing Engine durch kommen. Nach diesem Hotfix haben unsere Router ohne Probleme weiter funktioniert... bis wir festgestellt haben, dass der Bug auch durch ein UDP Paket per IPv6 an die IPv4 Ports provoziert werden kann. Wir vermuten, dass es länger gebraucht hat, bis Arbor bei der IPv6-Adresse unseres Routers angekommen ist, da der Adressraum natürlich größer und damit auch das Scan Interval größer ist.

Seitdem haben wir auch die Konfiguration unserer transparentem NAT so geändert, dass die Quell-MAC-Adressen bei ausgehenden Paketen ersetzt werden. Dies sollte diese Art von Problemen in Zukunft verhindern.

Nach einiger Zeit bekamen wir dann eine Bestätigung, das Juniper das Problem im Labor reproduzieren konnte. Leider sind Informationen zum Auslöser und dem grundlegenden Problem geheim, weshalb wir hier keine weiteren Informationen bekommen haben. Nichtsdestotrotz ist der JTAC nun informiert und kann anderen Juniper Kunden mit dem gleichen Problem helfen. Juniper hat uns auch darüber informiert, dass es im Mai 2020 neue Firmware Versionen geben wird, die den Bug beheben.

Laut Juniper ist der Fehler in folgenden Versionen behoben:

18.4R1-S5
18.4R3
19.2R2
19.3R3
19.4R2
18.3R3-S1
18.2R3-S3
17.3R3-S7
18.1R3-S9
18.4R2-S3
19.1R3
19.1R2-S1
20.1DCB
18.1R3-S10

Das Selfnet-Team

kill_core.py:

#!/usr/bin/env python3

from scapy.all import Ether, IPv6, UDP, Raw, sendp

SOURCE_MAC  = "00:80:41:33:05:04"  # my laptop at home (where I sent the packet from)
SOURCE_ADDR = "2001:db8::beef"     # my laptops address as source
SOURCE_INTF = "wlp3s0"  # wifi...
GATEWAY_MAC = "00:80:41:18:5b:0e"  # my crappy wifi router
TARGET      = "2001:db8::affe"     # our juniper box as the target


frame = Ether(
        src=SOURCE_MAC,
        dst=GATEWAY_MAC,
        type=0x86dd,
        ) / IPv6(
            version=6,
            src=SOURCE_ADDR,
            dst=TARGET,
            ) / UDP(
                sport=55377,
                dport=520,         # RIP
                len=32,
                chksum=0x0,
                ) / Raw(
                    load="\x00" * 24,
                    )

print(repr(frame))

sendp(frame, iface=SOURCE_INTF)

posted at 00:00 by Michael · Blog · network

← Previous Next → Page 3 of 11