Firewall

Unifi RADIUS Authentifizierung mit VLAN Zuordnung

­In der aktuellen Beta des Unifi Controllers (v5.5.5+) ist das erste Mal ein Radius Server enthalten, sodass man kein Drittsystem benötigt. Dieser läuft dann auf der USG und ist z.B. für die WLAN Authentifizierung verfügbar.

Zugegeben, meistens hat man einen Windows Server mit NAP und AD Anbindung, aber eben nicht immer. In meinem Fall möchte ich guten Bekannten einen persistenten Internetzugang geben (also keinen Gäste-Voucher) aber diese dennoch nicht in meinem Netzwerk haben. Hier steht, wie es geht:

Vorarbeiten – VLAN Anlegen

Damit man WLAN Clients in verschiedene VLANs zuordnen kann, müssen natürlich VLANs existieren. Dazu in den Settings unter Networks ein neues Netzwerk anlegen und VLAN ID, IP Range sowie DHCP Scope angeben – fertig! Jetzt noch nach belieben Firewallregeln festlegen.

Aktivierung des RADIUS Servers

Zunächst in die Settings und dort den neuen Menüpunkt Services auswählen und dort im Bereich RADIUS die Servereinstellungen wählen. Dort Enable RADIUS Server auf ON setzen – fertig.

Danach im RADIUS Profil (Profiles -> Default) das drahtlose VLAN Tagging aktivieren:

Zuletzt noch dem WLAN Profil das RADIUS Profil zuweisen:

User anlegen

Jetzt können User angelegt werden. Gibt man kein VLAN an, wird auch keines gesetzt und der User landet im Default / untagged VLAN:


Möchte man hingegen ein VLAN mitgeben, muss die ID eingetragen und die Optionen 13 sowie 6 gesetzt werden:


Wenn man sich nun verbindet und mit dem  „friend1“ anmeldet bekommt man eine IP aus dem VLAN341:

Aus der Serie…

Site-to-Site VPN: Unifi USG <-> Ubitquiti Edge Router

Wie ich in meinem letzten Artikel schon erwähnt habe, werkelt bei meinen Eltern ein EdgeRouter. Aktuell hatte ich für das StS VPN immer einen Debian Server mit OpenVPN als VM laufen – mit dem USG sollte sich das ändern. Also habe ich mich heute mal an die Konfiguration gemacht.

Mein erster Gedanke war: Ab in den Unifi Controller und flux das Remote-Netzwerk anlegen… leider falsch Gedacht. Dort geht das zwar theoretisch, aber eigentlich nur mit IPSec VPN. Die Besonderheit an meinem VPN ist, dass nur eine Site eine IPv4 Adresse hat, daher auch immer von der anderen Site initiiert werden muss.
Trotzdem kann man es aber auf dem USG einrichten, wie erfahrt ihr hier:

Vorbereitungen

Als erstes braucht ihr natürlich die Konfiguration auf der Edge-Router Seite. Das ist realtiv einfach und auch gut von Ubiquiti beschrieben. Also per SSH auf den EdgeRouter verbinden, den Shared Key erstellen und das OpenVPN Interface anlegen:

generate vpn openvpn-key /config/auth/secret

