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

Site2Site Ipsec will nicht

Hallo,

ich bin echt am verzweifeln. Folgendes Szenario habe ich:

Standort 1 (Titan)
eth0 192.168.123.1
eth1 Feste IPV4-Adresse (KabelBW Business)
ASG-320 neuste Firmware

Standort 2 (Pluto)
eth0 192.168.124.1
eth1 Dynamische IPV4-Adresse (O2 Business)
ASG-320 neuste Firmware

Entferntes Gateway Titan:
Gateway Typ nur antworten, Verteilter Schlüssel und das entfernte Netzwerk habe ich ein neues angelegt mit dem Namen Pluto und 192.168.124.0/24 als Adresse. Lokale Schnittstelle eth1 (WAN)

Entferntes Gateway Pluto:
Gateway Typ Verbindung initiieren, Gateway die feste IP von Titan, Verteilter Schlüssel und als entferntes Netzwerk neu angelegt 192.168.123.0/24

Verbindung Titan
Lokale Schnittstelle eth1 (WAN) lokale Netzwerke das interne 192.168.123.0/24

Verbindung Pluto
Lokale Schnittstelle eth1 (WAN) lokale Netzwerke das interne 192.168.124.0/24

Per pptp komme ich ohne Probleme von einem Client das jeweilie andere Netz rein.

Live-Protokoll auf Titan ist leer
Live-Protokoll auf Pluto bringt immer wieder die gleiche Fehlermeldung:

2014:02:22-14:57:31 Pluto-1 pluto[9726]: "S_*****" #2: ERROR: asynchronous network error report on ppp0 for message to 217.****** port 500, complainant 217.*******: No route to host [errno 113, origin ICMP type 3 code 1 (not authenticated)] 

die restlichen Einstellungen sind alle Standard, auch habe ich für beide die gleichen Richtlinien AES-256 gewählt.

Hat jemand eine Idee, was das noch sein könnte? Suche hat mir leider nicht weitergeholfen.

Viele Grüße und danke für alle Ideen und Tips


This thread was automatically locked due to age.
  • Hallo,

    Hängt vor den UTMs noch ein Router oder Firewall?
  • NAT? Richtiger Host? DNS Problem?

    Die Fehlermeldung ist recht eindeutig. Die Suche danach, auch hier im Forum und, in den drei gängigsten Suchmaschinen liefert die Lösungsansätze. Das lässt Deinen Satz "Suche hat mir leider nicht weitergeholfen" in keinem für Dich vorteilhaften Licht erscheinen.
  • @panic

    Die Fehlermendung im Live-Log ist da recht aussagekräftig:
     
    No route to host [errno 113, origin ICMP type 3 code 1 (not authenticated)] 

    Pluto erreicht das Remote-Gateway ( Titan ) nicht.

    Überprüfe nochmal auf Pluto, ob du tatsächlich die korrekte öffentliche IP-Adresse von Titan in der IPsec-Konfiguration angegeben hast.

    Gruß, Datax
  • Hallo

    erstmal Danke für die Antworten. Die Suche habe ich natürlich benutzt und auch entsprechende Antworten gefunden, aber leider hat nichts geholfen.

    Titan hängt hinter einer FB, die aber nur als Modem verwendet wird (KabelBW Firmware ist wohl nicht die aktuellste)

    Pluto hat zwei Leitungen, einmal mit FB und exposed Host eingetragen und eine zweite Leitung mit DSL-Modem und geht darüber auch direkt ins Netz.

    Beides ohne Nat, die FW erstellt über PPOE Zugriff und hat auch eine öffentliche IP.

    IP-Adresse stimmt auch zu 100 % dies habe ich bestimmt schon zehnmal geprüft.
  • @panic

    Beides ohne Nat, die FW erstellt über PPOE Zugriff und hat auch eine öffentliche IP.

    Das ist nicht ganz richtig.

    Wenn du auf der FritzBox einen Host als "Exposed Host" einträgst,
    dann nattet ( DNAT ) die FritzBox ALLE Zielports an den eingetragenen Host weiter.

    Auf Pluto ist die IPsec-Konfiguration ganz sicher nicht in Ordnung.

    Die Meldung "No route to host [errno 113, origin ICMP type 3 code 1 (not authenticated)] " bekommt man z.B. dann, wenn man auf der UTM ( IPsec-Konfiguration ) als "Local Network" beispielsweise 192.168.1.0/24 einträgt und als Interface die Schnittstelle auswählt, die selbst Teil dieses Netzes ist.

    Der User "jherm" hatte genau das gleiche Problem wie du und bei ihm lag es genau daran wie ich es oben beschrieben habe.

    Hier der Fall von "jherm":

    https://community.sophos.com/products/unified-threat-management/astaroorg/f/58/t/54843

    Kannst auch gerne mal die IPsec-Konfiguration von Pluto in Form von Screenshots schicken, dann kann man dazu genaueres sagen.

    Gruß, Datax
  • @panic

    Habe das gerade mal getestet.

    Auf "pluto" wird sehr wahrscheinlich das Tunnel-Interface eine IP-Adresse
    aus dem "Local Network" haben.

    Beispiel:

    Auf Pluto-Seite wurde als "Local Network" das Netz 192.168.1.0/24 angegeben.

    Als "Local Interface" wurde das Interface aus dem Netz 192.168.1.0/24 ausgewählt,
    z.B. 192.168.1.1.

    Dann kommt es zu dieser Fehlermeldung, die du bekommst.

    Bei UTM9 heißt die Fehlermeldung "cannot route -- route already in use".

    Gruß, Datax
  • Vielen Dank Datax, es läuft nun alles, wie es soll :-)

    Jetzt kommt die nächste Baustelle, ich möchte SSH-Traffic immer über VPN laufen lassen.

    Hintergrund ist die feste IP von Titan, da diese auf mehreren Servern eingetragen ist und ich nicht immer eine weitere VPN-Client Sitzung öffnen möchte.
  • @panic

    Mit den gegebenen Infos wird es schwierig sein dir bei dem SSH-Problem helfen zu können.

    Ich habe es bisher so verstanden, dass du irgendwo ( hinter Pluto vielleicht!? ) einen SSH-Server laufen hast, der ausschließlich Verbindungen von der externen IP-Adresse von Titan annimmt, ist das richtig?

    Musst du dich per SSL-VPN-Client mit Titan verbinden, um dann über Titan auf den SSH-Server hinter Pluto zuzugreifen?

    Falls ich völlig auf dem Holzweg bin, dann poste bitte einmal genaue Infos darüber von wo nach wo du eine SSH-Verbindung aufbauen möchtest und warum du diese unbedingt tunneln möchtest bzw. musst.

    Gruß, Datax
  • Hallo Datax,

    fast richtig :-)

    Wir verwalten ein paar Server, die auch per fester IP im Netz hängen (Webserver, Datenbankserver etc. im Rechenzentrum)

    Diese lassen teilweise nur Zugriffe über fest definierte IP-Adressen zu, wir verwenden daher immer die IP-Adresse von Titan. Von Pluto bzw. aus dessen Netz bauen wir daher immer PPTP Vpn Verbindungen von den einzelnen Clients aus auf zu Titan und von dort dann weiter auf die Server.

    Mein Wunsch wäre es, irgendwo zu definieren, dass sämtlicher SSH-Traffic über die VPN-Verbindung geroutet wird. Über ein normales Interface ist dies ja recht einfach möglich.

    VG
    Panic