Out of my sewing box: Migration of a Lancom (unmanaged) WiFi to a central managed

Hi guys,

today I will talk a little bit about one of the summer projects here at my workplace. In the last days before I was going to vacation and had married I migrated our unmanaged WiFi with three SSIDs to a central managed system with a WiFi controller.

The situation
Before I was hired, my company bought a bigger amount of Lancom L-54ag WiFi Accesspoints and an Lancom WLC 4025+ WiFi controller. Unfortunately there was nobody in house, who whad experience with WiFi controllers and so there build ad hoc a semi-managed (by hand) WiFi network. I know, not real professional. The WLC was unused mounted in one of the network racks. Every L-54ag span three SSIDs with two VLANs and two disjunct routing instructions. Ok, this was not bad and it… works, but „fancy“ things like band- and client steering wasn’t implemented and an automatic adjustment of broadcast channel and signal strength also. As you can see – it worked, but performant is another thing.

The Way
My first intention in researching about migrating was to look, if it is possible to export the configuration of one of the L-54ag and import this configuration with some mods in the WLC 4025+ If you plan the same – no, there is absolute no way to doing this without frustration, trust me. You can only do one thing, rebuild the whole system new on the WLC. Yes this is not real convenient, but its ok and the work is faster done as you think. Primary you must one configure two bigger points and this is all – configure physical profiles on the controller and logical profiles. Logical profiles will contain every single SSID with parameters and would be associated to one physical profile. the physical profiles contains informations about client steering and some other more physical options.
After you configured the profiles, allow your WLC to accept new accesspoints and reset every accesspoint to his factory defaults. (By default all Lancom accesspoints are in managed mode and waiting for the configuration). Thats all – in theory it’s quite real simple and easy.

Do you have any questions or additions? Please feel free to comment and we can discuss this.

Tagged with: , , ,
Veröffentlicht in english

Spotlight search and SMB protocol version 1

Hey guys, in the last days I work on a little problem in your school (for everybody who doesn’t know: so work as a sysop at a private school). Based on various points we mount our fileshares over SMB on our OS X machines.

Everything works fine except one thing: searching on files! The point is, that Apple’s Spotlight search can’t indexing SMB protocol v. 1. After some research I know why – Spotlight make a heavy use of extended file attributes, which are implemented in HFS+ and can be distributed over the Andrew File Protocol. Unfortunately I can’t upgrade the SMB transmission protocol to version two. If this would be possible, I can write a protocol extension for extended file attributes and everything will work fine in the future.

You can see the problem? To solve this little nasty problem I evaluate some replacements for file search
My first try was Alfred.app which I real like as an alternative launcher, but unfortunately Alfred.app uses the Spotlight index – same problem as described above. Another Option would be ExtremeZ-IP, but in my opinion this is little dirty solution in our case – absolutely impractical. The third option on my roadmap is DEVONSphere Express as a local solution on our OS X clients which offers besides a lot of other features indexing of network shares. After installing yesterday and long indexing times (I activated mail indexing also with about 60k archived mails in one of my account) I will give this tool a try. Maybe this can be a solution for our problem.

Tagged with: , ,
Veröffentlicht in OS X

Vorschau auf das Jahr 2015

In den letzten Tagen habe ich bereits ein erstes Brainstorming über neue Themen für diesen Blog im Jahr 2015 gemacht, aber auch wie es hier weitergehen wird: denn eines ist klar – viel Output konnte man hier im vergangenen Jahr (leider) nicht lesen, was verschieden Faktoren wie der Beendigung meines Studiums und meines Umzuges geschuldet ist.

Geplant ist auf jeden Fall hier, an dieser Stelle mehr zu veröffentlichen, aber auch ein Umzug dieses Blogs und meines privaten Blogs  auf eigene Infrastruktur bei einem Hoster meiner Wahl. Im Grunde genommen stehen auch hier bereits in groben Zügen verschiedene Optionen an. Der Blog wird allerdings weiterhin über einen Redirect unter dieser URL erreichbar bleiben.

