Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 38 subscribers
  • Views 5776 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Routing durch zwei IPSec-Tunnel hindurch

AstaroGuestIUser
Hallo,

mir ist nicht ganz klar, wie ich das folgende Szenario realisieren kann: drei Sites sind jeweils mit einem Tunnel mit einer Zentrale verbunden...

Site 1 (192.168.200.0) === Site 2 (192.168.100.0)

Site 2 (192.168.100.0) === Site 3 (192.168.230.0)

Site 1 und 2: ASG120 7.101
Site 3: SonicWALL 3G

Zwischen den einzelnen Sites funktioniert alles einwandfrei.

Von Site 1 aus sollen nun Hosts in Site 3 erreicht werden. Ich habe bei der Definition der Tunnel angegeben, daß man von Site 1 aus das Netz von Site 3 durch den Tunnel zu Site 2 hindurch erreichen kann (remote network). Ich habe auf Sites 1 und 2 Paketfilterregeln angelegt, die den Verkehr entsperchend erlauben (logging eingeschaltet, beim Pingtest aber kein Ergebnis). Und ich habe eine Routingregel auf Site 1 angelegt, daß das Netz Site 3 über das IPSec-Gateway von Site 2 zu erreichen ist (192.168.100.254).

Das hat alles nichts gebracht, ein Pingtest von Site 1 aus auf einen Host in Site 3 schlägt fehl, weil er das Paket nirgendwohin schicken kann:
"Ping check did not deliver a result, because of a probably non-existing ip address / hostname"
Site 2 ist so eingestellt, daß pings geforwardet werden.

Was muss ich tun, um dieses Szenario hinzukriegen?

Danke für Tipps
Tilman


