08.07.2019, aktualisiert am 11.07.2019

5514

Keine IP-Verbindung + Namensauflösung Fritzbox per VPN an SonicWall

Hallo Leute,
ich hoffe Ihr könnt mir helfen. Folgende Situation:

1. Zentrale
- SonicWall TZ400 (SonicOS Enhanced 6.5.3.1-48n) hinter einer Digitalisierungsbox Premium mit aktiviertem DynDNS
- seitens der Diggi-Box (192.168.178.1) sind alle Ports für VPN IPSec usw. auf die SonicWall (W0: 192.168.178.10) weitergeleitet
- hinter der SonicWall (Port X0: 192.168.120.254) steht im internen Netzwerk ein UCS-Server 4.4.0-errata mit DHCP/DNS (192.168.120.87). Im Menüpunkt VPN > DHCP over VPN > Send DHCP requests to the server addresses listed below, ist der UCS-Server eingetragen.

2. Außenstelle
- FritzBox 7490 (OS 7.11), IP: 192.168.179.1
- aktiviertes MyFritz
- VPN eingerichtet über Konfigdatei im Anhang

Bei der Einrichtung habe ich mich an folgenden Webseiten orientiert:
- https://blog.kopfteam.de/site2site-vpn-zwischen-fritzbox-und-sonicwall/
- https://www.xing.com/communities/posts/site2site-ueber-ipsec-sonicwall-f ...
- https://www.ip-phone-forum.de/threads/vpn-zwischen-fritzbox-und-sonicwal ...

Die gute Nachricht: Die VPN-Verbindung zwischen Außenstelle und Zentrale steht. Auf beiden Seiten leuchtet der Punkt im Konfig-Menü grün.

Die schlechte Nachricht: Man kann weder von der Außenstelle, noch von der Zentrale aus einen Rechner im jeweils gegenseitigem Netzwerk pingen oder deren Freigaben aufrufen.

Deshalb meine Fragen:
zuerst die blöde Frage: Müsste nicht die FritzBox vom DHCP-Server eine IP-Adresse aus dem Netzwerk der Zentrale (192.168.120.x) zugewiesen bekommen? Am DHCP-Server sehe ich aber keine FritzBox bzw. keine MyFritz-Adresse.
Oder läuft das so, dass sämtliche Anfragen aus dem Netz 192.168.179.y für der Netzwerk der Zentrale einfach bei der SonicWall auflaufen und diese sich um die „Übersetzung“ kümmert?
Oder muss ich die remote_virtualip an der FritzBox schon vorgeben?
Was habe ich falsch gemacht?

VPN-Konfig der Fritzbox:

/*
 * fritzbox_sonic.cfg
 */

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "blablabla.ddns.net";  
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "blablabla.ddns.net";  
                localid {
                        fqdn = "kauderwelsch.myfritz.net";  
                }
                remoteid {
                        fqdn = "blablabla.ddns.net";  
                }
                mode = phase1_mode_aggressive;
                phase1ss = "LT8h/all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "DaranHabeIchNaechtelangGegruebelt";  
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.179.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.120.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-3des-sha/ah-no/comp-no/no-pfs";  
                accesslist = "permit ip 192.168.179.0 255.255.255.0 192.168.120.0 255.255.255.0";  
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",   
                            "udp 0.0.0.0:4500 0.0.0.0:4500";  
}


// EOF

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 470921

Url: https://administrator.de/contentid/470921

Ausgedruckt am: 22.11.2024 um 15:11 Uhr

17 Kommentare

Neuester Kommentar

zuerst die blöde Frage: Müsste nicht die FritzBox vom DHCP-Server

Blöde Fragen gibt es nicht nur blöde Antworten...

Die Antwort lautet nein !
DHCP spielt bei IPsec VPNs und ihrer Adress Vergabe keinerlei Rolle. Da DHCP mit UDP Broadcasts funktioniert rennt sowas auch sowieso nicht über ein geroutetes VPN. DHCP Prozesse haben in einem Site to Site VPN mit IPsec Protokoll keinerlei Funktion.
Deshalb ist es auch eher ein Fehler sowas wie "Send DHCP requests to the server addresses listed below..." in einer IPsec Konfig zu definieren.

