38517
Sep 26, 2007, updated at Sep 28, 2007 (UTC)
11689
6
0
Netgear FVS318v3 Gateway-Gateway VPN DISCARDING RETRANSMITTED PACKET...
Hallo Zusammen
Ich bin dabei ein Gateway to Gateway VPN mit 2 Netgear FVS318v3 (aktuelle Firmware) einzurichten. Die Firewalls stehen je hinter einem Netopia ADSL Router. Dabei verwende ich ein kaskadiertes System, so dass ADSL Router die Internet Verbindung herstellt und dann die Firewalls über eine Interne IP hinter dem NAT kommunizieren.
Beide Firealls sind identisch konfiguriert, einfach kreuzweise mit den VPN Informationen. Die ADSL Router haben als Default Sever die Firewalls drin, so dass diese alle Pakete bekommen.
Speziell ist, dass ich vom Standort A eine VPN Verbindung zu Standort B herstellen kann, jedoch keine Daten empfangen kann und diese Fehlermeldung erhalte: (siehe unterste 3 Zeilen)
*
[2007-09-26 21:29:51] RECEIVED FOURTH MESSAGE OF MAIN MODE
[2007-09-26 21:29:51]<POLICY fresh-vpn> PAYLOADS KE,NONCE
[2007-09-26 21:29:52] SENT OUT FIFTH MESSAGE OF MAIN MODE
[2007-09-26 21:29:54] RECEIVED SIXTH MESSAGE OF MAIN MODE
[2007-09-26 21:29:54]<POLICY fresh-vpn> PAYLOADS ID,HASH
[2007-09-26 21:29:54] MAIN MODE COMPLETED
[2007-09-26 21:29:54][==== IKE PHASE 1 ESTABLISHED====]
[2007-09-26 21:29:54]<POLICY: fresh-vpn> PAYLOADS HASH,DEL
[2007-09-26 21:29:54] SENT OUT INFORMATIONAL EXCHANGE MESSAGE
[2007-09-26 21:29:54]<POLICY fresh-vpn> PAYLOADS: HASH,DEL
[2007-09-26 21:30:10][==== IKE PHASE 2(to xxx.xxx.xxx.xxx) START (initiator) ====]
[2007-09-26 21:30:10] SENT OUT FIRST MESSAGE OF QUICK MODE
[2007-09-26 21:30:10]<Initiator IPADDR=192.168.0.0,PORT=0>
[2007-09-26 21:30:10]<Responder IPADDR=192.168.3.0,PORT=0>
[2007-09-26 21:30:10] RECEIVED SECOND MESSAGE OF QUICK MODE
[2007-09-26 21:30:10]<POLICY fresh-vpn> PAYLOADS: HASH,SA,PROP,TRANS,NONCE,ID,ID
[2007-09-26 21:30:10]<POLICY fresh-vpn> PAYLOADS: HASH
[2007-09-26 21:30:10] SENT OUT THIRD MESSAGE OF QUICK MODE
[2007-09-26 21:30:10] QUICK MODE COMPLETED
[2007-09-26 21:30:10][==== IKE PHASE 2 ESTABLISHED====]
[2007-09-26 21:30:15]DISCARDING RETRANSMITTED PACKET...
[2007-09-26 21:30:20]DISCARDING RETRANSMITTED PACKET...
[2007-09-26 21:30:25]DISCARDING RETRANSMITTED PACKET...
*
Bei Standort B kann ich, wenn diese Verbindung durch A initiert wurde, beliebig Daten übers VPN senden, wie gewünscht.
Breche ich aber von B aus die Verbidung ab und möchte die Via B starten, erhalte ich keine Antwort von Standort A.
Sprich: Wenn A mit B verbunden ist, kann ich nur von B auf A zugreiffe und nicht von A auf B. Von B aus kann ich keine Verbindung starten.
Im Firewall Log von Standort A hatte ich noch dies:
*
Wed, 2007-09-26 21:27:07 - ICMP packet - Source: 192.168.1.1 - Destination: 192.168.1.2 - [ICMP Type: 3 Code: 1 Icmp error message received for uninitiated connection. Orginal Src 192.168.1.2 Dst xxx.xxx.xxx.xxx., dropping packet from WAN]
*
Was könnte das sein?
Danke für eure Hilfe!
Gruss
Manuel
Ich bin dabei ein Gateway to Gateway VPN mit 2 Netgear FVS318v3 (aktuelle Firmware) einzurichten. Die Firewalls stehen je hinter einem Netopia ADSL Router. Dabei verwende ich ein kaskadiertes System, so dass ADSL Router die Internet Verbindung herstellt und dann die Firewalls über eine Interne IP hinter dem NAT kommunizieren.
Beide Firealls sind identisch konfiguriert, einfach kreuzweise mit den VPN Informationen. Die ADSL Router haben als Default Sever die Firewalls drin, so dass diese alle Pakete bekommen.
Speziell ist, dass ich vom Standort A eine VPN Verbindung zu Standort B herstellen kann, jedoch keine Daten empfangen kann und diese Fehlermeldung erhalte: (siehe unterste 3 Zeilen)
*
[2007-09-26 21:29:51] RECEIVED FOURTH MESSAGE OF MAIN MODE
[2007-09-26 21:29:51]<POLICY fresh-vpn> PAYLOADS KE,NONCE
[2007-09-26 21:29:52] SENT OUT FIFTH MESSAGE OF MAIN MODE
[2007-09-26 21:29:54] RECEIVED SIXTH MESSAGE OF MAIN MODE
[2007-09-26 21:29:54]<POLICY fresh-vpn> PAYLOADS ID,HASH
[2007-09-26 21:29:54] MAIN MODE COMPLETED
[2007-09-26 21:29:54][==== IKE PHASE 1 ESTABLISHED====]
[2007-09-26 21:29:54]<POLICY: fresh-vpn> PAYLOADS HASH,DEL
[2007-09-26 21:29:54] SENT OUT INFORMATIONAL EXCHANGE MESSAGE
[2007-09-26 21:29:54]<POLICY fresh-vpn> PAYLOADS: HASH,DEL
[2007-09-26 21:30:10][==== IKE PHASE 2(to xxx.xxx.xxx.xxx) START (initiator) ====]
[2007-09-26 21:30:10] SENT OUT FIRST MESSAGE OF QUICK MODE
[2007-09-26 21:30:10]<Initiator IPADDR=192.168.0.0,PORT=0>
[2007-09-26 21:30:10]<Responder IPADDR=192.168.3.0,PORT=0>
[2007-09-26 21:30:10] RECEIVED SECOND MESSAGE OF QUICK MODE
[2007-09-26 21:30:10]<POLICY fresh-vpn> PAYLOADS: HASH,SA,PROP,TRANS,NONCE,ID,ID
[2007-09-26 21:30:10]<POLICY fresh-vpn> PAYLOADS: HASH
[2007-09-26 21:30:10] SENT OUT THIRD MESSAGE OF QUICK MODE
[2007-09-26 21:30:10] QUICK MODE COMPLETED
[2007-09-26 21:30:10][==== IKE PHASE 2 ESTABLISHED====]
[2007-09-26 21:30:15]DISCARDING RETRANSMITTED PACKET...
[2007-09-26 21:30:20]DISCARDING RETRANSMITTED PACKET...
[2007-09-26 21:30:25]DISCARDING RETRANSMITTED PACKET...
*
Bei Standort B kann ich, wenn diese Verbindung durch A initiert wurde, beliebig Daten übers VPN senden, wie gewünscht.
Breche ich aber von B aus die Verbidung ab und möchte die Via B starten, erhalte ich keine Antwort von Standort A.
Sprich: Wenn A mit B verbunden ist, kann ich nur von B auf A zugreiffe und nicht von A auf B. Von B aus kann ich keine Verbindung starten.
Im Firewall Log von Standort A hatte ich noch dies:
*
Wed, 2007-09-26 21:27:07 - ICMP packet - Source: 192.168.1.1 - Destination: 192.168.1.2 - [ICMP Type: 3 Code: 1 Icmp error message received for uninitiated connection. Orginal Src 192.168.1.2 Dst xxx.xxx.xxx.xxx., dropping packet from WAN]
*
Was könnte das sein?
Danke für eure Hilfe!
Gruss
Manuel
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 69616
Url: https://administrator.de/contentid/69616
Printed on: April 18, 2024 at 12:04 o'clock
6 Comments
Latest comment
Hallo,
kann es sein das du an beiden Standorten den selbe IP Kreis hast ?
Poste bitte mal die Details der beiden Standorte.
Gruß
Fisicon
kann es sein das du an beiden Standorten den selbe IP Kreis hast ?
Poste bitte mal die Details der beiden Standorte.
Gruß
Fisicon
Hallo!
Nein, ich habe 4 Subnetze, Wan & Lan A Wan & Lan B. Das sollte schon klappen.
Ich vermute, dass das Problem bei einem der ADSL Router liegt. Der ADSL Router von Standort A ( Cayman Model 3341 DSL USB) ist schon 4 Jahre alt und unterstützt im Portforwarding nur TCP und UDP, jedenfalls kann ich nichts anderes auswählen. Ich habe jedoch den Default Server für Portforwarding gesetzt. Eventuell werden icmp Pakete doch nich inbound weiter geleitet. Der zweite ADSL Router ist erst 1 Jahr alt.
Könnte es eine Lösung sein, wenn ich bei Standort A den ADSL Router in den Brigding Modus stecke und denn via Netgear Firewall mich über PPoE zum ISP einwähle? Sollten dann auf jeden fall alle Protokolle korrekt duch den Netopia ADSL Router geroutet werden?
Leider konnte ich dies noch nicht testen.
Könnte das eine Erklärung sein, weshalb ich von Standort B aus Daten von Standort A laden kann, also Outbound von A, jedoch von A aus keine Daten von B aus laden kann?
Danke und Gruss
Manuel
Nein, ich habe 4 Subnetze, Wan & Lan A Wan & Lan B. Das sollte schon klappen.
Ich vermute, dass das Problem bei einem der ADSL Router liegt. Der ADSL Router von Standort A ( Cayman Model 3341 DSL USB) ist schon 4 Jahre alt und unterstützt im Portforwarding nur TCP und UDP, jedenfalls kann ich nichts anderes auswählen. Ich habe jedoch den Default Server für Portforwarding gesetzt. Eventuell werden icmp Pakete doch nich inbound weiter geleitet. Der zweite ADSL Router ist erst 1 Jahr alt.
Könnte es eine Lösung sein, wenn ich bei Standort A den ADSL Router in den Brigding Modus stecke und denn via Netgear Firewall mich über PPoE zum ISP einwähle? Sollten dann auf jeden fall alle Protokolle korrekt duch den Netopia ADSL Router geroutet werden?
Leider konnte ich dies noch nicht testen.
Könnte das eine Erklärung sein, weshalb ich von Standort B aus Daten von Standort A laden kann, also Outbound von A, jedoch von A aus keine Daten von B aus laden kann?
Danke und Gruss
Manuel
Folgendes habe ich gerade auf der Netopia Website (http://www.netopia.com/support/hardware/technotes/NIR_082.html) gefunden:
6.3.0 R7 Outbound IPSec is supported. Make sure the IPSec passthrough box is checked in the web GUI as shown below.
Inbound Passthrough - - Netopia 3300 / 3500 Series
6.30R7: Inbound passthrough is NOT supported.
7.1.1: Inbound passthrough is NOT supported.
7.1.2: Inbound passthrough is supported using the Software Hosting passthrough feature. See 7.1.2 documentation for a description of this feature.
Weil ich 6.3.0. R9 habe könnte dies ein Problem sein?
Umgehe ich die Einschränkungen, wenn die ADSL Modems im Bridge Modus sind und die Firewall dahinter sich beim ISP einloggt? Oder habe ich auf jeden Fall ein Problem?
Hallo Zusammen, ich versuche es auch mal mit einem Firmware Upgrade des ADSL Routers: http://www.netopia.com/equipment/intl/emea/ch/de/DE_aktual_swisscom.htm ...
Grüsse
Manuel
6.3.0 R7 Outbound IPSec is supported. Make sure the IPSec passthrough box is checked in the web GUI as shown below.
Inbound Passthrough - - Netopia 3300 / 3500 Series
6.30R7: Inbound passthrough is NOT supported.
7.1.1: Inbound passthrough is NOT supported.
7.1.2: Inbound passthrough is supported using the Software Hosting passthrough feature. See 7.1.2 documentation for a description of this feature.
Weil ich 6.3.0. R9 habe könnte dies ein Problem sein?
Umgehe ich die Einschränkungen, wenn die ADSL Modems im Bridge Modus sind und die Firewall dahinter sich beim ISP einloggt? Oder habe ich auf jeden Fall ein Problem?
Hallo Zusammen, ich versuche es auch mal mit einem Firmware Upgrade des ADSL Routers: http://www.netopia.com/equipment/intl/emea/ch/de/DE_aktual_swisscom.htm ...
Grüsse
Manuel
Ich glaube, ich mache lieber den Web über den ADSL Router im Bridge Modus. Der Standort A habe ich nun im Bridge Modus mit einer Fixen IP (Webacces geht), jedoch erhalte ich noch die Discarding Fehlermeldungen. Heute Abend werde ich auch Standort B in den Brindgemodus nehmen.
Werden dann im Bridgemodus total die Einschränkungen des ADSL Routers übergangen, da nun die separate Firewall eine direkte IP via PPoE übers Internet hat? Oder könnte eine Tiefe Firmware auf dem ADSL Router (nicht exterme Firewall) Einfluss auf die VPN Verbindung haben?
Grüsse
Manuel
Werden dann im Bridgemodus total die Einschränkungen des ADSL Routers übergangen, da nun die separate Firewall eine direkte IP via PPoE übers Internet hat? Oder könnte eine Tiefe Firmware auf dem ADSL Router (nicht exterme Firewall) Einfluss auf die VPN Verbindung haben?
Grüsse
Manuel
Nachdem ich bei beiden ADSL Routern die Bridge Funktion aktiviert hatte und über die beide externen Firewall-Gateways mich einwählte + ein Firmware update eines alten ADSL Routers machte, funktioniert nun die VPN Verbindung auf beide Seten. Die Discarding Meldung kommt zwar immer noch, aber die Daten fliessen. Was könnte der Grund für die Meldung sein?
Grüsse
Manuel
Grüsse
Manuel
So ist die Konfig in jedem Falle richtig ! Wenn du VPN Betrieb machst solltest du niemals die VPN Gateways hinter NAT Router betreiben wenn diese wie in deinem Falle eine Einwahl ja auch selber vornehmen können.
Der Grund ist ein ganz einfacher und das wird auch dein Problem gewesen sein: Die musst das VPN Protokoll, wie in deinem Falle IPsec wahrscheinlich im ESP Modus (Encapsulation security Payload), revers über den NAT Router davor übertragen, was immer unschön ist da viele Systeme das nicht richtig können wie sehr wahrscheinlich dein altes Cayman System.
Wie du sicher selber weisst besteht IPsec(ESP) aus 3 Protokollen, IKE dem Schlüsselprotokoll auf UDP 500, dann ESP was in der IP Protokollsuite ein eigenes Protokoll mit der Nummer 50 ist und meist auch noch dem NAT-Traversal auf UDP 4500.
Leider kann man nur raten wie du das Port Forwarding auf den davor liegenden NAT Routern eingestellt hast aber scheinbar führt einer der Router das VPN Passthrough dann nicht sauber aus, so das es zu diesem Verhalten gekommen ist.
Wenn du mit dem Wireshark mal einen Trace gezogen hättest beim VPN Verbindungsaufbau hätte man dir das sofort sagen können aber leider fehlten diese Daten von dir so das man, wie gesagt, nur raten kann
Dadurch das du nun einen der Vorrouter zum dummen Modem gemacht hast, stellt sich das Problem nicht mehr denn die FVS haben nun eine direkte VPN Verbindung ohne NAT.
So oder so ist das aber technisch die beste Lösung es mit den VPN Routern direkt zu machen oder noch besser ist es gleich VPN aktive Router mit integriertem Modem zu nutzen !!!
Wenns das war bitte
How can I mark a post as solved?
nicht vergessen !
Der Grund ist ein ganz einfacher und das wird auch dein Problem gewesen sein: Die musst das VPN Protokoll, wie in deinem Falle IPsec wahrscheinlich im ESP Modus (Encapsulation security Payload), revers über den NAT Router davor übertragen, was immer unschön ist da viele Systeme das nicht richtig können wie sehr wahrscheinlich dein altes Cayman System.
Wie du sicher selber weisst besteht IPsec(ESP) aus 3 Protokollen, IKE dem Schlüsselprotokoll auf UDP 500, dann ESP was in der IP Protokollsuite ein eigenes Protokoll mit der Nummer 50 ist und meist auch noch dem NAT-Traversal auf UDP 4500.
Leider kann man nur raten wie du das Port Forwarding auf den davor liegenden NAT Routern eingestellt hast aber scheinbar führt einer der Router das VPN Passthrough dann nicht sauber aus, so das es zu diesem Verhalten gekommen ist.
Wenn du mit dem Wireshark mal einen Trace gezogen hättest beim VPN Verbindungsaufbau hätte man dir das sofort sagen können aber leider fehlten diese Daten von dir so das man, wie gesagt, nur raten kann
Dadurch das du nun einen der Vorrouter zum dummen Modem gemacht hast, stellt sich das Problem nicht mehr denn die FVS haben nun eine direkte VPN Verbindung ohne NAT.
So oder so ist das aber technisch die beste Lösung es mit den VPN Routern direkt zu machen oder noch besser ist es gleich VPN aktive Router mit integriertem Modem zu nutzen !!!
Wenns das war bitte
How can I mark a post as solved?
nicht vergessen !