Thematisch wird es bunt werden: so wird zum Beispiel ein Schwerpunkt auf FreeBSD und diverse darauf aufbauende Distributionen geben, auch das Thema Netzwerk wird wieder einen Schwerpunkt bilden, sowie Softwaredevelopment und Scripting mit python und WordPressdeployment. Dies sind bisher erst einmal die Ergebnisse meines Jahresanfangs Brainstorming.

Veröffentlicht in Allgemein

A little bit of magic glue

Ok guys, I real like IFTTT as a little glue between multiple web apps, but sometimes this service is not good enough for my intensions. This is the moment in which I choose zapier.com (refferal link) to solve a specific task.

You need an example? Ok – one of my zaps filter photos on instagram and send me a notification, if a new photo is posted in a specific area. It sounds, like it is the probability to solve this task with IFTTT, but it isn’t, ‚cause I not want real all images. I filtered out some hashtags in the description **and** this is the real interesting thing: IFTTT can’t handle this kind! It’s simple impossible. I don’t know why the IFTTT devs do that, but they didn’t implement this little thing.

So if you search for something like IFTTT, but with a little bit more functionality: take a look over zapper.

Tagged with:
Veröffentlicht in Allgemein

[DIY Router] pfsense: DHCP, DNS und NAT (Series Part 02)

Nachdem wir uns in der vergangenen Woche mit der grundlegenden Installation von pfsense auf einer virtuellen Maschine oder optinonal auf Hardware beschäftigt haben, wird es so langsam aber sicher Zeit sich Gedanken über die Konfiguration zu machen, respektive unser neues System betriebsbereit zu konfigurieren. Da wir weiterhin mit dem vorgestellen Szenario arbeiten wollen und werden wird sich der Konfigurationsaufwand mehr oder weniger im Rahmen halten. Ich werde allerdings versuchen zu allen Aspekten dieses Artikels einen kleinen Überblick in die jeweilige Materie zu liefern. Aber notieren wir erst einmal, mit welchen Themen wir uns in dieser Ausgabe der Artikelserie beschäftigen werden:

Vorwort

Wir werden uns also mit mindestens drei Diensten etwas auseinander setzten müssen, um ein funktionsfähiges Netzwerk und Internetanschluss zu erhalten. Keine Angst, wir werden uns Schritt für Schritt an die Lösung des Problems herantasten und ich werde versuchen die Konzepte hinter den jeweiligen Technologien zu erklären. Hilfreich kann es hier sicherlich für den einen oder anderen auch seinen die „Request for Comment (RFC)“ zu den einzelnen Technologien zu lesen. Ich möchte allerdings an dieser Stelle sehr deutlich betonen, das diese RFCs weder vorrausgesetzt werden noch unbedingt gelesen werden müssen um den vorliegenden Artikel verstehen zu können, sie sollen alleinig dem interessierten Leser eine Anlaufstelle bieten um im Selbststudium weiter in die Tiefen der entsprechenden Konzepte vorzudringen. Auf jedes involvierte Protokoll oder Dienst ausführlich einzugehen würde den Rahmen diese Artikels bei weitem sprengen.

Ein kleiner Exkurs in die Adressierung von Computernetzen