set interfaces openvpn vtun1
set interfaces openvpn vtun1 mode site-to-site
set interfaces openvpn vtun1 local-port 1195
set interfaces openvpn vtun1 remote-port 1195
set interfaces openvpn vtun1 local-address 10.99.99.3
set interfaces openvpn vtun1 remote-address 10.99.99.4
set interfaces openvpn vtun1 shared-secret-key-file /config/auth/secret
set interfaces openvpn vtun1 openvpn-option "--comp-lzo"
set interfaces openvpn vtun1 openvpn-option "--float"
set interfaces openvpn vtun1 openvpn-option "--ping 10"
set interfaces openvpn vtun1 openvpn-option "--ping-restart 20"
set interfaces openvpn vtun1 openvpn-option "--ping-timer-rem"
set interfaces openvpn vtun1 openvpn-option "--persist-tun"
set interfaces openvpn vtun1 openvpn-option "--persist-key"
set interfaces openvpn vtun1 openvpn-option "--user nobody"
set interfaces openvpn vtun1 openvpn-option "--group nogroup"
set protocols static interface-route 192.168.15.0/24 next-hop-interface vtun1
Wichtig ist, dass ihr euch die Datei /config/auth/secret bzw. den Inhalt kopiert.
Anschließend speichern und abmelden
commit
save
exit
Als nächstes müssen wir auf dem Unifi Controller manuelle Konfigurationen des USG erlauben. Dazu per SCP z.B. verbinden und die Datei config.gateway.json in der Site Configuration (/var/lib/unifi/sites/<SiteName>/) anlegen
Der Inhalt der Datei legt fest, wo die OpenVPN Konfiguration für das Interface vtun0 liegt:
{
	"interfaces": {
                "openvpn": {
                        "vtun0": {
                                "config-file": "/config/ovpn/site1-udp-1195.ovpn"
                        }
                }
	}
}

Konfiguration des USG

Nun können wir uns dem USG zuwenden – hier via SSH oder SCP die OpenVPN Config anlegen


# Remote server to connect to. Can be domain name or IP address.
remote site1.mydyn.domain.de

# Protocol and Port - Must be the same on both server and client.
proto udp
port 1195

ifconfig 10.99.99.4 10.99.99.3
secret /config/auth/secret
route 192.168.17.0 255.255.255.0

# Use a persistent key and tunnel interface.
persist-tun
persist-key

# keeping a connection through a NAT router/firewall alive, andfollow the DNS name of the server if it changes its IP address.
#keepalive 10 60
ping-timer-rem
float
ping 10

# Compresssion
comp-lzo

Wichtig ist, dass ihr anschließend das Secret von oben nach /config/auth/secret kopiert.

Das war’s! Nun muss das USG neu provisioniert oder neugestartet werden. Hierzu könnt ihr z.B. eine Portweiterleitung anlegen. Anschließend wird der Tunnel aufgebaut.

Falls es nicht funktioniert, werden die Fehler im Syslog protokolliert:


tail -f /var/log/messages

Aus der Serie…

Netzwerkupgrade: Ubiquiti USG und APs

Ich habe aktuell eine Fritz!Box. Leider. Diese Box ist ja echt ein Wunderwerk der Technik, kann alles, macht alles. Aber sie ist bei mir auch ultra langsam. Das WLAN ist nicht der Knaller und mein OpenVPN für zwei Site-to-Site Tunnel ich muss extra auf einer VM laufen lassen. Also würde es mal Zeit für ein Upgrade: ein Ubiquiti Security Gateway und zwei UAP-AC-PRO AccessPoints sind es geworden. Erst hatte ich überlegt einen Edge Router zu nehmen (habe ich schon bei meinen Eltern im Einsatz), aber die USGs werden nach und nach immer besser… also mal die (meiner damaligen Meinung nach) einfache USG – Variante genommen.

Die Konfiguration über die Unifi Software ist easy – über eine Oberfläche kann man das USG, die APs sowie eventuelle Switche konfigurieren. Übergreifende Konfigurationen wie VLANs sind auf allen Geräten verfügbar und können einfach verwendet werden.

Mein Setup wird relativ einfach sein: 2 SSIDs (intern und Gast) und 3 VLANs. Das Gast WLAN wird mit einem Captive Portal mit Voucher Codes geschützt um nur meinen Gästen den Zugriff zu gestatten.

Unifi Konfiguration

Da ich von Natur aus ungeduldig bin, habe ich schon am Mittwoch und Donnerstag die Unifi Software installiert und komplett durch konfiguriert. Die wichtigsten Punkte:

Unter „Networks“ müssen die Netzwerke, also euer LAN und ggf Gäste-Netz definiert werden:

Mein LAN sieht dabei so aus:

Wichtig ist hier das „Gateway“ – diese IP wird später das USG bekommen. Das Gast-Netz ist äquivalent – nur mit dem Purpose „Guest“ und der VLAN ID 330. Diese könnt ihr natürlich wählen wie ihr wollt – bei mir ist WLAN immer ab 300 und 330 das Gast-Netz.

Anschließend unter „Wireless Networks“ die WLAN-Netze erstellen:

Ich habe dort mein Default-WLAN per WPA-PSK und das offene Gast-Netz. Dazu noch ein WPA2 Enterprise Test-Netz (dazu später mehr). Zu guter Letzt noch unter „Guest-Control“ den Hotspot konfigurieren. Eigentlich ist alles selbsterklärend, wichtig ist, dass Voucher aktiviert sind und die IP des Unifi-Servers freigegeben ist für „Pre-Authorization Access“ – das heißt auch ohne Anmeldung darf man diese IP aus dem Gast-Netz aufrufen. Das ist notwendig, weil der auf dem Unifi Server das Portal gehosted wird.

Um den Gäste nicht meine ganze Leitung zur Verfügung zu stellen sondern nur 4 Mbit habe ich eine neue User-Gruppe angelegt und dieser die entsprechende Bandbreiten-Einschränkung zugewiesen

und diese anschließend im WLAN Netzwerk eingetragen

Das wars – ab dem Moment wartete ich nur noch auf die Hardware…

Einrichtung der Hardware

Am Freitag war es dann endlich soweit: das USG und der erste Accesspoint waren da!

Also fix alles ausgepackt:

Kabel dran, in der Software auf Adopt geklickt und…

„Adoption Failed“ – ging nicht. Was für ein Dreck! Klingt ja auch logisch – das USG hat die IP 192.168.2.1 – mein Unifi-Server hat die 192.168.15.252, die kommen nicht zueinander. Für die Adoption wird SSH genutzt, und da muss die Netzwerkroute natürlich funktionieren.
Also mal fix geschaut: laut Ubiquity soll man sich direkt an das USG verbinden und die IP des LAN-Ports auf das Ziel-Subnetz ändern. Gesagt getan – ohne Erfolg. Also habe ich es dann umgedreht und dem Unifi-Server eine virtuelle Netzwerkkarte im Subnetz 192.168.1.0/24 gegeben. Ja richtig, 192.168.1.0 – auch wenn das USG laut Unifi Software die 192.168.2.1 hat, in Wirklichkeit ist es die 192.168.1.1.

iface eth0:1 inet static
address 192.168.1.252
netmask 255.255.255.0
Anschließend habe ich das „Adopt-Form“ von Hand ausgefüllt und die Daten
IP: 192.168.1.1
User: ubnt
Password: ubnt
Inform-URL: 192.168.1.1:8080/inform
Siehe da – die Adoption lief ohne Probleme durch und das USG wurde erkannt:
Ab dem Moment war es einfach. Die Konfiguration für den WAN Port kann man direkt im „Configure“-Menü auf der rechten Seite durchführen:
Bei mir hängt das USG hinter der Fritz!Box – durch die VOIP-Konten von Vodafone/KabelDeutschland kann ich leider nicht ganz auf die Box verzichten. Aber nachdem ich alle unnötigen Funktionen (WLAN, FritzNAS, FritzMediaServer, DHCP etc.) deaktiviert hatte, lief sie etwas schneller und ist jetzt nur noch Gateway. Das USG ist als ExposedHost in der FritzBox definiert.
Jetzt gab es schonmal wieder Internet – wenn man mit dem Kabel verbunden war. Also als nächstes den WLAN Accesspoint in Betrieb nehmen. Hier war dann aber wirklich alles „straightforward“. Anschließen, adoptieren, fertig.
Schon gab es WLAN, alle SSIDs waren da und auch das Gast-Portal funktionierte – wunderbar!
Das USG und der Accesspoint sind in meinem Wohnzimmer (da ist auch die Kabeldose – leider!) und unsere Wände bestehen gefühlt aus Blei und Stahl. Im Wohnzimmer hatte ich super Empfang (-40db) und im Arbeits- bzw. Gästezimmer war es schon wieder grausam mit -78db. Außerdem hatte ich noch eine kleine Herausforderung: im Arbeitszimmer hatte ich einen FritzRepeater mit LAN Port um alle Geräte über die WLAN-(B/K)rücke per Kabel zu verbinden. Dieser Repeater wollte aber nicht gut mit dem Unifi-Accesspoint arbeiten. Also habe ich schnell bei Amazon noch einen bestellt – dieser sollte als Mesh-Accesspoint genutzt werden.

