UniFi Controller - Firewall

[Hexcode]

Hallo zusammen,

ich hab bei meiner Mutter einen Ubiquiti Networks - UniFi AP AC PRO installiert und das W-Lan der Fritzbox deaktiviert.
Die Fritzbox ist per VPN mit meiner gekoppelt.

Mein Netz 192.168.178.1/24
Ihr Netz: 192.168.179.1/24

Problem ist jetzt: Ich kann aus meinem Netz zu Wartungszwecken die Geräte im W-Lan nicht mehr erreichen...
Bisher hab ich Übergangsweise das lokale NAS bei meiner Mutter als Proxy konfiguriert, das klappt problemlos.
Mir stellt sich jedoch die Frage: Wo im UniFi-Controller kann ich die passende Freigabe erstellen, so dass auch Daten aus meinem Netz durch die Firewall des APs kommen, heißt Verbindungen meinerseits aufgebaut werden können?

Grüße

 

[magicteddy]

Moin,

der AP AC PRO ist ein Accesspoint und kein Router, der hat keine Firewall.

Was mich eher stutzig macht: Ihr Netz: 192.168.179.1/24 deckt sich mit dem Gastnetz der Fritte hast Du das bei Dir aktiv?
Kannst Du den AP bei Mutti anpingen?

-teddy

 

[Hexcode]

Genau das macht micht ja auch stutzig... normal darf es ja nichts blocken.
Fakt ist: Ich kann alles im LAN drüben Pingen und erreichen (vorher ging das auch bei den W-Lan Geräten), seit dem der AP dazwischen gekommen ist, lassen sich die W-Lan Geräte nicht mehr pingen und erreichen.
Der AP lässt sich problemlos pingen :/

Gastnetz ist btw. die 181 - das überschneidet sich nicht.

 

[rayze]

Wenn man in der Fritzbox Routen oder das Netz auf 192.168.179 ändert, switched das Gastnetz ins 172er Netz, sobald das ebenfalls belegt ist geht das Gastnetz ins 10er Netz. Könnte also durchaus so funktionieren.

 

[hominidae]

...sind die WLAN-Clients überhaupt mit der Fritte verbunden (doofe Frage, aber muss sein) und in der Fritte sichtbar, als DHCP-Client in der Heimnetz-Übersicht?
Im Controller irgendwelche Broadcast oder Multicast Filter aktiviert?

 

[Hexcode]

Die Geräte sind online - wie gesagt: Wenn ich das NAS nutze am LAN der Fritzbox, komme ich von da auf alle W-Lan Geräte.
In der Fritzbox sind die leider nicht mehr sichtbar, sie bekommen zwar das DHCP von dort, aber sie speichert die Geräte nicht aktiv mit: ist aber ein bekannter Firmware-Bug der Fritzbox.

Und Broadcast und Multicast ist es ja imho nicht - es wäre ja z.B. ne Port 80 Anfrage an ne W-Lan Kamera. Mache ich die direkt über den Proxy im Form des NAS von 192.168.179.2 geht alles durch in Richtung der Kameras, komme ich aus dem 192.168.178.er Netz geht absolut nichts in Richtung der W-Lan Geräte durch. Sofern diese die Verbindung nicht aktiv initiieren.
Also 178 -> W-Lan 179 geht nicht
179 -> 178 geht problemlos

Im Controller hab ich eigentlich alles auf Default gelassen was Filter und dergleichen betrifft und das ist halt das was mich bisschen nervt... das ist nen Access Point: Der hat nicht zu filtern -.-

 

[KurantRubys]

Vergiss gleich mal was du an Firewall im Controller einstellen kannst, der Punkt ist zwar da, macht aber nur was wenn auch ein UniFi USG dazwischen ist. Du siehst einfach alles was du einstellen kannst, auch ohne das die passende Hardware dazu da ist.

 

[Hexcode]

Ja dessen bin ich mir soweit ja bewusst (steht ja auch dran dass man ne USG braucht), dennoch wird mir nicht klar, warum der AP scheinbar die eingehenden Pakete aus meinem Netz für die Clients wegwirft...

 

[hominidae]