Am DHCP-Server sehe ich aber keine FritzBox bzw. keine MyFritz-Adresse.

Kein Wunder ! Siehe oben !
Die Digi Box rennt ja mit der Sonicwall in einer Router Kaskade mit doppeltem NAT. Was da zu beachten ist bei IPsec VPNs kannst du hier genau nachlesen:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Technsch besser ist immer ein reines Modem davor statt eines Routers. Das aber nur nebenbei. Es funktioniert natürlich auch in einer Kaskade fehlerfrei wenn man die o.a. Settings beachtet.

Oder muss ich die remote_virtualip an der FritzBox schon vorgeben?

Die IP Adresse nicht, bei einer Site to Site Kopplung musst du aber statisch jeweils immer das remote IP Netzwerk der anderen Seite defineren damit die Phase 2 SAs etabliert werden.

2 Dinge fehlen oben:

Wie immer: WAS sagen die VPN Logs ?? Einmal der FritzBüx und einmal der Sonicwall ?? Es ist immer sinnvoll die lokalen LAN IPs zu pingen weil es hier meist keine Routing Probleme usw. gibt.
Kannst du jeweils die die lokalen LAN Interface IP Adressen der FritzBox und der Sonicwall von gegenüber pingen ?

Beachte ferner das das Pingen remoter Windows Rechner vermutlich nicht geht, denn Ping (ICMP) ist per Default in der Winblows Firewall geblockt ! Das müsst du erst freischalten !:
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Besonders wenn diese Pings aus fremden Netzen kommen die generell in der Windows Firewall geblockt sind. Ggf. also anpassen.
Besonders betrifft das auch das Sonicwall Interface. In der Regel ist auch hier immer bei Firewalls ICMP geblockt. Das solltest du also prüfen.
Besser also Drucker usw. pingen die keine FW an Bord haben.
Nochwas: 3DES als Schlüssel zu verwenden ist nicht mehr besonders sicher. Hier solltest du immer besser auf AES128 besser AES256 gehen !
Weitere Infos dazu auch hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a

Guten Morgen
und danke für die ausführliche Antwort!

Deshalb ist es auch eher ein Fehler sowas wie "Send DHCP requests to the server addresses listed below..." in einer IPsec Konfig zu definieren.

ok, ist wieder gelöscht

2 Dinge fehlen oben:
Wie immer: WAS sagen die VPN Logs ?? Einmal der FritzBüx und einmal der Sonicwall ??

Die Logs lesen sich nicht so spannend. Für die SonicWall ist das VPN-Log im Anhang.
Die Kollegin Fritz meldet nur, dass sie die VPN-Verbindung zu blablabla.ddns.net erfolgreich aufgebaut hat und meldet dazu die passende und koreekte öffentliche IP der Diggi-Box.

* Kannst du jeweils die die lokalen LAN Interface IP Adressen der FritzBox und der Sonicwall von gegenüber pingen ?

Also in der Zentrale ping 192.168.179.1 (Fritz Außenstelle) - Zeitüberschreitung der Anforderung
Umgekehrt ging es gestern auch nicht, fahre aber nachher wieder in die Außenstelle.

Technsch besser ist immer ein reines Modem davor statt eines Routers. Das aber nur nebenbei.

Danke, das ist genau mein Reden. Als ich den Kunden im letzten Jahr erstmal besucht habe, hatte er noch ein Modem und ich sagte ihm, alles Prima, lass das so! Dann hat er eine neue Telefonanlage bekommen und oben drauf eine FritzBox vom TK-Menschen. Leider hat die Telefonanlage nicht funktioniert. Dann kam die Telekom und hat die Fritz wieder herausgeschmissen und die Diggi-Box hingehängt.
Egal, ich habe in der Digi-Box alle nötigen Ports (UDP 500, UDP 4500, ESP) per Portweiterleitung an die SonicWall offen.