Mesh WLAN

Unifi bietet die unglaublich geile Funktion Mesh WLANs aufzubauen. Das heißt ich kann AccessPoints dort wo kein Kabel ist anschließen und sie arbeiten als Repeater – für alle SSIDs mit VLAN Tagging etc. Und wenn der AccessPoint zwei LAN Interfaces hat – wie mein UAP-AC-PRO dann gibt er dort auch wieder das Netzwerk aus. Übrigens kann man mit den richtigen Mesh-AccessPoints sogar die per WLAN angebunden AccessPoints als Uplink für weitere nutzen.

Also dann – AccessPoint ausgepackt, POE dran (wichtig: nichts in den LAN Port des POE Adapters stecken) und schon wurde er angezeigt:

Nach der Adoption wird er als ISOLATED angezeigt und muss einem Uplink-AccessPoint zugewiesen werden:

Anschließend wird er provisioniert und strahlt die WLAN SSIDs  aus.

Das wars – zwei AccessPoints und ein USG verrichten jetzt hier Ihren Dienst. Die WLAN Verbindung ist erheblich besser als vorher- ich erreiche in der ganzen Wohnung (sogar auf dem Balkon) im Speedtest mindestens 75 MBit/s – früher waren es mit Ach und Krach 20 MBit/s.

Zukunftsausblick

Ich denke ich werde noch meine zwei „Öko-Switche“ von D-Link gegen Unifi Switche tauschen – nicht das ich die Funktionen wirklich brauche, aber im Wohnzimmer kann ich mir durch POE eine Steckdose sparen und generell ist es dann einheitlich.

Aus der Serie…

Die Astaro-Ära hat ein Ende…

Seit Verson 7 nutze ich die Astaro Security Gateway, bzw. inzwischen die Sophos UTM.

Die Astaros der Versionen 7 und 8 waren immer spitze, performant, leicht zu konfigurieren und trotzdem sehr funktional. Mit dem Upgrade auf Version 9 und somit dem Wechsel Sophos änderte sich das. Die Software wurde langsamer und nur für das betreiben der UTM brauchte es 4GB in der VM.

(mehr …)

Seriennummer der Fritz!Box über das Web-IF auslesen

Klingt leicht, oder? Ich wollte nicht mehr als für den Support meine S/N zu haben. Dummerweise war ich aber nicht in der Nähe meiner Fritz!Box. Also: Im Webinterface gucken!

Wie ich sehe, sehe ich nichts! Keine Infos… also kurz google angeworfen und eigentlich ist es einfach:

http://fritz.box/jason_boxinfo.xml
Und schon zeigt die Box alle möglichen Infos an:
<j:BoxInfo>
  <j:Name>FRITZ!Box Fon WLAN 7270 v2</j:Name>
  <j:HW>139</j:HW>
  <j:Version>54.05.05/j:Version>
  <j:Revision>20181</j:Revision>
  <j:Serial>0024XXXXX3733XXC</j:Serial>
  <j:OEM>avm</j:OEM>
  <j:Lang>de</j:Lang>
  <j:Annex>B</j:Annex>
  <j:Lab/>
  <j:Country>049</j:Country>
</j:BoxInfo>

mit TMG redirect auf /owa