kannst Du auf dem NAS auch den UniFi Controller laufen lassen?
Mein erster Impuls war "AP-Isolation Mode", aber der sollte nur verhindern, dass die Clients sich untereinander sehen.
Aber ich vermute das Du entweder irgendwas in der Guest-Policy aktiviert hast oder ähnliches.

 

[Hexcode]

Der Unifi Controller ist auf dem NAS installiert als Debian Package.
Wie gesagt das ist halt das was mich irritiert - Ich hab nichts dergleichen konfiguriert... also wenn muss es Default-Setting gewesen sein.

 

[fdsonne]

Irgend ne ACL Beschränkung auf den Zielgeräten?
Weil wenn es vom 179er über den Tunnel in das 178er Netz geht - dann stimmen zumindest die Routingwege. Das MUSS also auch andersrum gehen.
Da es offenbar nicht geht - und der AP nichts blockt (bei mir zumindest OotB auch über verschiedenste Netze nicht) - bleibt eigentlich nur noch irgendwas auf der Client Seite... Oder wirklich irgendwelche komischen Settings auf dem AP.


Um das Problem aber tiefer zu troubleshooten solltest du erstmal alles an möglichen Fehlerquellen ausschließen. Schnapp dir bspw. mal nen PC mit ner Virtualisierungssoftware drauf und pack da drauf nen abgespeckten Mini Router und von mir aus ne VM von der aus zu testen kannst. Dann gehst du bei Mutti ins Netz und trägst ne Statische Route auf der FB für deine Router VM ein und dessen internen Netz ein - das simuliert dir den Zugriff außerhalb des eigenen Netzes und schließt die FB, den Tunnel und irgendwas bei dir im Netzwerk aus...
Wenn das schon nicht geht, dann nimmst du dir den AP mal konkret vor.

Ich kenne die FB-VPN Geschichten nicht, keine Ahnung ob da nicht vllt die FB noch irgendwo mit NAT drin rum fingert. Oder vllt auch so Themen wie IPv6 und DNS oder Namensauflösung allgemein dir da drin rum fingern...
Dass der Zugriff aus dem eigenen Netz (geproxyt) geht, zeigt eigentlich nur, dass der AP generell erstmal auch Zugriff von der LAN Seite in Richtung WLAN durch lässt. Hier wäre bspw. interessant, wenn du dir mal die Logs ansiehst - mit welcher Source IP kommt der Client? Ne IP aus dem gleichen netz wie der Proxy steht? Oder ne 178er von dir?



PS: bei mir gibts da noch so nen Punkt Gastkontrolle oder so ähnlich - vllt hat der da was mit zu tun?? Soll angeblich Zugriff auf Netze steuern von den WLAN Gästen aus. Was auch immer genau mit Gast gemeint ist. Hast du da möglicherweise das Source Netz festgedreht und der Spaß wirkt generell auf ALLE Clients im WLAN?

 

[hominidae]

nö, ich sehe das auch so...Default sollte so einen Effekt eben nicht haben.
Aber wenn Du übers VPN schon bis zum NAS kommst und über den Proxy auf die W-Clients, scheidet die Fritte mMN als Ursache aus.
Ich bin jetzt nicht so firm in der Controller UI...aber der Effekt tritt doch wohl ein, wenn die Source-IP in einem anderen Netz ist.
Da kommen nur VLANs oder Giuest-Policy in Frage, die den AP zu sowas "zwingen"...was anderes fällt mir nicht.

...man kann ja im AP das Logging aktivieren und über den Controller anschauen...kann man da wenigstens was sehen, wenn man es auf "gewschätzig" einstellt?

 

[p4n0]

Kann man auf der Fritte keinen TCP Dump anschmeißen? Soweit ich weiß ging das irgendwo mal in den Experteneinstellungen.
Daraus koennte man schlauer werden.

 

[fdsonne]

Aber wenn Du übers VPN schon bis zum NAS kommst und über den Proxy auf die W-Clients, scheidet die Fritte mMN als Ursache aus.

