neun11turbo
Goto Top

Site-to-Site VPN Sonicwall TZ170 zu TZ190 mit Speedport W721V als Modem dazwischen

Der Tunnel lässt sich von EINER Seite (TZ190 hinter Speedport als VDSL Modem) aufbauen und funktioniert dann von beiden Seiten aus perfekt. Er lässt sich aber NICHT von der anderen Seite (TZ170 hinter normalem DSL Modem) aufbauen (wohl aber nutzen wenn er von der anderen Seite aufgebaut wurde...)

Folgendes Szenario:

Site A:

VDSL an Speedport W721V
Speedport hat die Zugansdaten und die Option "als Modem nutzen" ist aktiviert
Adresse Speedport ist 192.168.2.1
DHCP ist aktiviert

Sonicwall TZ190 WAN Port angeschlossen an den LAN Port 1 des Speedport
WAN Zugang so definiert, dass sich die Sonicwall per DHCP vom Speedport die "WAN"-Adresse etc. holt
Die TZ 190 hat dann als "WAN" Adresse 192.168.2.153
Die LAN Adresse des TZ190 ist auf 10.10.101.1 gesetzt.
Alle PCs etc. sind über die LAN Anschlüsse und diverse Switche so an die TZ190 angeschlossen

Alles funktioniert so weit perfekt. Alle PCs kommen in Internet etc., alles wunderbar

Jetzt wollen wir einen VPN Tunnel mit einer anderen Site aufsetzen:

Site B

Normales ADSL an normalem DSL Modem (reines Modem)
Sonicwall TZ170 WAN Port angeschlossen am Modem
TZ170 hat die Zugangsdaten und bekommt über PPPoE seine WAN Adresse etc.
Die LAN Adresse des TZ170 ist 10.101.98.1
Wieder sind alle PCs etc an den LAN Anschlüssen des TZ179 angeschlossen

Auch hier funktioniert alles so weit perfekt


VPN zwischen den Sites:

Die WAN Adressen sind über DYNdns als FQDN vorhanden und entsprechend bei IPSec Primary Gateway eingetragen
Secondary GW ist 0.0.0.0

IKE mit PSK
IDs sind die UFIs (bei der TZ190 / bei der TZ170 muss der VPN Policy Name dem UFI der Peer Seite entsprechen)
Proposals sind identisch auf beiden Seiten

Auf Site A ist als remote Netzwerk 10.101.98.1 mit 255.255.255.0 eingetragen
Auf Site B ist als remote Netzwerk 10.10.101.1 mit 255.255.255.0 eingetragen


Wird jetzt VON Site A im Browser z.B. 10.10.101.1 eigetragen wird der Tunnel ohne Problem aufgebaut und es escheint die Login-Seite der TZ170 von Site B (die hat auf Site B ja 10.101.98.1). Auch von Site B kann jetzt jedes Gerät im LAN von Site A angesprochen werden und alles funktioniert ohne jedes Problem....

Ganz anders von Site B: wird hier eine Adresse von Site A im Browser eingetragen passiert gar nichts und im TZ170 Log ist zu lesen:


2009/06/27 00:53:37.832 IKE negotiation aborted due to timeout xxx.xxx.xxx.xxx, pxxxxxxxxx.dip.t-dialin.net xxx.xxx.xxx.xxx, pyyyyyyyyy.dip.t-dialin.net
3 2009/06/27 00:53:03.832 IKE Initiator: No response - remote party timeout xxx.xxx.xxx.xxx, pxxxxxxxxx.dip.t-dialin.net xxx.xxx.xxx.xxx, pyyyyyyyyy.dip.t-dialin.net
4 2009/06/27 00:52:46.816 IKE Initiator: No response - remote party timeout xxx.xxx.xxx.xxx, pxxxxxxxxx.dip.t-dialin.net xxx.xxx.xxx.xxx, pyyyyyyyyy.dip.t-dialin.net
5 2009/06/27 00:52:35.832 IKE Initiator: No response - remote party timeout xxx.xxx.xxx.xxx, pxxxxxxxxx.dip.t-dialin.net xxx.xxx.xxx.xxx, pyyyyyyyyy.dip.t-dialin.net
6 2009/06/27 00:52:27.864 IKE Initiator: Start Aggressive Mode negotiation (Phase 1) xxx.xxx.xxx.xxx, pxxxxxxxxx.dip.t-dialin.net xxx.xxx.xxx.xxx, pyyyyyyyyy.dip.t-dialin.net


...die TZ170 versucht also den Tunnel aufzubauen, scheitert aber kläglich... face-sad

Woran könnte es nun liegen, dass es zwar in einer Richtung problemlos klappt, in der anderen aber nicht...?

Danke für alle Ideen,
Klaus

Content-Key: 119189

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

Ausgedruckt am: 29.03.2024 um 09:03 Uhr

Mitglied: aqui
aqui 28.06.2009 um 14:44:42 Uhr
Goto Top
Ein Argument von dir:
Die TZ 190 hat dann als "WAN" Adresse 192.168.2.153

zeigt ganz klar das der SP niemals nur als Modem arbeitet ! Ein Modem ist transparent und es ist also zu erwarten das du eine öffentliche IP Adresse an diesem Port bekommst aber niemals eine RFC 1918 IP Adresse
http://de.wikipedia.org/wiki/Private_IP-Adresse

Die ganz klar auf einen NAT Prozess schliessen lässt, denn die T-Com verwendet logischerweise ja keine privaten IPs im WAN !!

Vermutlich hast du also vergessen den DHCP Server beim Speedport W721V auszuschalten. Es ist auch zu bezweifeln das die T-Com IP Adressen bei VDSL mit DHCP vergibt. Vermutlich wird hier ebenfalls PPPoE benutzt.
Es ist logisch das mit einer geNATeten IP Adresse aus einem RFC 1918 IP netz niemals eine VPN Verbindung zustande kommt.

Erst wenn du auf dem WAN Port der Sonicwall eine öffentliche IP hast ist das IP Adressing OK und dann wird ein (VPN) Schuh draus !!