Die IP Adresse nicht, bei einer Site to Site Kopplung musst du aber statisch jeweils immer das remote IP Netzwerk der anderen Seite defineren damit die Phase 2 SAs etabliert werden.

jep, internes Netz Zentrale 120.0, internes Netz Außenstelle 179.0

Vielleicht sagt Dir ja das Log noch etwas:
www.jottacloud.com/s/03016cdac1ec3b14a90b88078c64e7947ec

mal eine bildliche Darstellung:

Ich habe nochmal mit einem Bekannten mir die ganze Sache angeschaut. Dabei ist uns aufgefallen, dass auf der SonicWall keine Pakete via Port 4500 UDP kommen. Diese Port ist jedoch in der Diggi-Box auf die SonicWall weitergeleitet.

Kann es sein, dass diese seltsame Dimmi-Box von der Telekom das Port-Forwarding nicht hinbekommt?

Moin,

ein kurzer Hinweis meinerseits, das die Namensauflösung durch das VPN mit einer FritzBox NICHT funktioniert, da die FritzBox kein Request Routing beherrscht.

Ein Ping aus der Außenstelle auf 192.168.120.87 wird also funktionieren, ein Ping nach z.B. ucs.zentrale.local NICHT! Du mußt also Freigaben usw. IMMER über die IP-Adresse aufrufen, also z.B. \\192.168.120.87\Freigabe, sonst klappt das nicht.

cu,
ipzipzap

dass auf der SonicWall keine Pakete via Port 4500 UDP kommen

Dann ist auf dem Gegenpart kein NAT Traversal aktiviert im IPsec. In sofern dann tödlich wenn sich irgendwo ein NAT im Pfad befindet. Das kann dann ohne NAT Traversal nicht überwunden werden.

Dimmi-Box von der Telekom das Port-Forwarding nicht hinbekommt?

Kann sein. Generell sind die Billigen Schrott Router die es mit einem Account für Umsonst dazugibt der größte Mist. Klar, denn der Provider will dein Geld und einen langfristigen Vertrag. Er will dich nicht sponsorn mit eurem Equipment !
Deshalb macht es immer Sinn besser vollständig auf solche Router als "Durchlauferhitzer" bzw. generell auf solche Kaskaden Konfigs zu verzichten und ein simples und einfaches Hybridmodem wie z.B. ein Vigor 165 https://www.draytek.de/vigor165.html zu verwenden !!
Siehe auch hier zu dem Thema:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät

Nebenbei:
nach z.B. ucs.zentrale.local
.local sollte man niemals verwenden als lokale Root Domain. Ein NoGo, denn das ist weltweit per Standard für mDNS reserviert ! Wird also früher oder später zu Problemen führen.
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Wie man sinnvolle lokale DNS Namen wählt steht u.a. hier:
https://www.heise.de/select/ct/2017/26/1513540412603853

Hallo aqui,

Zitat von @aqui:
nach z.B. ucs.zentrale.local

Das sollte nur als ((zugegebenermaßen) schlechtes) Beispiel dienen

Zitat von @aqui:
Dann ist auf dem Gegenpart kein NAT Traversal aktiviert im IPsec. In sofern dann tödlich wenn sich irgendwo ein NAT im Pfad befindet. Das kann dann ohne NAT Traversal nicht überwunden werden.

Doch, das ist auf der SonicWall und der Fritz aktiviert

Kann sein. Generell sind die Billigen Schrott Router die es mit einem Account für Umsonst dazugibt der größte Mist.

Mist?! Das ist noch übertrieben freundlich ausgedrückt. Dachte gestern abend noch, ok, vielleicht reißt es ja eine neue Routerfirmware für die Dummi-Box. Das nennt sich sogar BOSS-Version. Nach dem Neustart der Box zeigt sie alle Portweiterleitungen immer noch an, aber auf der SonicWall kommen nun gar keine Pakete über UDP 500 mehr an. Musst zur Beruhigung erstmal mit der Flex ein paar Bleche durchtrennen.

