Eigenen AP (Raspberry Pi 3) durch Sophos UTM schützen (Update: Sophos UTM und FB 7490 - So gehts)

Hallo Chris,

wegen Umstellung auf All-IP habe ich seit kurzem auch eine FB7490. (Vorher hat die UTM die Einwahl gemacht und 2 AP10 sorgten für WLAN)

Jetzt macht die Fritzbox die Einwahl und reicht alles über Exposed Host an die UTM weiter. DHCP auf der FB ist ausgeschaltet.

WAN -- Fritzbox -- LAN1 (192.168.168.1) ---- EXT (192.168.178.10 fest) -- UTM

Auf der UTM wurde eine zusätzliche Adresse auf das externe Interface gelegt:
Additional Address on Interface EXTERNAL mit 10.10.10.1 genannt FritzboxWLAN. Für dieses Netzwerk wurde DHCP eingerichtet.

Meldet sich jetzt ein Gerät an der Fritzbox an (entweder LAN oder WLAN) bekommt es eine IP-Adresse aus dem 10.10.10.x-Raum und als Gateway die 10.10.10.1.

Somit läuft der ganze Traffic über die UTM und Du kannst die Geräte so fein verwalten wie Du willst. Es ist ein eigenes Subnetz der UTM mit allen Möglichkeiten.

Moin Walter,

danke schon mal! Ein paar Fragen hätt ich da noch...

1) Die FB als Exposed Host wurde in anderen Beiträgen hier als Sicherheitsrisiko eingestuft, da dadurch jeder, der an der FB vorbei kommt, sofort in deinem lokalen LAN landet. Wie schätzt du das Risiko ein?

2) Deinen Aufbau versteh ich im Moment noch nicht ganz. Ich hab dich so verstanden: Kabel aus LAN1 (FB) auf NIC der UTM (External WAN) mit fester IP aus dem FB-Netz (192.168.178.10). Dann Kabel aus zweitem NIC der UTM ins interne (Internal) Netz (Switch, PC, whatever) mit neuen Subnetz (192.168.168.1). Dann zusätzliches Interface auf das external WAN-NIC gelegt, mit ganz neuem Netz und eigenem DHCP (10.10.10.1). Wenn ich dich bis hierhin richtig verstanden habe, ergeben sich für mich zwei Fragen: Wie gibst du dem externen Interface zwei IPs? Das geht nur via Ethernet VLAN, oder? Und zweite Frage: Kann ich dann meinen internen DHCP für das Netz hinter der UTM weiterlaufen lassen?

3) Verschiedene SSIDs/separate Netze lassen sich mit deiner Methode aber nicht realisieren, oder?

Gerade wegen Punkt drei bin ich ja fast am überlegen, ob ich mir einfach ein paar mehr APs bastle, Raspberrys liegen hier genug rum :). Damit wäre auch das Eingangs skizzierte Problem gelöst. Statt einzelnen Rules für die angeschlossenen Geräte hätt ich dann für jedes Gerät nen eigenen AP...gut, zugegeben, effizient is was anderes :).

Letzte Frage: Die Eintragung als Exposed Host brauch ich doch NUR, wenn Geräte, die direkt über die Fritzbox connecten, auch hinter die UTM wandern sollen, oder? So wie ich es jetzt habe, hängt ja schon alles hinter der FB (komplettes Heim-LAN).

Vielen Dank für deine/eure Zeit,

Gruß, 

der Bastler mit Lichtblick

Ich muss mich nochmal korrigieren... die Verwendung eines /30 Netzes ist nicht zu empfehlen!

Hintergrund ist ein Automatismus der Fritzbox bzgl. dem eigenen NAS und der automatischen Bindung an die .254, bzw. die letztmögliche nutzbare IP Adresse.

Das hatte bei mir dann zur Folge, dass 'Exposed Host' nicht mehr funktionierte oder sich einrichten ließ. 'Ungültige Regel' meinte die Fritte dazu nur noch.

Hat sich auch nicht mehr geändert als ich auf /24 zurück bin, war sehr strange das Ganze. Hab die Box zurückgesetzt und neu eingerichtet, diesmal mit /29er Netz und da funktioniert alles wieder wie gewollt.

Ob das Zufall war oder reproduzierbar ist mag ich grad nicht testen. Aber wenn dem so sein sollte kann man sich das Ändern der Subnetzmaske im Transfernetz zur Fritzbox auch ganz schenken, da im /29er außer Fritz und Sophos noch 2 IPS frei sind...

