[Frage] VPN Hostbeschränkung klappt nicht

[geohei]

Hallo.

Bräuchte dringend Hlfe bzgl. AVM VPN Config.

2x FB7390 FW 06.83.

Ich möchte 2 LANs verbinden.
Klappt auch perfekt.

Jetzt will ich den Zugriff des einen LAN auf nur ein gerät beschränken.
Geht das?

Ich habe Folgendes probiert:

LAN 1 (192.168.111.0)

accesslist = "permit ip any 192.168.222.0 255.255.255.0";

LAN 2 (192.168.222.0)

accesslist = "permit ip 192.168.222.3 255.255.255.255 192.168.111.0 255.255.255.0";

Ich dachte dass ich aus LAN 1 nur Zugriff auf Host 192.168.222.3 in LAN 2 habe.
Klappt aber nicht.

Wo ist der (Denk)fehler?

 

[PeterPawn]

Die "accesslist" in LAN2 gilt erst für den "Rückweg" der Pakete, weil die Pakete trotzdem von LAN1 nach LAN2 gehen würden. Da gehört also in LAN1 ein Eintrag in die "accesslist", der nur den Zugriff auf die 222.3 gestattet und das ist einer, der eine /32-Maske hat und keine /24, denn daran krankt die zweite "accesslist" - aber die würde auch mit der korrekten Maske eben nur dafür sorgen, daß nur die Antworten von der 222.3 das LAN1 erreichen und niemanden in LAN1 davon abhalten, irgendwelche Datenpakete an beliebige Clients in LAN2 zu senden - auch wenn die halt nicht richtig antworten können.

Für "Sicherheit" ist das aber schon ein Problem, wenn man "blind" irgendein Paket senden kann - das verhindert dann die passende "accesslist" in LAN1 gleich mit.

 

[geohei]

Man findet sehr wenig Infos über diesen Parameter der AVM VPN Config.
Hast du Quellen wo alle möglichen Optionen erklärt sind?
Da gibt es auch noch "reject" anstatt "permit". Was gibt es sonst noch?
In welcher Reihenfolge bzw. nach welchen Regeln werden die Optionen abgearbeitet?
...
Ohne diese Infos ist dieser Parameter für mich nichts anderes als ein Schuss aus der Hüfte.

So wie ich jetzt deine Erklärung des accesslist Parameters verstehe, beschränkt dieser nur die "Antworten" vom remote network (nachdem ich den eine "Frage" gestellt habe). Ich kann also an das remote network schicken was ich will (und es kommt auch an), aber mit meiner accesslist beschränke ich nur die "Antworten" des remote network.

Wenn dem so ist, dann sehe ich nicht was der Sinn und Zweck dieser Einschränkung sein soll, und welchen Anwendungszweck sie möglicherweise hat.

Ist es nicht möglich, mit accesslist die "Fragen" an das remote network einzuschränken?

Ich will einfach nur, dass von LAN 1 nur 192.168.222.3 (in LAN 2) erreichbar ist ("Fragen" und "Antworten"). Alle anderes hosts in LAN 2 sollen für LAN 1 nicht erreichbar sein.

Das muss doch möglich sein, oder?

 

[Shirocco88]

Ich will einfach nur, dass von LAN 1 nur 192.168.222.3 (in LAN 2) erreichbar ist ("Fragen" und "Antworten"). Alle anderes hosts in LAN 2 sollen für LAN 1 nicht erreichbar sein.

das läßt sich mit "Whitelist-Methode", d.h. "permit" Directiven bewerkstelligen:

Fritzbox1 (192.168.111.0):

accesslist = "permit ip 192.168.111.0 255.255.255.0" 192.168.222.0 255.255.255.0";

Fritzbox2 (192.168.222.0):

accesslist = "permit ip 192.168.222.3 255.255.255.255 192.168.111.0 255.255.255.0";

"reject" Directiven ("Blacklist-Methode") sind IMHO nicht erforderlich.

 

[PeterPawn]

@geohei:
Das ist aber wirklich oft genug schon erklärt ... die Kurzform lautet einfach, daß der Name "accesslist" ggf. dahingehend verwirrend ist, als er so klingt, daß man darüber auch irgendeinen Zugriff (access) reglementieren könnte. In Wirklichkeit legt der nur die Filterkriterien fest, anhand derer entschieden wird, ob ein bestimmtes lokales Datenpaket verschlüsselt über das VPN geht (wenn es hier "ausgewählt" wurde in der "accesslist") oder ganz normal (ohne weitere Verschlüsselung) über das WAN-Interface. Andererseits ist diese Syntax ja auch nicht nur bei AVM in Gebrauch ... sie hat schon erhebliche Ähnlichkeiten mit dem, was in Cisco's IOS verwendet wurde (und wird).