This thread was automatically locked due to age.
Parents
  • 0
    hmmm, das paket fällt aus dem tunnel raus und muss gerade wieder auf dem gleichen phys. interface in den 2. tunnel reingeschubst werden - ob das funktioniert?

    kannst du mal die gesamte routing table posten?

    einfacher wäre evtl. full mesh - also einen dritten tunnel zwischen seite 1 und 3 (asl - sonicw)
  • 0 in reply to gnujuba
    Nach allen Versuchen und viel Recherche bin ich zu dem Schluss gekommen, daß dieses Szenario so nicht zu realisieren ist. Man muss es 'full-mesh' machen oder wenigstens sternförmig. Insbesondere hat die ASG einige Kommunikationsprobleme mit der SonicWALL hinsichtlich der IPSec-Policy - ob es zwischen drei Astaros geht, kann ich nicht sagen.  ;-(


    Gruß
    Tilman
  • 0 in reply to AstaroGuestIUser
    Nach allen Versuchen und viel Recherche bin ich zu dem Schluss gekommen, daß dieses Szenario so nicht zu realisieren ist. Man muss es 'full-mesh' machen oder wenigstens sternförmig. Insbesondere hat die ASG einige Kommunikationsprobleme mit der SonicWALL hinsichtlich der IPSec-Policy - ob es zwischen drei Astaros geht, kann ich nicht sagen.  ;-(


    Gruß
    Tilman


    schon mal mit "schmutzigen" tricks versucht? also evtl. die eingehende verbindung von seite1 im hub (seite2) zu natten und dann wieder durch den tunnel zu seite3 zu schieben? nicht  wirklich schön ...

    bzgl. des tunnels zwischen sonicwall und asl: immer darauf achten, dass die lifetimes der keys in den ike phasen zu einander passen.

    aber machmal will es einfach nicht. hatte mal das problem zwischen pixen und draytek boxen. tunnel steht - aber besch..eidene performance ohne ersichtlichen grund.
Reply
  • 0 in reply to AstaroGuestIUser
    Nach allen Versuchen und viel Recherche bin ich zu dem Schluss gekommen, daß dieses Szenario so nicht zu realisieren ist. Man muss es 'full-mesh' machen oder wenigstens sternförmig. Insbesondere hat die ASG einige Kommunikationsprobleme mit der SonicWALL hinsichtlich der IPSec-Policy - ob es zwischen drei Astaros geht, kann ich nicht sagen.  ;-(


    Gruß
    Tilman


    schon mal mit "schmutzigen" tricks versucht? also evtl. die eingehende verbindung von seite1 im hub (seite2) zu natten und dann wieder durch den tunnel zu seite3 zu schieben? nicht  wirklich schön ...

    bzgl. des tunnels zwischen sonicwall und asl: immer darauf achten, dass die lifetimes der keys in den ike phasen zu einander passen.

    aber machmal will es einfach nicht. hatte mal das problem zwischen pixen und draytek boxen. tunnel steht - aber besch..eidene performance ohne ersichtlichen grund.
Children
  • 0 in reply to gnujuba
    schon mal mit "schmutzigen" tricks versucht? also evtl. die eingehende verbindung von seite1 im hub (seite2) zu natten und dann wieder durch den tunnel zu seite3 zu schieben? nicht  wirklich schön ...


    Wie müsste man hier das Routing einrichten? Denn das Tunnel-Interface kann ich so einfach nicht in den Routingregeln angeben.

    bzgl. des tunnels zwischen sonicwall und asl: immer darauf achten, dass die lifetimes der keys in den ike phasen zu einander passen.


    Der Tunnel läuft jetzt stabil, aber der Weg dahin war mühsam... Die Policy ist extrem eingeschränkt in den Möglichkeiten. Die default policies der ASG z.B. versagen alle - das gibt es zwischen zwei ASG so zum Glück nicht.

    Gruß
    Tilman
  • 0 in reply to AstaroGuestIUser
    routing sollte vom kernel ja richtig durchgeführt werden, wenn der tunnel up ist. 
    nur interessehalber, kannst ja mal dein routing tabelle posten (tunnel up).
  • 0 in reply to gnujuba
    Ist auf den Astaros bei den VPNs strict routing aktiviert ?


    Gregor Kemter
  • 0 in reply to gkemter
    Ist auf den Astaros bei den VPNs strict routing aktiviert ?


    Gregor Kemter


    Strict routing ist deaktiviert - ich hatte es nie eingeschaltet, weil ich annahm, daß es in diesem Fall eher zu Schwierigkeiten führen würde. Hier die Routingtabelle:

    217.5.98.*** dev ppp0  proto kernel  scope link  src 217.91.13.yyy 
    217.5.98.*** dev ipsec0  proto kernel  scope link  src 217.91.13.yyy 
    192.168.100.0/24 dev ipsec0  proto 42  scope link  src 192.168.200.254 
    192.168.200.0/24 dev eth0  proto kernel  scope link  src 192.168.200.254 
    192.168.230.0/24 dev ipsec0  proto 42  scope link  src 192.168.200.254 
    127.0.0.0/8 dev lo  scope link 
    default via 217.5.98.*** dev ppp0  proto kernel 
    broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
    local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
    broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
    broadcast 192.168.200.0 dev eth0  table local  proto kernel  scope link  src 192.168.200.254 
    local 192.168.200.254 dev eth0  table local  proto kernel  scope host  src 192.168.200.254 
    broadcast 192.168.200.255 dev eth0  table local  proto kernel  scope link  src 192.168.200.254 
    local 217.91.13.yyy dev ppp0  table local  proto kernel  scope host  src 217.91.13.yyy 
    local 217.91.13.yyy dev ipsec0  table local  proto kernel  scope host  src 217.91.13.yyy 
    local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 

    .*** ist der ISP, .yyy ist die ASG extern, 192.168.200.0 ist in diesem Fall das local network.


    Gruß
    Tilman
  • 0 in reply to AstaroGuestIUser
    Wenn ich die Onlinehilfe richtig deute : 

    Strict Routing: If strict routing is enabled, VPN routing is done according to source and destination IP address (instead of only destination IP address).

    In this case, only those packets exactly matching the VPN tunnel definition are routed into the VPN tunnel. 

    As a consequence, you cannot use SNAT to add networks or hosts to the VPN tunnel, that are originally not part of the tunnel definition.

    On the other hand, without strict routing, you cannot have a mixed nencrypted/encrypted setup to the same network from different source addresses.


    Dann müsste es doch eigentlich gehen mit strict routing disabled und entsprechenden SNAT Regel.

    Gregor Kemter
Unfiltered HTML