Computer sprechen nicht mit menschlicher Sprache untereinander – dies dürfte ja mittlerweile hinreichend bekannt sein. Die Adressierung in einem Netzwerk erfolgt übrigens auch nicht mittels menschlicher Sprache sonder über Bitstrings mit einzelnen Segmenten. Heute gebräuchlich für die Adressierung in Computernetzwerken ist das Internet Protocol (IP) entweder in der etwas angestaubten Version 4 (RFC  791) oder die aktuelle Version 6 (RFC 2460).  Die derzeitige Dualität der Adressierung lässt sich wie folgt  erklären: ursprünglich wurde IPv4 im Jahre 1984 durch die RFC 791 validiert und hiermit eingeführt. Es war ein und ist hier ein Adressraum von 32 Bit reserviert, der auf vier 8-Bit große Blöcke verteilt wird. Aus dieser Vereinbarung ergibt ein Adressraum von 4.294.967.296 einmaligen Adressen. Dies war 1981 eine utopische Zahl und niemand hätte damals gedacht, das dieser Adressraum zu klein sein könnte, wodurch viele Adressräume recht großzügig zum Beispiel durch ie RIPE (übergeordnet für die Welt fungiert die iana) als zentrale Vergabestelle für Europa vergeben: alleine das X-WIN (Backbonenetz des Deutschen Forschungsnetzes, DFN) als auch das GEANT2 (europäisches Forschungsbackbone) nutzen gewaltige Mengen an IPs (ich bitte um Entschuldigung, das ich auf die Schnelle keine Zahlen gefunden habe). Heutzutage stehen wir vor dem Problem, das die IP-Adressen annähernd „aufgebraucht sind, so das man sich bereits 1998 genötit sah durch RFC 2460,  RFC 4291 sowie einigen weiteren eine neue Adressvergabe zu spezifizieren: geboren wurde IPv6. Die Adressvergabe durch IPv6 erfolgt etwas anders, so wurden hier 128 Bit reserviert, die in acht Blöcken a 16 Bit hexadezimal (IPv4 wird dezimal) notiert werden. Hieraus ergibt sich letztendlich ein Adressraum von 2^128 (oder 3,4·10^38) was hoffentlich bis auf weiteres reichen wird.

Der erste Streich: DNS Konfiguration