Guten Abend die Herren!

Ich hoffe ich habe bald wieder mehr Luft, der UTM zu widmen. Verfolge aber den Thread mit großer Neugier :).

Die Routing-Idee von Kevin klingt für mich plausibel, allerdings nur für das W-Lan Netz. Wozu brauche ich ein extra Routing von der FB auf die UTM? Übernimmt das nicht quasi der Exposed Host?

Aktuell kämpfe ich noch sehr mit langsamen, verpixelten und manchmal gar nicht startenden Video-Streams (Netflix; Amazon Prime) und gelegentlichen DNS Problemen (beim surfen wird "plötzlich" ein Host nicht aufgelöst). Mein nächstes ToDo, von dem ich mir eine Verbesserung erhoffe, ist das hier: https://community.sophos.com/products/unified-threat-management/f/management-networking-logging-and-reporting/32566/solved-dns-best-practice

Melde mich wieder :) Und ja, bin auch stark für ein "HowTo" am Ende, unterstütze auch gerne.

Grüße und gute Rest-Woche

Chris

Hi Chris,

auf der Fritzbox an die Sophos routen musst Du alle über die Sophos verwalteten Netze, vorausgesetzt Du deaktivierst Masquerading auf der Sophos komplett. Exposed Host ist prinzipiell nur eine Firewall-Regel auf der Fritzbox (Allow Any from Any to Any), kombiniert mit einem DNAT (For Any Connection to WAN-IP Fritzbox change Destination to WAN-IP UTM). Würde die Fritzbox im Bridged Mode laufen und die UTM hinge an dem entsprechend konfigurierten Port sähe das Ganze etwas anders aus. Da steht das WAN Interface der Sophos wirklich auf der öffentlichen IP und ohne Masquerading in Richtung Internet würde nichts laufen. Leider deaktiviert mein Provider den Bridge Mode in Privattarifen und bietet ihn nur im Businesstarif an.

Hast Du aber Masquerading in der Exposed Host Config zusätzlich an wird eine Verbindung aus dem LAN erst auf die WAN-IP der Sophos ge-SNATed und dann auf der Fritzbox nochmal vom internen Netz in Richtung Internet. Das wäre doppeltes NAT und das würde ich wie gesagt wo es geht vermeiden.

Deaktiviere ich aber einfach das Masquerading ohne Routen auf der Fritzbox kommen dort Pakete aus dem LAN hinter der Sophos an und die Fritzbox kennt diese IP gar nicht, da am WAN der Sophos ja eine IP aus dem LAN der Fritzbox konfiguriert ist. Damit die Fritzbox Verbindungen mit einer IP aus einem Netz, welches über die Sophos verwaltet ist, verarbeiten kann muss jedes IP-Netz zurückgeroutet werden.

In der von Walter angeregten Fritzbox-WLAN Geschichte also einmal das Netz, welches auf der Additional IP des Sophos WAN-Interfaces hängt und zusätzlich das interne LAN hinter der Sophos. Bei mir sind es 4 Netze, weil ich SSL-VPN eingehend nutze und noch ein separate Zone WLAN auf der Sophos laufen habe.

Gruß

Kevin

Moin!

Ganz komm ich noch nicht mit. Wenn ich dich richtig verstehe, brauchst du das Routing in der FB NUR, wenn du auf der UTM kein Masquerading machst. Hast du, so wie ich, Masquerading an, brauchts eigentlich auch kein dediziertes Routing an der FB. 

Mir würde es sehr helfen, wenn du mir mal deine Masquerading-Regeln als Screenshot posten würdest.

Anbei meine aktuelle Config der FB (mit Routing an die Secondary IP und Exposed Host auf die UTM) und meine Masquerading-Regeln.

Gruß Chris

Hi Chris,

mit diesen Masquerading Regeln brauchst Du keine Route setzen. Gesagt hast Du es falsch, aber richtig konfiguriert, die Route darf nicht zur secondary IP zeigen, denn die würde die Fritzbox ja nicht kennen. Screenshot meiner Masquerading Regeln erübrigt sich, da hat es keine ;-)

In Deiner Config ist nun aber entweder die Route oder aber der zweite Masquerading Eintrag unnötig, beides brauchst Du nicht, entweder eine Route oder Masquerading für das jeweilige Netz.

Hi Chris,

