Beiträge von itvnb

grundsaetzlich sind wol-pakete nicht auf dem layer 3 (tcp/udp) sondern auf dem layer 2 (ip) unterwegs, was grundsaetzlich bedeutet, dass sie nicht zwischen vlans (sind layer 2 domaenen) ausgetauscht werden... die magic packets werden entweder an eine mac-adresse in der gleichen layer 2 domaene oder an den broadcast (ff:ff:ff:ff:ff:ff) der eigenen layer 2 domaene adressiert und normalerweise nicht gerouted...

was ich jetzt nicht genau weiss, ob die udm da spezielle regeln fuer wol magic packets hat, die den pakettyp erkennen und entsprechend weiterleiten, wenn ja muss aber auch sichergestellt sein, dass nach dem routen die pakete auf layer 2 wieder an die broadcast-mac gesendet werden (vgl. beispiel fuer eine fortigate firewall: https://community.fortinet.com…-FortiGate-in/ta-p/198103)...

ich würde mal klassisch auf die "rückroute" tippen, weiß deine fritzbox, dass sie die antwortpakete für das netz 10.20.0.0/16 an die usg zurückschicken muss (statische route auf der fb)? sonst schickt sie die nämlich an ihre standardroute (internet)... das ist der nachteil, wenn man doppeltes nat vermeiden will...

versuche es mal mit einer statischen route

10.20.0.0/16 via 192.168.0.2

auf der fritzbox...

gruß Nils

keiner?

moin zusammen,

ich betreue auch einige größere wlan-systeme und es kommen immer mal wieder problemmeldungen beim verbindungsaufbau von geräten einzelner hersteller (vor allem google pixel). bekannt ist, dass google im android stock-rom vor einiger zeit änderungen vorgenommen hat, dass man die zertifikatsvalidierung bei der verbindung mit einer wpa2-enterprise ssid nicht mehr "umgehen" kann. da mag man von halten was man will, aber irgendwie muss das ganze ja funktionieren...

konkret sieht das system folgendermaßen aus:

android-client -> uap-ac-hd -> (unifi-controller) -> radius-server

der radius-server präsentiert ein wildcard-zertifikat von letsencrypt, beim verbindungsaufbau wird eine zum zertifikat passende domain angegeben, aber nach einer ungemessenen zeitspanne schlägt der verbindungsaufbau mit einer meldung wie "verbindung fehlgeschlagen" fehl, ohne irgendeinen logeintrag im controller...

ich kenne den genauen ablauf des handshakes android-client <-> uap-ac-hd <-> radius-server nicht genau und vor allem nicht, an welcher stelle das zertifikat ins spiel kommt. aus meiner erfahrung bei anderen verschlüsselten verbindungen (z.b. web), sollte der ap beim radius-server eine authentifizierungsanfrage stellen, was im controller nur als (in diesem fall interne) ip-adresse an zu geben ist, dann präsentiert der radius-server das zertifikat, das für eine domain mit allen subdomains ausgestellt ist, was logischerweise die angefragte ip-adresse nicht enthält (enthalten kann/darf) und die verifizierung des zertifikats schlägt fehl...

hat jemand erfahrung in diesem bereich oder es bestenfalls schon mal so in betrieb genommen, denn ich kann nicht wirklich hilfreiche informationen dazu finden?

danke und gruß

Nils

moin,

ich bin mir gerade nicht ganz sicher, was du mit "Domain Name ihr in euren Subnetzen" meinst... simple namensauflösung in einem abgetrennten netzwerkbereich oder eine richtige windows-domäne (=active-directory-domäne) mit allem was dazu gehört?

was immer funktioniert, wenn man eine öffentliche domain sein eigen nennt, ist split-dns, also das lokale "abtrennen" einer subdomain für einen bestimmten zweck (hier namensauflösung in einem lokalen netzbereich, bzw. eine windows-domäne), die extern nicht aufgelöst werden kann (oder muss).

ich kenne diese aussagen auch, warum man .local nicht als lokale tld verwenden sollte... das einzige szenario in dem es mir in der praxis begegnet ist, ist m$ azure bzw. exchange online in verbindung mit einer lokalen wiindows-domäne (azure-ad-sync), aber auch dafür gibt es lösungen...

ich habe es immer pragmatisch gehalten, wenn ich mir sicher war, dass es nur für eine lokale namensauflösung verwendet wurde und keine externen anbindungen geplant waren (100% meiner fälle), sprach nichts gegen eine .local-domain (wenn es sich überhaupt gelohnt hat, für ein lokales netz ohne ad eine vollständige namensauflösung ein zu richten )... für alle anderen fälle habe ich den vorteil eine eigene öffentliche domain mein eigen zu nennen und die meisten kunden bei denen die frage aufkam auch...

grundsätzlich funktioniert auch heute noch, was die letzten 10 oder 15 jahre funktioniert hat, nimm eine .local-domain (oder jede beliebige andere tld) und lass es darauf ankommen... sollte dir der fall unterkommen, dass doch eine öffentliche domain erforderlich ist, ist es bei einem netz ohne ad schlimmstenfalls fleißarbeit, das zu ändern (gut und zentral konzipiert, wären aber auch nur dhcp- und dns-server betroffen) und beim ad gibt es wege die öffentliche domain zu integrieren...

just my 2 ct

gruß Nils

genau das war das problem, zufügen einer regel für related und established und alles klappt wie es soll...

danke noch mal fürs mitdenken...

da ist was dran... vielen dank schon mal, das werde ich morgen mal testen...

Zitat von gierig

Local ist nunmal für Verbindungen von oder zu dem Router direkt.

[...]

so war auch mein verständnis...

Zitat von gierig

[...]

aber ohne Einsicht in die Regeln kann ist das aber schwer zu beurteilen..

das sind die drei regeln, die ping, openvpn und dns erlauben sollten (das waren auch die einzigen regeln in diesem regelsatz):

 name WAN_LOCAL {
     default-action drop
     description ""
     rule 1 {
         action accept
         description ping
         log disable
         protocol icmp
         state {
             established disable
             invalid disable
             new enable
             related disable
         }
     }
     rule 2 {
         action accept
         description openvpn
         destination {
             port 1194
         }
         log disable
         protocol udp
         state {
             established disable
             invalid disable
             new enable
             related disable
         }
     }
     rule 3 {
         action accept
         description dns
         destination {
             port 53
         }
         log disable
         protocol tcp_udp
         state {
             established disable
             invalid disable
             new enable
             related disable
         }
     }
 }

hallo community,

ich habe mal eine frage zu den firewall-regeln (und regelsätzen) bei einem edge-router (in diesem fall ein er-12). nach dem der router jetzt in den produktiv-einsatz überführt werden soll, möchte ich noch alle netze trennen (was grundsätzlich auch funktioniert) und den zugriff richtung wan einschränken, wobei es bei mir grundsätzlich mit dem whitelist-prinzip realisiert wird, drop-policy und nur erlauben, was benötigt wird.

das einrichten der regelsätze für den gerouteten traffic (IN und OUT) funktioniert auch bei der wan-schnittstelle problemlos, nur sobald ich den LOCAL-regelsatz erstelle und an die wan-schnittstelle binde, ist keinerlei traffic vom router direkt richtung wan möglich, gemeint sind hier vor allem die lokale namensauflösung, ein- wie ausgehender ping und ausgehende vpn-verbindungen. entsprechende regeln für ping, dns oder openvpn mit state = new habe ich eingerichtet, das scheint ihn aber nicht wirklich zu interessieren.

habe ich hier irgendwas übersehen oder schlimmstenfalls falsch verstanden?

danke und gruß

Nils