Dieser kleiner Exkurs in die Welt des Internet Protocols war nötig um aufzuzeigen, warum der Domain Name Service (DNS)  (RFC 1034 und RFC 1035) im Jahre 1987  – also nur knapp sechs Jahre später – verabschiedet wurde: kein Mensch konnte und wollte sich schwer lesbare IP-Adressen merken. Um diese Problematik zu lösen bedient sich DNS einer brilliant einfachen Technologie: es werden sprechende Namen eingeführt, welche auf die nummerischen Adressen umgebogen werden. Man kann sich dies wie eine Art Telefonbuch der Computernetzte vorstellen. Bestechend simple und dabei unglaublich elegant. Wir müssen jetzt natürlich unserem frisch installiertem Gateway mitteilen, wo denn eines (oder mehrer) dieser Telefonbücher zu finden sind – sonst wird hier schwerlich ein Übersetzung in die entsprechende IP-Adresse möglich sein. In der Regel stellt jeder ISP (Internet Service Provider) mindestens seinen Kunden Zugang zu seinen eigenen DNS-Servern bereit. Sollten Sie allerdings vor dem Problem stehen, dass Sie aus Ihrem bisherigen Router die Adressen der DNS-Server nicht auslesen können, Ihr Provider in der folgenden Liste nicht auftauchen oder Ihr ISP sich scheut Ihnen die Adresse mitzuteilen, so werden sie im Abschnitt „Problematik mit ISP-DNS“ sog. freie DNS Server finden, die Sie ohne Problem nutzen können. [gist https://gist.github.com/g4s/0eff634bb98a30da507c /] Nun aber wirklich mal ans Werk! Wir wollen für die DNS-Einstellungen zwei verschiedene Punkte realiseren, denn erstens möchten wir, das unser lokaler DNS-Server auf dem pfsense-Gateway sprechende Namen für alle Geräte produziert, welche über DHCP eine Adresse zugewiesen bekommen (richten wir weiter unten noch ein) und zweitens möchten wir die Möglickeit, die über den WAN-Anschluss zugewiesenen DNS-Server ignorieren zu können. Ersteres dient vornehmlich unser Bequemlichkeit um Geräte im Netzwerk ansprechen zu können. Für das Überschreiben der zugewiesenen DNS-Server gibt es verschiedene Gründe, unter anderem weil einem die zugewiesenen DNS-Server nicht schnell genug antworten.

DNS-Forwarding: lokalen Geräten dynamisch DNS-Einträge verpassen

Wie ich bereits im Vorwort erwähnt ist die Konfiguration von pfsens keine Magie und so ist auch die lokale DNS-Auflösung einfach zu bewerkstelligen. Sie loggen Sich hierzu auf dem Webfrontend Ihrer pfsense-Installation ein und gehen wie folgt vor, da wir zur Zeit keinen vollwertigen DNS-Server installieren wollen – pfsense nutzt für diese Aufgabe im übrigen die relativ schlanke Software dnsmasq, sondern lediglich uns des DNS-Forwardings bedienen möchten:

  1. Wählen Sie oben aus dem Dropdownmenü den Reiter „Services“ aus und dort den Eintrag „DNS-Forwarder“
  2. Nun die beiden Checkboxen vor „Register DHCP leases in DNS forwarder“ und „Register DHCP static mappings in DNS forwarder„.

Das war es auch schon für das DNS forwarding im lokalen Netz. Angemerkt sei hier, dass dnsmasq ein relativ kleiner DNS-Server für klein Netzwerke ist, möchte man große Netzwerke versorgen wird man nicht umhin kommen sich mit anderen DNS-Servern auseinander zu setzen. dnsmasq kann auch sehr kreativ eingesetzt werden um DNS-Anfragen umzubiegen.

Überschreiben der WAN DNS-Server (konfigurieren alternativer DNS-Server)

Ich hoffe, ich konnte Sie spätestens im vorhergehenden Abschnitt überzeugen, dass pfsense bemüht ist die Konfiguration des Gateways möglichst simple zu halten. Wie Sie sehen werden, ist es ähnlich trivial alternative DNS-Server einzutragen, falls Sie die von Ihrem ISP automatisch zugewiesenen nicht nutzen möchten.

  1. Unter System General Setup finden Sie den Eintrag DNS servers
  2. Tragen Sie auf der Seite die entsprechenden DNS-Server und die zugeordneten WAN Gateways ein
  3. Entfernen Sie den Haken in der Checkbox for „Allow DNS server list to be overridden by DHCP/PPP on WAN
  4. Speichern Sie die Änderungen.

Hier sind wir bereits fertig was die Konfiguration des DNS angeht – habe ich Ihnen zu viel versprochen? Es war doch bisher alles machbar, oder? Gewöhnen Sie sich schon einmal daran, sehr viel schwerer wird es erstmal nicht werden.

Probleme mit ISP-DNS

Sie haben nun gesehen, das es möglich ist auch eigenen DNS-Server in das pfsense-Gateway einzukonfigurieren, allerdings haben wir uns noch nicht darüber unterhalten, warum diese Option von Interesse sein könnte. Neben möglichen Geschwindigkeitsfragen muss man sich auch überlegen, ob man seinem ISP trauen kann, in wie weit tatsächlich die DNS-Server des ISP korrekt antworten: leider ist es in der Vergangenheit immer wieder vorgekommen, dass ISPs von Regierungen angewiesen wurden bestimmte Inhalte des weltweiten Netzes zu sperren oder nicht zugänglich zu machen. Eine der einfachsten Lösungen für ISPs, besteht darin falsche Einträge auf Anfragen zurück zu liefern – zumal dies eine möglichst kostengünstige Methode ist. Sofern Ihr Provider nicht DNS Traffic blockt (was die wenigsten machen dürften) besteht eine Lösung des Problems darin, freie DNS-Server in die Konfiguration aufzunehmen. Eines der größten Netzwerke dieser dezentralen DNS-Server ist OpenDNS. [gist https://gist.github.com/g4s/36bce72c1945503688b1 /]

Zweiter Streich: DHCP Konfiguration

Es lässt sich sicherlich streiten ob Sie zuerst die DNS oder zuerst die DHCP Konfiguration durchführen sollten – dieser Guide sieht zuerst die DNS Konfiguration vor, so dass wir nun DHCP konfigurieren, bevor wir uns dem Bereich NAT zuwenden. Bei DHCP werden meistens IP-Adressen dynamisch Netzteilnehmern zugeordnet, bis das Gateway diese wieder löscht: entweder durch Anweisung des Administrators oder weil das Gerät lange genug nicht innerhalb des Netzwerkes integriert war. DHCP-Deamons führen die Zuweisung anhand der sog. MAC-Adresse eines Netzwerkadapters durch, die einer Seriennummer gleich kommt. Per se sollte es auf der Welt keine zwei Netzwerkadapter geben, die die selbe MAC-Adresse teilen, wodurch sich dieses als Identifikationsmerkmal eignet. In der Regel sollte der DHCP-Dienst bereits laufen auf den Netzwerkschnittstellen für das lokale Netzwerk, sollte dies nicht der Fall sein, haben die Schnittstellen höchstwahrscheinlich keine statische IP zugewiesen bekommen – dies sollten Sie spätestens jetzt nachholen, bevor wir weiterfahren mit der Konfiguration. Überlegene Sie sich auf welchen Netzwerkschnittstellen für das lokale Netzwerk Sie gerne DHCP hätten und aktivieren Sie es. In der entsprechenden Maske müssen Sie nur noch den Adressbereich eintragen, den DHCP verwenden soll. Sie geben also ein, von welcher Startadresse, bis zu welcher Endadresse der Adressbereich läuft. Im Grunde genommen reicht dies bereits aus, damit Sie im lokalen Netzwerk ein funktionierendes Netzwerk besitzen: Ihre Maschinen werden mit IP-Adressen versorgt und DNS wird weitergeleitet. Sinnvollerweise können Sie im übrigen auch feste Zuweisungen zwischen MAC Adresse und IP festlegen, so dass das entsprechende Gerät immer die selbe IP erhalten wird – wahlweise auch damit nutzbar, das nur Geräte mit bestimmten MAC-Adressen überhaupt eine IP Zuweisung via DHCP erhalten.

Dritter Streich: NAT und Portforwarding

Widmen wir uns dem inhaltlich schwierigsten Thema dieses Artikels zu, der Network Address Translation (oder kurz: NAT). Im Gegensatz zu DNS und DHCP greift hier pfsense  nicht auf einen Dienst zu, sondern verwendet den Systemkern eigenen Paketfiter – unter pfsense ist die PF hierfür verantwortlich. Im Gegenzug zu Linux, wo es nur einen  Paketfilter im Kerne gibt, auf den alle Firewalls aufbauen, gibt es grundsätzlich die Möglichkeit verschiedene Paketfilter zu verwenden. Ich empfehlen Ihnen aber dringend jedenfalls unter pfsense nicht den Paketfilter aus zu tauschen.

Exkurs: was ist NAT

Bei NAT handelt es sich um ein semi-kompliziertes Verfahren zur Adressumsetzung in Computernetzwerken. Ein kleiner Satz, der allerdings viel inhaltlichen Gehalt aufweist, denn so simple dieser Satz klingt, ist es dann auch nicht. Bei NAT (beschrieben in RFC 1631)handelt es sich um ein Verfahren um öffentliche IP-Adressen auf (private) IP-Adressbereiche zu matchen, denn bereits 1994 bemerkte man, dass der IPv4 Adressraum zu klein sein würde und nicht jeder Host mit einer öffentlichen IP versorgt werden könne. (Wer Interesse hat sich mit privaten Adressräumen zu beschäftigen sie hier auf das entsprechende RFC 1918 hingewiesen). Um dieses gewährleisten zu können, wurden in der entsprechenden RFC 1631 zwei unterschiedliche Typen für NAT definiert, welche ein wenig unterschiedlich funktionieren:

  • Source-NAT Source-NAT ist die gebräuchliche Variante des NAT, wie sie auf gebräuchlichen Routern aus dem SoHo-Segment implementiert und genutzt wird. Hierbei war die Überlegung private Netze an das öffentliche Netzwerk Internet anzubinden. Allerdings waren und sind die Ressourcen in Form von IPv4 Adressen knapp bemessen, weshalb (vor allem) im privaten Segment meist nur eine einzige IPv4 Adresse pro Anschluss verwendet wird.Problematisch hingegen gestaltet sich hier die Menge der möglichen Verbindungen über ein Gateway welches NAT verwendet, denn bedingt durch die Adressierungsbreite von 16 Bit für Portnummern, sind nur knapp 65.000 Verbindungen möglich – Einen Wert, den Privatpersonen eher nicht erreichen werden, aber schon in kleinen Unternehmen kann diese Menge erreicht werden.
  • Destination-NAT Im Gegensatz zum Source-NAT wird beim Destination-NAT etwas anders gearbeitet.  Hierbei geht es darum eingehenden Datenverkehr auf unterschiedlich Server im privaten Netzwerk zu verteilen: Beispielsweise wird der Datenverkehr für Web auf die Domain example.com auf einen anderen Server umgebogen als eingehende SSH Verbindungen.

Letztendlich kann man ganz gut an diesen beiden Variante von NAT sehen, dass sie sich nicht so ganz unterscheiden und warum das ganze eine Routing / Firewalling Sache ist. Firewalling nicht ganz, allerdings unterscheiden die Paketfilter auf  unixoiden Maschinen nur bedingt zwischen Routing und Firewalling.

Zurück zu pfsense

So viel nun zu der grauen Theorie, in der wie immer der Teufel bekanntlich im Detail steckt. Glücklicherweise liefert pfsense von Hause aus auf jeder Schnittstelle zum lokalen Netzwerk bereits NAT aus, so dass wir uns um diesen Aspekt nicht kümmern brauchen, wenn wir dies nicht möchten. Alleinig Portforwarding in Kombination mit NAT muss durch uns konfiguriert werden, damit es funktioniert, damit gehen Sie bitte wie folgt vor:

  1. Wählen Sie im Tab-Menü den Punkt Firewall aus und selektieren Sie dann NAT
  2. Wählen Sie den Tab Port-Forward aus und klicken dort auf das Plus-Symbol
  3. Füllen Sie das Formular entsprechend aus
  4. Speichern Sie die neue Forward Regel ab.

Nachwort und Ausblick

Ich hoffe, ich konnte Ihnen in diesem Beitrag ein wenig die Protokolle DNS, DHCP und NAT näher bringen, sowie wie sie diese in in einer frischen pfsense Installation entsprechend konfigurieren.  Die Liste der freien DNS-Server ist derzeit leider unvollständig, wird aber in nächster Zeit weiter verfollständigt werden – natürlich wird es dann einen gesonderten Artikel hierzu gehen. Sollten Sie einen bestimmten Server vermissen, so lassen Sie es mich bitte wissen, damit auch dieser Server in die Konfigutation mit aufgenommen werden kann.

Tagged with: , , , , , , , , , ,
Veröffentlicht in Administration, Freebsd, HowTo, Security

Mögliche Projekte

Man soll ja irgendwie ab und an auch mal über den eigenen Tellerrand schauen und dann auch vielleicht etwas anderes machen. Klingt gut, lässt sich auch durchführen. Neben der wöchentlichen Artikelserie über pfsense gibt es natürlich auch noch andere Projekte die ich in Erwägung ziehen. Bisher sind das alles noch etwas unausgegorene Ideen, welche erst noch reifen müssen, aber es ist vielleicht für Euch auch mal ganz interessant zu sehen was so in meiner Pipeline steckt:

Diese vier Punkte werden mich sicherlich eine ganze Menge Zeit kosten und mir ganz interessante Aspekte liefern. Nicht zu vergessen sei hier auch noch, dass ich immer noch (mehr oder weniger) an einer LPIC Zertifizierung arbeite.

Tagged with: , , , , ,
Veröffentlicht in Allgemein, Freebsd, Netzwerk, Operating Systems, Virtualisierung, Windows

[Notiz] Featureupdate bei Pinterest

Derzeit scheint sich einiges im Rahnen von Webdiensten zu tun. So gibt es nicht nur Veränderungen bei tumblr und flickr, sonder auch pinterest hat heute Nacht ein neues Feature ausgerollt, neben einem kleinen Design Update, wurden die sog. „Richpins“ eingeführt. Bei dieser neuen Art der Pins handelt es sich um die Möglichkeit mit mehr Kontextinformationen anzureichern, um einen weiteren Mehrwert eines Pins zu repräsentieren. Bei diesem neuen Feature versucht pinterest von einigen Partnerseiten entsprechende Informationen zu grepen.

Tagged with:
Veröffentlicht in News