Gestern habe ich mich endlich mal dran gemacht und auf unserer TMG eine neue Regel erstellt, die Anfragen auf unser OWA via http entgegen nimmt und dann auf die https-Adresse umleitet. Weiterhin ist es nicht mehr nötig den kompletten Pfad also inkl /owa anzugeben.

Zunächst wird der OWA-Listener um den Port 80 erweitert und der gesamte HTTP-Traffict auf HTTPS umgeleitet:

Dabei stieß ich auf das Problem, dass der installierte IIS Port 80 für sich beanspruchte und ein Binding auf 0.0.0.0:80 hatte. Nachdem ich den IIs über die Management-Konsole auf Port 8066 umgebogen habe funktionierte der Listener auch einwandfrei.

Nun konnte eine neue Regel kreiert werden beziehungsweise können wir einfach die Veröffentlichungsregel für das OWA duplizieren:

Die neue Regel wird dann aber auf „Deny“ und „Redirect to <OWA-Adresse>“ gestellt:

Weiterhin muss die Authentifizierung abgeschaltet werden:

 

Als letztes müsse die Pfade bereinigt werden, es darf lediglich „/“ eingetragen sein:

Fertig und eigentlich wars ja auch ganz einfach!

550 IP 94.127.18.154 blocked by EarthLink

Gestern kam eine Beschwerde, dass E-Mails an den Provider EarthLink.net immer zurück kamen. Nach einem kurzen Blick auf die Antwort des Mailservers war klar, EarthLink mag unseren Mailserver nicht.

xxx@earthlink.net
SMTP error from remote mail server after MAIL FROM:<prvs=absender@domain.com> SIZE=24641:
host mx4.earthlink.net [209.86.93.229]: 550 IP 94.127.18.154 is blocked by EarthLink. Go to earthlink.net/block for details.

Auf der angegebenen Seite ist dann aber sehr schön beschrieben, das man seine IP wieder „entblocken“ kann, dazu einfach die E-Mail des Mailservers weiterleiten an „blockedbyearthlink@abuse.earthlink.net“ und den Betreff durch „Blocked [IP]“ ersetzen.

Jetzt schauen wir mal, ob das auch klappt…

Astaro: Schlechte Performance mit virtueller ASG

Uns ist vor einiger Zeit aufgefallen, dass die Performance zwischen einer Astaro und den VMs auf dem gleichen ESXi Host sehr schlecht war. Dort waren nur ein paar KB/s möglich. Eigentlich sollte da ja die Post abgehen…

zunächst dachte ich unsere ASG VM hat vielleicht einen Schadem, also schnell aus dem OVF-File eine neue erstellt… erfolglos. Also wurde hier und da recherchiert, gegooglet und festgestellt: Das Problem haben nicht nur wir. Im Astaro-Forum haben sich einige gemeldet und genau das gleiche Problem beschrieben.

Am Ende ist es ganz einfach: Man darf nicht die „Flexible“-Netzwerkkarte verwenden, es muss die „E1000“ sein.

Vorher:

asg vm1

Nachher:

asg vm3

Und schon war die Performance optimal, alles lädt fix und auch der E-Mail Verkehr läuft flüssiger – was ja kein Wunder war bei der bisheringen Geschwindigkeit.

Also, bei VMs immer erstmal die Netzwerkkarten prüfen…

ActiveSync durch Astaro WAF?

In Bezug auf meinen Beitrag zum Thema OWA durch die ASG mit WAF bereitstellen wurde ich angeschrieben und gefragt, wie man denn Active Sync durch die WAF bekommt. Meine Antwort war leider negativ: Ich habe keine Ahnung. Damals habe ich (aus historischen Gründen) ActiveSync via Port 9443 und als NAT-Rule gemacht, heute läufts über ne TMG.

Weiß jemand von euch, wie die korrekten Einstellungen sind? Wenn ich was in Erfahrung bringe, wird es natürlich an dieser Stelle ein weiteres Bilderbuch geben!