VPN Site to Client eine IP-Adresse aus einem der lokalen Netzwerke

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

Antworten
akoujan
Beiträge: 5
Registriert: 21 Jun 2024, 17:08

VPN Site to Client eine IP-Adresse aus einem der lokalen Netzwerke

Beitrag von akoujan »

Hallo zusammen,

ich habe bei einer UF-60 VPN`s Site to Client eingestellt. Habe eine Virtuelle IP vergeben und dann eine Route auf das lokale Netzwerk in der Routen Tabelle 254 eingestellt.
Interface: VPN-Test
Ziel: 192,168.200.0/24
Gateway: leer
Typ: unicast

Die Virtuelle IP-Adresse ist eine freie IP vom lokalem Netzwerk das erreicht werden soll.

Kann per ping das Netzwerk erreichen. Nur hat die virtuelle IP keine Verbindung zum lokalem Netzwerk.
Habe die VPN`s mit dieser Anleitung https://knowledgebase.lancom-systems.de ... =167673974 erstellt.
Nur verstehe ich den Satz nicht richtig:
Soll dem VPN-Client eine IP-Adresse aus einem der lokalen Netzwerke statt einer Adresse aus dem Virtuellen IP-Pool zugewiesen werden (über das Feld Virtuelle IP), muss Routen-basiertes IPSec verwendet und in der Routing-Tabelle 254 eine Route für das VPN-Interface erstellt werden, welche auf die virtuelle IP-Adresse im lokalen Netzwerk verweist.
nibbleminx
Beiträge: 13
Registriert: 03 Sep 2024, 18:19

Re: VPN Site to Client eine IP-Adresse aus einem der lokalen Netzwerke

Beitrag von nibbleminx »

Bei Routen-basiertem IPsec erzeugt die Firewall ein virtuelles, sogenanntes xfrm Interface.

Das Heißt:
Alles was ins VPN geht, oder von dort kommt, geht von oder zu diesem "internen" Interface. Für die Firewall selbst ist das xfrm Interface oberflächlich betrachtet, dann nichts anderes mehr als eine reguläre Ethernet-Schnittstelle

Wenn nun das VPN mit dem selben Subnetz arbeiten soll, wie das lokale LAN, würde man Probleme beim Routing bekommen.

Beispiel:
1. xfrm1 192.168.0.0/24
2. eth1 192.168.0.0/24


Sagen wir es kommt jetzt ein Paktet über eth2, das die Ziel-IP 192.168.0.5 hat, dann kann das Paket nicht mehr korrekt greoutet werden. Es gibt plötzlich 2 Interfaces, an denen das Ziel anliegt. Im Zweifel kann man sich damit sogar aus seinem eigenen LAN aussperren, weil die xfrm-Regel als erstes gegriffen hat. Anstatt den lokalen Router erreichen zu können, geht plätzlich alles ins VPN. (passiert auch den besten Admins mal... :wink: )

Um das zu verhindern wird also eine Interface-spezifische Route für ein kleineres Subnetz (in dem Fall eine einzel IP) benötigt, damit wieder ein eindeutiges Routing vorliegt.

Beispiel:
1. xfrm1 192.168.0.5 (/32)
2. eth1 192.168.0.0/24

Wenn nun ein Paket von eth2 kommt und die Ziel-IP 192.168.0.5 hat, dann wird das von der Firewall ins VPN (also aufs xfrm Interface) geroutet werden, denn: Je größer die Subnetzmaske ist, umso höher wird der Routing-Eintrag priorisiert.
Wenn ein Paket von eth2 kommt und bspw. die Ziel-IP 192.168.0.6 hat, matcht Regel 1 nicht mehr. Dafür matcht jetzt aber routing Regel 2 und das Paket geht auf eth1 raus. Ergo, hat man sich damit nichtmal aus dem LAN ausgesperrt.

Trivia: 0.0.0.0/0 also Alles (kleinste Subnetzmaske) wird am geringsten priorisiert, deshalb geht das, was man lokal nicht durch spezifischere Regeln erreichen kann, letztlich ins Internet raus... :)

Soviel zum Verständnis von dem Satz.

Was ich aber niemals verstehen werde ist, warum man eine lokale IP im VPN haben wollen will. Die Firewall routet doch eh zwischen beliebigen anliegenden Netzen (sofern es auch eine erlauben Regel dafür gibt). Also kann man das m.E. auch gleich auf dem Standardweg machen und sich den zusätlzichen Administrationsaufwand mit den manuellen Routing-Einträgen, sparen. Das dürfte auf dauer besser skalieren und weniger Nerven kosten.
:arrow: Better safe than sorry. Erst das Backup, danach alles Andere
Antworten