Immerhin und das ist innovativ: Ich sehe im Log der Dummi-Box sehr interessante Einträge:

IKE_SA: peer 0 () sa (R): failed id No Id <- ip [Öffentliche_IP_Fritzbox] ((null))

und zeitgleich im Log der Fritzbox:

VPN-Fehler: blablabla.ddns.net, IKE-Error 0x02026

Nun, habe ich - nur für Spass - die SonicWall in der Dummi-Box als Screened Host deklariert. Damit sollten doch endlich alle Pakete ungefiltert bei der SonicWall aufschlagen... We like it, when we say it doesn't work!

Die Dummi Box ist vermutlich auch ein VPN Router, kann das sein ?!
Dann "denkt" sie diese IPsec Pakete sind für sie selber und versucht sie selber zu verwursten statt sie per Port Forwarding weiterzugeben.
Das ist der Fluch von Router Kaskaden wenn man dumme Router davor hat...

Du musst auf der Dummi Box alles deaktivieren was eigenes VPN ist.
Sie muss zwangsweise diese 3 Komponenten an die kaskadierte Sonicwall weiterleiten:

UDP 500 (IKE)
UDP 4500 (NAT Traversal)
ESP Protokoll (IP Protokoll Nummer 50)

Wenn du statt der Sonicwall mal einen Wireshark Sniffer mit gleicher IP wie die Sonicwall an die Dummi Box anschliesst dann musst du diese Pakete sehen wenn du eingehenden IPsec Traffic hast.
Oder diesen Port mit einem Mirror Port oder einer Bridge Probe eben mal spiegeln und den IPsec Traffic belauschen

ok, in der Dummi Box ist kein VPN eingerichtet. In den globalen Optionen habe ich IPSec nun ausgeschaltet. Das sorgt dafür, dass ich die Anfragen nicht mehr im Log sehe.
Die SonicWall hat einen integrierten Packet Monitor, den habe ich laufen gelassen habe und als Quell-IP die öffentliche IP der Fritzbox eingetragen.
Klappt wunderbar. Ich sehe z.B. die https-Anfragen aus dem Netz der Fritzbox zum OWA. Aber ich sehe kein einziges IPSec-Paket.
Nochmal nur für Spass, habe ich nur die entsprechenden Ports abgelauscht ohne eine Quelle vorzugeben - nix, einfach nix.

Streiken die vertunnelten Paketzusteller bei der Telekom?

Fakt ist also, dass IPSec von der Box aufgehalten und verworfen wird. Beweise übergeben.
Ich habe dem Kunden heute Mittag nahegelegt, er möge bitte das alte Modem wieder anschließen. Das VoIP-Gedöns kann die SonicWall auch noch machen.
Nein, lässt mir der inzwischen vom Kunden angerufene Telekom-Beauftragte ausrichten (ja, der die Dummi-Box geliefert hat) - das ginge doch alles nicht! Wo soll er denn da die Telefonanlage anschließen? Die SonicWall hat doch keine S0-Schnittstellen und davon braucht er 2 Stück.

jep, für eine IP-fähige Anlage braucht man ISDN - und zwar zwei Mal. Danke!

Aber ich sehe kein einziges IPSec-Paket.

Dann stimmt wohl deine Firewall Regel nicht ! Eine andere Erklärung gibt es ja nicht dafür. Millionen IPsec fähige und funktionierende Sonicwalls sprechen da eine deutliche Sprache !

Wenn beide VPN Tunnelendpunkte Initiators sind kannst du auch an der FritzBüx mal nachsehen ob da entsprechendes ankommt.
Über http://fritz.box/html/capture.html kannst du sehen was so an der FritzBüx rein- und rausgeht. Wenigstens da sollten ja IPsec Pakete der Sonicwall ankommen.
Die FritzBüx arbeitet mit so ziemlich allem fehlerlos zusammen was IPsec spricht. Siehe dazu auch hier: IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a

Streiken die vertunnelten Paketzusteller bei der Telekom?