Aber insofern hast Du das schon richtig verstanden ... da diese Filter tatsächlich nur festlegen, ob ein Paket aus dem LAN nun über das VPN oder WAN geht und keinerlei Einfluß darauf haben, was von der Gegenseite über den Tunnel gesendet wird und ob das nach dem Entschlüsseln in der lokalen Box dann weiterverteilt wird (das kann ja - je nach Zieladresse - wieder Traffic für das LAN, das WAN oder auch einen anderen VPN-Tunnel sein), muß man dem Peer schon so weit vertrauen können, daß der keinen Traffic sendet, den man nicht will.

Wenn man wenigstens dem Admin des Peers so weit vertrauen kann, daß der auf seiner Seite die Filterregeln so gestaltet, daß nur Traffic für den einen erlaubten Host im eigenen LAN auch in den VPN-Tunnel gelangt, ist eigentlich auch wieder "alles gut", weil nicht irgendein wildgewordener LAN-Client aus dem entfernten Netz irgendwelchen Quatsch senden kann ... der landet dann ja bei passenden Filterregeln gar nicht erst im Tunnel und in der Folge nicht im eigenen LAN.

Kann man schon dem (Remote-)Admin nicht trauen, baut man keinen VPN-Tunnel auf oder isoliert das lokal über den Tunnel erreichbare Netz vom Rest des eigenen LAN (das können die Boxen mit mehreren LAN-Ports auch). Dann ist das (VPN-Ziel-)Netz zwar auch von lokal nicht mehr problemlos erreichbar, aber das ist nun mal der Preis der Isolation und da ist jede "Ausnahme" dann automatisch auch eine Schwachstelle. Ein Beispiel wäre z.B. ein EC-Karten-Terminal, das per VPN-Tunnel direkt mit dem Zahlungsdienstleister kommunizieren soll und das man nicht unbedingt im eigenen LAN will (weil man es weder selbst konfigurieren kann, noch in der Lage ist, dessen Netzwerkzugriffe (auf andere eigene Geräte) effektiv zu überwachen).

 

[geohei]

@Shirocco
Bevor ich auf dein Posting #4 eingehe, möchte ich noch Folgendes fragen:

Aus den Beispielen hier und im Internet glaube (?!) ich jetzt Folgendes verstanden zu haben.

1. Die accesslist kontrolliert nur die Antworten der Geräte in den VPN Tunnel. Die Fragen an die Hosts können nicht kontrolliert werden. Die erreichen die Hosts immer. M.a.W. ... accesslist kontrolliert nur was in den VPN Tunnel darf, nicht was aus dem Tunnel ins lokale LAN darf. Ist das korrekt?

2. Im einzigen (!) Netzwerk (192.168.111.0/24) kann man entweder "192.168.111.0 255.255.255.0" oder "any" in accesslist eintragen. Das ist identisch. "any" würde eigentlich mehr 0.0.0.0/32 entsprechen. Korrekt?

3. accesslist = "permit ip <ip/mask 1> <ip/mask 2>"
<ip/mask 1> ist ein lokaler Host, welches Antworten zu <ip/mask 2> zulässt. Korrekt?

4. Kann man nicht auch beschränken, was aus dem Tunnel ins LAN zugelassen wird und was nicht?

@PeterPawn
Deine Antwort hat sich mit meiner (#5) gekreuzt. Werde mir das später ansehen. Sorry. Danke!

 

[Shirocco88]

1. Die accesslist kontrolliert nur die Antworten der Geräte in den VPN Tunnel. Die Fragen an die Hosts können nicht kontrolliert werden.
Die erreichen die Hosts immer. M.a.W. ... accesslist kontrolliert nur was in den VPN Tunnel darf, nicht was aus dem Tunnel ins lokale LAN darf.
Ist das korrekt?

Die Accesslist selektiert den Netzwerk-Traffic, der in den Tunnel geschickt werden soll; dazu wird Matching der Frames basierend, auf Protokoll-Art (ip, udp, tcp), Source-IP, Destination-IP durchgeführt.

2. Im einzigen (!) Netzwerk (192.168.111.0/24) kann man entweder "192.168.111.0 255.255.255.0" oder "any" in accesslist eintragen. Das ist identisch. "any" würde eigentlich mehr 0.0.0.0/32 entsprechen.
Korrekt?

Theoretisch entspricht "any" der "0.0.0.0 0.0.0.0", d.h. alle Unicast-Pakete (keine Multi-Cast/Broadcast) werden hier gematched;
Hinweis: "accesslist = permit ip any any" ist zu vermeiden, da hier ohne ergänzende "deny" rules für div. Pakete (dns, ipsec, ...) der Betrieb (VPN-Aufbau usw.) gestört ist.

3. accesslist = "permit ip <ip/mask 1> <ip/mask 2>"
<ip/mask 1> ist ein lokaler Host, welches Antworten zu <ip/mask 2> zulässt.
Korrekt?

siehe 1.), "ip <ip/mask 1> <ip/mask 2>" arbeitet als Selector