Kann man so einer Fritzbox irgendwie ALCs beibringen?
So nach dem Motto PVLAN/Port Isolation? Das würde möglicherweise erklären, warum der Zugriff auf den Proxy geht - denn der Traffic kommt ja aus der FB, weil vom Tunnel und geht zu einem direkt angeschlossenen Gerät. Während der Zugriff zu einem WLAN Gerät nicht zu einem direkt angeschlossenen Gerät geht sondern über den WLAN AP.


Die Idee von p4n0 wäre auch noch ne Option, allerdings sieht man dort ja dann "nur" die Sicht der FB - wenn ich das richtig sehe kommt der Spaß da ja definitiv an. Ob damit Tunnel to Inside Traffic sichtbar ist, weis ich allerdings nicht...
Man müsste eigentlich auf dem WLAN AP sniffern, respektive den Uplink Port des WLAN APs capturen - aber ich glaube der AP kann das nicht???
Ansonsten wäre es noch ne Option auf dem Client zu sniffern und zu schauen, ob am Client überhaupt Pakete ankommen oder ob diese vorher schon weg gefiltert sind - weil möglicherweise gehen auch einfach nur die Rückpakete verlustig... DAS würde man mit nem Trace auf dem Client zumindest sehen.
Ein WLAN Adapter im Promiscuous Mode wäre auch hilfreich - dürften aber die wenigsten Zuhause haben...

 

[p4n0]

Sollte hiermit klappen:
SSH auf den AP. Rest sollte selbsterklaerend sein.


Alle notwendigen Werkzeuge sind verfuegbar.

 

[Hexcode]

Das ist ja lustig... ich habe exakt NICHTS geändert und das Problem hat sich in Luft aufgelöst.
Plötzlich als ich mit per SSH von hier (das ging problemlos) auf dem AP war und

tcpdump src 192.168.178.141 and dst not 192.168.179.4 -n -vvv

probiert habe ging der Ping durch und im Anschluss auch die Port 80 Anfragen...
Sehr merkwürdig.

Das Aktivieren von SSH auf dem AP hat ja den AP neu provisioniert. Evtl. lag es ja daran, dass da irgendwo was im argen war.

//Edit: Zu Früh gefreut... es klappt nicht bei allen Geräten.
Wobei diese an und für sich den PING-Request bekomme, der nur nicht mehr bei mir ankommt.

BZ.v3.9.19# tcpdump src 192.168.178.141 and dst not 192.168.179.4 or dst 192.168.178.141 and not src 192.168.179.4 -n -vvv
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:28:14.399488 IP (tos 0x0, ttl 126, id 16174, offset 0, flags [none], proto ICMP (1), length 60)
192.168.178.141 > 192.168.179.38: ICMP echo request, id 1, seq 25, length 40
17:28:14.414059 IP (tos 0x0, ttl 64, id 46747, offset 0, flags [none], proto ICMP (1), length 60)
192.168.179.38 > 192.168.178.141: ICMP echo reply, id 1, seq 25, length 40
17:28:19.004867 IP (tos 0x0, ttl 126, id 16202, offset 0, flags [none], proto ICMP (1), length 60)
192.168.178.141 > 192.168.179.38: ICMP echo request, id 1, seq 26, length 40
17:28:19.022448 IP (tos 0x0, ttl 64, id 46748, offset 0, flags [none], proto ICMP (1), length 60)
192.168.179.38 > 192.168.178.141: ICMP echo reply, id 1, seq 26, length 40
17:28:24.032679 IP (tos 0x0, ttl 126, id 16217, offset 0, flags [none], proto ICMP (1), length 60)
192.168.178.141 > 192.168.179.38: ICMP echo request, id 1, seq 27, length 40
17:28:24.033544 IP (tos 0x0, ttl 64, id 46749, offset 0, flags [none], proto ICMP (1), length 60)
192.168.179.38 > 192.168.178.141: ICMP echo reply, id 1, seq 27, length 40
17:28:29.020574 IP (tos 0x0, ttl 126, id 16227, offset 0, flags [none], proto ICMP (1), length 60)
192.168.178.141 > 192.168.179.38: ICMP echo request, id 1, seq 28, length 40
17:28:29.021435 IP (tos 0x0, ttl 64, id 46750, offset 0, flags [none], proto ICMP (1), length 60)
192.168.179.38 > 192.168.178.141: ICMP echo reply, id 1, seq 28, length 40