wie Dir Kevin schon sagte, Du musst das mit dem Routing nicht machen und kannst es beim Masquerading belassen.

Das führt halt zum DoppelNAT. Das ist nicht schlimm, kann aber in machen Konstellationen zu Problemen führen. Darum hat Kevin die Möglichkeit aufgezeigt das DoppelNAT zu umgehen. Der Aufwand ist nicht groß.

Etz hab ichs kaputt gemacht :)

Wer will schon doppeltes NAT, also ich nicht...gesagt, getan. Erst mal die Routen in der FB angepasst:

10.10.10.0 -> Secondary IP/Netz fürs W-Lan

192.168.2.0 -> Internes Netz (LAN hinter der UTM; Internal)

192.168.178.22 -> External WAN an der UTM (also FB -> UTM)

Den Exposed Host gelassen wie er ist:

Danach sämtliches Masquerading in der UTM abgeschalten. Zunächst ging alles...bis mir aufgefallen ist, dass meine beiden Squeezeboxen (Logitech Internet Radio) plötzlich nicht mehr wollen.

Die Ursache glaube ich bereits gefunden zu haben:

2017:03:06-21:52:10 firew_chris dhcpd: DHCPRELEASE of 10.10.10.28 from 00:XX:XX:XX:XX:XX via eth1 (not found)

2017:03:06-21:52:17 firew_chris dhcpd: uid lease 10.10.10.12 for client 00:XX:XX:XX:XX:XX is duplicate on REF_IntEthExternaWan

2017:03:06-21:52:17 firew_chris dhcpd: DHCPDISCOVER from 00:XX:XX:XX:XX:XX via eth1

2017:03:06-21:52:17 firew_chris dhcpd: DHCPOFFER on 10.10.10.28 to 00:XX:XX:XX:XX:XX via eth1

2017:03:06-21:52:17 firew_chris dhcpd: uid lease 10.10.10.12 for client 00:XX:XX:XX:XX:XX is duplicate on REF_IntEthExternaWan

2017:03:06-21:52:17 firew_chris dhcpd: DHCPREQUEST for 10.10.10.28 (192.168.178.22) from 000:XX:XX:XX:XX:XX via eth1

2017:03:06-21:52:17 firew_chris dhcpd: DHCPACK on 10.10.10.28 to 00:XX:XX:XX:XX:XX via eth1

Hi Chris,

die Routen passen soweit, daran sollte es nicht scheitern. Die Sophos ist allerdings gerne etwas zickiger bei DHCP-Leases.

Probier mal, deine Statischen Reservierungen noch mal zu löschen und stell dann den DHCP-Bereich für Dein WLAN so ein, dass Anfang und Ende identisch sind. Dadurch löschst Du alle Leases raus, löschen einzelner unterstützt der DHCP-Server leide noch nicht. Nach dem Speichern der Änderung gleich wieder bearbeiten und die alten Werte einstellen.

Danke dir Kevin! Leider deinen Post ein paar Minuten zu spät gelesen:

Nachdem die beiden Radios ausgefallen waren, quittierte auch noch der Chromecast die Arbeit. Hiernach habe ich mal alle Schritte rückwärts gemacht: Routen gelöscht und Masquerading wieder angeschmissen. Geht jetzt wieder alles.

Werde dein Vorgehen die Tage testen, wenn die Göttergattin gerade keine Musik im Badezimmer braucht :).

Hast Du in der Konstellation auch einen Web Proxy aktiviert gehabt?

Den würde ich zuerst mal ausschalten und erst, wenn  es grundsätzlich klappt wieder aktivieren.

Interessant wäre auch, ob nur DNS nicht will und ob z.B. ein Ping auf eine externe IP wie 8.8.8.8 dennoch funktioniert. FQDN zu 8.8.8.8 ist google-public-dns-a.google.com für die Gegenprobe. Ping muss dann natürlich firewalltechnisch auch raus dürfen.

Hast Du in der Konstellation auch einen Web Proxy aktiviert gehabt?

Den würde ich zuerst mal ausschalten und erst, wenn  es grundsätzlich klappt wieder aktivieren.

Interessant wäre auch, ob nur DNS nicht will und ob z.B. ein Ping auf eine externe IP wie 8.8.8.8 dennoch funktioniert. FQDN zu 8.8.8.8 ist google-public-dns-a.google.com für die Gegenprobe. Ping muss dann natürlich firewalltechnisch auch raus dürfen.