4. Kann man nicht auch beschränken, was aus dem Tunnel ins LAN zugelassen wird und was nicht?

Nein;
diese Einschränkung liegt dem IPsec-Protokoll zugrunde, d.h. Unabhängig von der Impementierungen z.B. CISCO, AVM, shrewsoft, ...

 

[geohei]

Mit diesen Erklärungen (#5 & #7) habe ich es jetzt genau so zum Laufen gebracht was ich wollte. Vielen Dank!

Habe trotzdem noch einige Fragen.

1.
Also kann ich aus LAN 1 auch Geräte ansprechen, die in der LAN 2 "accesslist permit ..." nicht erlaubt sind? Die Pakete kommen dann beim LAN 2 / Client an, nur ich sehe die Antwort nicht, weil die LAN 2 accesslist die Antwort in den VPN Tunnel verweigert. Ist das nicht ein Sicherheitsrisiko für die Geräte im LAN 2?

2.

Theoretisch entspricht "any" der "0.0.0.0 0.0.0.0", d.h. alle Unicast-Pakete (keine Multi-Cast/Broadcast) werden hier gematched;

Liegt es da dran, dass ich meine Sonos Soundanlage nicht über VPN erreiche (wenn ausserhalb des WLAN)?
Kann ich das nicht auch irgendwie bewerkstelligen?

Hinweis: "accesslist = permit ip any any" ist zu vermeiden, da hier ohne ergänzende "deny" rules für div. Pakete (dns, ipsec, ...) der Betrieb (VPN-Aufbau usw.) gestört ist.

Ich nehme an die accesslist ist keine AVM Erfindung.
Gibt es weiterführende Dokumentation diesbezüglich? Ich würde mir das mit den deny rules auch gerne ansehen.
Auch warum "permit ip any any" deny rules für Port 53, ... benötigt.

Ich würde gerne wissen welche Optionen die accesslist insgesamt anbietet.
Da stecken bestimmt noch Möglichkeiten drin für die ich Verwendung habe.

5.
Im Internet findet man öfters das hier:

...
conn_type = conntype_user;
...
remote_virtualip = 192.168.100.203;
...
accesslist = "permit ip 192.168.100.0 255.255.255.0 192.168.100.203 255.255.255.255",
             "permit ip any 192.168.100.203 255.255.255.255";

Warum benötigt man überhaupt "permit ip 192.168.100.0 255.255.255.0 ..." wenn es ja schon "permit ip any ..." gibt?

 

[PeterPawn]

Logisch, das ist ein Sicherheitsrisiko für LAN2, deshalb baut man dann keinen Tunnel zu einem solchen Netz (als LAN1) auf (zumindest nicht mit einer FRITZ!Box, sondern nur mit einem Gerät, was den Traffic aus dem Tunnel zusätzlich filtern kann), wenn man nicht darauf vertrauen kann, daß da kein unerwünschter Traffic kommt.

Auch ohne den Rückweg kann ein Client in LAN1 ein UDP-Paket an irgendeine beliebige Internet-Adresse absetzen und das landet dann - wenn das die Filterregeln in LAN1 in den VPN-Tunnel zu LAN2 stecken - bei diesem Empfänger auch (nach NAT in der Box in LAN2) mit der öffentlichen IP-Adresse von LAN2. Damit kann man allen möglichen Unsinn anstellen ... vom "flooding" der externen Adresse und des internen Netzes von LAN2 durch (nicht angeforderte) Antworten (denn die kommen dann tatsächlich wieder durch die Firewall, weil ja das ausgehende Paket das Loch gebohrt hat und das mit der "Absenderadresse" des ursprünglichen UDP-Pakets) bis zu DoS-Attacken, die halt von der "falschen" öffentlichen IP-Adresse zu kommen scheinen. Nun ist es bei UDP zwar ohnehin leicht, den Absender eines Pakets zu fälschen ... trotzdem gibt es ja auch UDP-basierte Anwendungen (z.B. syslog auf UDP 514), wo tatsächlich der Traffic nur in einer Richtung fließt.