Auch interessant:

BZ.v3.9.19# ping 192.168.178.1
PING 192.168.178.1 (192.168.178.1): 56 data bytes
64 bytes from 192.168.178.1: seq=0 ttl=63 time=24.662 ms
64 bytes from 192.168.178.1: seq=1 ttl=63 time=23.648 ms

aber

BZ.v3.9.19# ping 192.168.178.141
PING 192.168.178.141 (192.168.178.141): 56 data bytes

kommt nicht durch...

Klingt für mich irgendwie danach als wäre es doch nicht der AP schuld. Ich muss gleich mal hier mithören, ob hier das Paket am Rechner ankommt wenn der AP pingt.

//Edit: OK Ping aus dem anderen Netz hier rüber wurde von der Windows-Firewall geblockt... Nachdem die deaktiviert wurde gehts. Dennoch klappen die Port 80 Anfragen ins andere Netz nicht. Bzw. jetzt bei 2 von 4 Kameras.

//Edit: Ich sehe beim mitschneiden von eth0 auf der Fritzbox 179 auch die Anfragen von mir in Richtung der Kamera, die Antwort wird auch generiert - kommt aber nicht an, was scheinbar zu beidseitigen Retransmissions führt. Leider lässt sich weder an der 179er Box als an meiner 178er Box das tunl0 mitschneiden.

//Edit: an der 178er sieht man auf eth2 (da hängen hier die Geräte dran) nur die Anfragen in Richtung 179er Netz, jedoch keine Antwortpakete mehr. Scheint also als ob die 178er Fritzbox die verwirft oder nicht in den Tunnel steckt.
Stellt sich mir gerade echt die Frage: Warum geht es bei einigen Geräten und bei einigen nicht... die Config ist für alle erstmal die gleiche.

 

[p4n0]

Evtl nen arpcache der dazwischenfunkt?
Starte mal die FB und alle WLAN Clients die nun am UAP haengen neu.

 

[fdsonne]

//Edit: Ich sehe beim mitschneiden von eth0 auf der Fritzbox 179 auch die Anfragen von mir in Richtung der Kamera, die Antwort wird auch generiert - kommt aber nicht an, was scheinbar zu beidseitigen Retransmissions führt. Leider lässt sich weder an der 179er Box als an meiner 178er Box das tunl0 mitschneiden.

//Edit: an der 178er sieht man auf eth2 (da hängen hier die Geräte dran) nur die Anfragen in Richtung 179er Netz, jedoch keine Antwortpakete mehr. Scheint also als ob die 178er Fritzbox die verwirft oder nicht in den Tunnel steckt.
Stellt sich mir gerade echt die Frage: Warum geht es bei einigen Geräten und bei einigen nicht... die Config ist für alle erstmal die gleiche.

Wie ist der Tunnel genau konfiguriert?
Baut die FB vllt für jeden Host ne eigene SA? Oder ist das das ganze Netz?
Würde es ne eigene SA pro Host sein, könnte es schon sein, dass da so manches Paket einfach nicht in den Tunnel geschickt wird, weil die SA nicht steht... -> und dann einfach der default Route folgend public raus geht.

-> um genau solche Themen auszuschließen war oben mein Rat, schnapp dir nen lokalen Client in einem anderen Netz (Router VM + VM Client hinter diesem virtuellen Router) und schließ dieses Tunnel-FB-Frickelzeugs aus. (Ja ich bin kein Freund von diesen FB-Büchsen)

 

[Hexcode]

Ich hab gerade alle beteiligten Geräte neu gestartet - das ändert nichts daran, dass einige Geräte jetzt erreichbar sind und andere nicht

 

[p4n0]

@Hexcode: Gibts n Update wo der Hund begraben lliegt oder hoffentlich lag?

 

[Hexcode]

Leider nicht - hab Studiumsbedingt gerade keine Zeit da weiter nach zu schauen. Solange ich mit dem Proxy als Übergangslösung rein komme, muss das erstmal reichen.