Möglich, ja, aber nicht sehr wahrscheinlich... Bei billigen nur Surf Accounts werden gerne mal die VPN Protokoll bei den Providern gefiltert, da sie teureren Business Accounts vorbehalten werden. Solltest du mal klären !
Die dt. Telekom macht das aber in der Regel und Erfahrungs gemäß nicht ! Also solltest du besser mal dein Regelwerk in der FW checken. Zu 98% liegt da der Fehler !

Wo soll er denn da die Telefonanlage anschließen?

Der kennt scheinbar seine eigene Produktpalette nicht...!! Ohne Worte...
https://www.telekom.de/zuhause/geraete-und-zubehoer/wlan-und-router/spee ...

Hey Super, das mit dem Capture auf der Fritz ist eine klasse Idee. Probiere ich morgen direkt mal aus.
Jetzt ist erstmal Feierarbend.
cu

p.s. Die TK-Anlage kann IDSN und IP. Sie wurde vor der Umstellung des Anschlusses geliefert und zu diesem Zeitpunkt natürlich noch mit ISDN betrieben. Nach der Umstellung hat man sich die Sache leicht gemacht und einfach alles so gelassen. Ging bestimmt schneller, als noch mal die Konfig der Anlage anzupassen.

Nach der Umstellung hat man sich die Sache leicht gemacht und einfach alles so gelassen.

Ist ja krank und mus sman sicher hier in einem Admin Forum nicht weiter kommentieren. So gehen Bastellaien vor, aber egal !!
Die Anlage sollte man dann immer besser direkt auf VoIP umstellen. Alles andere wäre doch sinnfreie Wandelei. Ist vermutlich auch mit 3 Mausklicks im GUI erledigt. Aber das ist erstmal auch eine ganz andere Baustelle.... Bleiben wir hier also besser beim Thema als sich über so einen Unsinn aufzuregen.

Zitat von @Allyfied:
Ging bestimmt schneller, als noch mal die Konfig der Anlage anzupassen.

Oder es lag am Geld. Habe ich leider oft, das ich etwas nicht vernünftig machen kann/soll/darf, weil die Zeit nicht bezahlt oder es zu teuer wird.

...du has Recht ! Macht die Sache aber auch nicht besser sondern eher noch schlimmer...

so.... läuft!

Wie?
- Alle NAT- und Firewallregeln in der Dimmi-Box löschen
- Neustarten
- Neue NAT-Regel any auf SonicWall
- Neue Firewallregel alles zur SonicWall durchlassen
- Neustart und geht

Offenbar hat die Dummi-Box ein Problem damit, wenn mehr als 24 Regeln erstellt werden - in meinem Fall hatte ich 32 Ports an die SonicWall weitergeleitet. Und diese Weiterleitungen gingen bis Nr. 24 ohne Probleme. Die IPSec-Regeln standen erst darunter. Schon beim Löschen der NAT-Regeln habe ich gesehen, dass die SonicWall plötzlich IKE-Pakete geliefert bekommt.

Ich danke allen in diesem Thread für ihre Geduld und ihre Anregungen. Ihr seid spitze!
Viele Grüße
Ally

so.... läuft!

👏 Glückwunsch !
Die "Dummie" Box macht ihrem Namen also alle Ehre. Deswegen auch immer wieder die Appelle hier eben keinen (Zwangs) Router davor zu nutzen sondern ein simples nur Modem. Das verhindert all diese Fallen und Probleme in die du getappt bist schon von Anfang an.
Case closed !

Bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !

gelöst Frage Netzwerke Router, Routing

Mehr von Allyfied

Wörter markieren mit Doppelklick ohne nachfolgendes LeerzeichenAllyfied - 4 Kommentare

Photoshop und Co. - Bilder automatisch skalieren und zuschneidenAllyfied - 4 Kommentare

User Profile Disk eines gelöschten Users entfernenAllyfied - 17 Kommentare

Verrückte Dateiberechtigungen und Absturz Windows Explorer beim Versuch diese zu ändernAllyfied - 4 Kommentare

Heiß diskutiert