Site-to-site VPN zw. AVM und pfsense mit öffentlichem Subnetz!
moinmoin ...
... ein site-to-site VPN zw. AVM und pfSense ist ja kein großes Hexenwerk nach dieser Anleitung hier 1
Problematisch wird es aber auf der AVM-Seite, wenn das Netz hinter der pfSense ein öffentliches Subnetz ist.
Ich weiss nämlich nicht, wie ich der Fritz-Box beibiegen soll, dass Anfragen an diese IPs immer durch den Tunnel wandern und nicht erst ins WWW?
Das VPN steht zw. (AVM) 192.168.10.0/24 und (pfSense) 79.45.159.160/29
Ein tracert von einem PC aus dem Netz der pfsense an ein Gerät im Netz der FritzBox läuft einwandfrei durch das VPN
tracert 192.168.10.1
Routenverfolgung zu SRVWH [192.168.110.1] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms 78.47.225.166
2 32 ms 27 ms 29 ms SRVTEST [192.168.10.1]
3 28 ms 30 ms 26 ms SRVTEST [192.168.10.1]
Umgekehrt jedoch klappt es nicht
tracert 79.45.159.161
Routenverfolgung zu srvtest2.mydomain.net [79.45.159.161] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms fritz.box [192.168.10.20]
2 * * * Zeitüberschreitung der Anforderung.
3 26 ms 30 ms 26 ms srvtest2.mydomain.net [79.45.159.161]
Via IP kann ich im Explorer über \\79.45.159.161\testshare auf die Freigabe zugreifen
... ein site-to-site VPN zw. AVM und pfSense ist ja kein großes Hexenwerk nach dieser Anleitung hier 1
Problematisch wird es aber auf der AVM-Seite, wenn das Netz hinter der pfSense ein öffentliches Subnetz ist.
Ich weiss nämlich nicht, wie ich der Fritz-Box beibiegen soll, dass Anfragen an diese IPs immer durch den Tunnel wandern und nicht erst ins WWW?
Das VPN steht zw. (AVM) 192.168.10.0/24 und (pfSense) 79.45.159.160/29
Ein tracert von einem PC aus dem Netz der pfsense an ein Gerät im Netz der FritzBox läuft einwandfrei durch das VPN
tracert 192.168.10.1
Routenverfolgung zu SRVWH [192.168.110.1] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms 78.47.225.166
2 32 ms 27 ms 29 ms SRVTEST [192.168.10.1]
3 28 ms 30 ms 26 ms SRVTEST [192.168.10.1]
Umgekehrt jedoch klappt es nicht
tracert 79.45.159.161
Routenverfolgung zu srvtest2.mydomain.net [79.45.159.161] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms fritz.box [192.168.10.20]
2 * * * Zeitüberschreitung der Anforderung.
3 26 ms 30 ms 26 ms srvtest2.mydomain.net [79.45.159.161]
Via IP kann ich im Explorer über \\79.45.159.161\testshare auf die Freigabe zugreifen
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 278755
Url: https://administrator.de/contentid/278755
Ausgedruckt am: 24.11.2024 um 05:11 Uhr
6 Kommentare
Neuester Kommentar
Eigentlich unsinnig, denn es kann technisch niemals sein das unterschiedliche Applikationen unterschiedliche Transportrouten auf dem gleichen System nutzen !
Auch das ein Ping von einer Seite geht, was ja zeigt das das Routing sauber funktioniert, von der anderen Seite aber nicht.
So ein asymetrisches Verhalten deutet fast immer darauf hin das im Tunnel selber unsinnigerweise NAT gemact wird (Blocking der NAT Firewall) oder die Firewall Regeln im Tunnel bzw. Tunnelinterface (pfSense Seite) falsch oder fehlerhaft gesetzt sind !!
Normal ist es völlig egal ob hinter der pfSense ein öffentliches Netz ist oder ein RFC 1918 IP Netz. IPsec announced die Route der lokalen Netze automatisch auf die Tunnelinterfaces.
Der Knackpunkt ist hier die Fritzbox....
Generell gilt im TCP/IP das die Route mit dem kleinsten, sprich dem spezifischstem Prefix die aktive sein muss !
Theoretisch hat die FB 2 Optionen das 79.45er Netz zu erreichen, einmal über die Default Route zum Provider und einmal über den Tunnel direkt.
Da die FB über den Tunnel eine /29er Maske propagiert bekommt ist diese der /0 Maske der Default Route überlegen und hat damit laut Standard eine höhere Priorität !
Die FB muss also diese Route per Definition nutzen und Traffic für das 79.45.159.160 /29 IP Netz zwingend in den Tunnel routen !!
Interessant wäre hier also mal die Routing Tabelle der Fritzbox zu sehen, denn die ist ganz klar der phöse Puhmann hier !
Ein bischen mehr debug Output wäre also hilfreich. Auch macht es Sinn mit -d beim Traceroute die Namensauflösung zu deaktivieren !
Auch das ein Ping von einer Seite geht, was ja zeigt das das Routing sauber funktioniert, von der anderen Seite aber nicht.
So ein asymetrisches Verhalten deutet fast immer darauf hin das im Tunnel selber unsinnigerweise NAT gemact wird (Blocking der NAT Firewall) oder die Firewall Regeln im Tunnel bzw. Tunnelinterface (pfSense Seite) falsch oder fehlerhaft gesetzt sind !!
Normal ist es völlig egal ob hinter der pfSense ein öffentliches Netz ist oder ein RFC 1918 IP Netz. IPsec announced die Route der lokalen Netze automatisch auf die Tunnelinterfaces.
Der Knackpunkt ist hier die Fritzbox....
Generell gilt im TCP/IP das die Route mit dem kleinsten, sprich dem spezifischstem Prefix die aktive sein muss !
Theoretisch hat die FB 2 Optionen das 79.45er Netz zu erreichen, einmal über die Default Route zum Provider und einmal über den Tunnel direkt.
Da die FB über den Tunnel eine /29er Maske propagiert bekommt ist diese der /0 Maske der Default Route überlegen und hat damit laut Standard eine höhere Priorität !
Die FB muss also diese Route per Definition nutzen und Traffic für das 79.45.159.160 /29 IP Netz zwingend in den Tunnel routen !!
Interessant wäre hier also mal die Routing Tabelle der Fritzbox zu sehen, denn die ist ganz klar der phöse Puhmann hier !
Ein bischen mehr debug Output wäre also hilfreich. Auch macht es Sinn mit -d beim Traceroute die Namensauflösung zu deaktivieren !