Ipsec mit CentOS und openSUSE

Ich brauche Unterstützung bei der Einrichtung von ipsec unter openSUSE und racoon unter CentOS

Hallo Administratoren,

ich habe zwei Linux-Systeme hinter jeweils einem Router. Das OpenSUSE verwendet schon erfolgreich 3 Tunnel und der 4. soll nun mit einem CentOS kommunizieren können. Die notwendigien Ports/Protokolle (500, 4500, ESP, AH) sind alle dementsprechend geforwardet. Die PSK sind auf beiden Systemen natürlich gleich. Bis kurz vor Phase #3 schafft es der Tunnel scheinbar.

Zuerst die Konfiguration von ipsec.conf von openSUSE

version 2.0
config setup
        klipsdebug=none
        plutodebug=none
        nat_traversal=yes
        plutowait=yes
        nhelpers=0
        overridemtu=1420

conn aqua
        left=%defaultroute
        leftid=@host.dyndns.org
        leftnexthop=%defaultroute    
        leftsubnet=192.168.10.0/24
        right=196.203.181.XXX
        rightid=@196.203.181.XXX
        rightnexthop=%defaultroute 
        rightsubnet=10.64.1.0/24
        ike=3des-md5-modp1024!
        esp=3des-md5!
        auto=start                     
        auth=esp
        authby=secret
        pfs=yes
        pfsgroup=modp1024
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        compress=yes

Nun die Konfiguration von racoon.conf

Hinweis: "remote anonymous", damit dyndns funktioniert

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

# Phase 1
#
remote anonymous
{
 exchange_mode aggressive, main;
 generate_policy on;
 nat_traversal on;
 passive on;
 lifetime time 28800 seconds;
 my_identifier user_fqdn "@host.dyndns.org";
 proposal {
  encryption_algorithm 3des;
  hash_algorithm md5;
  authentication_method pre_shared_key;
  dh_group 2;
 }
}


# Phase 2
#
sainfo anonymous
{
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}

Und hier kommen nun die leidigen Fehlermeldungen, mit denen ich ab jetzt nicht mehr viel anfangen kann und auf Eure Unterstützung oder zumindest Ideeansatz hoffe:

Log von ipsec openSUSE

"aqua" #110: STATE_MAIN_I1: initiate
"aqua" #110: received Vendor ID payload [RFC 3947] method set to=110
"aqua" #110: received Vendor ID payload [Dead Peer Detection]
"aqua" #110: STATE_MAIN_I2: sent MI2, expecting MR2
"aqua" #110: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
"aqua" #110: STATE_MAIN_I3: sent MI3, expecting MR3
"aqua" #110: STATE_MAIN_I3: retransmission; will wait 20s for response
"aqua" #110: discarding duplicate packet; already STATE_MAIN_I3
"aqua" #110: discarding duplicate packet; already STATE_MAIN_I3
"aqua" #110: STATE_MAIN_I3: retransmission; will wait 40s for response
"aqua" #110: discarding duplicate packet; already STATE_MAIN_I3
"aqua" #110: discarding duplicate packet; already STATE_MAIN_I3

Log von racoon CentOS

2010-04-23 19:34:43: INFO: respond new phase 1 negotiation: 10.64.1.10[500]<=>84.148.78.XXX[500]
2010-04-23 19:34:43: INFO: begin Identity Protection mode.
2010-04-23 19:34:43: INFO: received Vendor ID: DPD
2010-04-23 19:34:43: INFO: received Vendor ID: RFC 3947
2010-04-23 19:34:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
2010-04-23 19:34:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2010-04-23 19:34:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2010-04-23 19:34:43: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
2010-04-23 19:34:43: INFO: Selected NAT-T version: RFC 3947
2010-04-23 19:34:43: INFO: Hashing 10.64.1.10[500] with algo #1
2010-04-23 19:34:43: INFO: NAT-D payload #0 doesn't match
2010-04-23 19:34:43: INFO: Hashing 84.148.78.XXX[500] with algo #1
2010-04-23 19:34:43: INFO: NAT-D payload #1 doesn't match
2010-04-23 19:34:43: INFO: NAT detected: ME PEER
2010-04-23 19:34:43: INFO: Hashing 84.148.78.XXX[500] with algo #1
2010-04-23 19:34:43: INFO: Hashing 10.64.1.10[500] with algo #1
2010-04-23 19:34:43: INFO: Adding remote and local NAT-D payloads.
2010-04-23 19:35:33: ERROR: phase1 negotiation failed due to time up. 19917dbe449fcf22:cbc078bb385e96a9
2010-04-23 19:35:53: INFO: respond new phase 1 negotiation: 10.64.1.10[500]<=>84.148.78.XXX[500]

Ich würde mich freuen, wenn ich zumindest einen Ansatz bekommen könnte, wo ich weitersuchen soll. Google hat mir dazu nur eine Problemlösung genannt: die MTU. Bei openSUSE habe ich sie schon reduziert, weil es mit den anderen Tunneln vorher auch Probleme gab. Und am CentOS hat der ISP die MTU auf 1500 erhöht.

Ich hoffe wirklich auf euch und danke Vorab.

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

Content-ID: 141344

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

Ausgedruckt am: 26.11.2024 um 18:11 Uhr

6 Kommentare

Neuester Kommentar

Die MTU zu erhöhen ist ja genau der falsche Weg, denn dann bekommst du noch mehr Probleme bei größeren Paketen. Das ist also genau kontraproduktiv. Die MTU muss auf den Tunnelinterfaces reduziert werden.

Dein Problem ist aber ein ganz anderes: Der Fehler taucht in der NAT Traversal discovery (NAT-D) auf. Dort kommt es zu einem Payload Mismatch.
http://www.faqs.org/rfcs/rfc3947.html
Es sieht so aus als ob eine Seite kein NAT-T macht oder es dort nicht aktiviert ist.
Was noch sein kann ist das der Session Cache für ESP beim Router voll ist mit 3 aktiven IPsec Sessions. Das kannst du leicht mal checken indem du die Router reloadest und NUR diese eine neue Session (Tunnel) versuchst aufzubauen. Kommt der Zusatande ist der Buhmann der Router.

Übrigens AH zu forwarden kannst du dir getrost sparen !!! IPsec AH ist niemals über NAT Router zu übertragen, da die IP durch NAT verändert wird und das gibt bei AH einen sofortigen Sessionabbruch. Über NAT Router kannst du einzig und allein nur IPsec ESP machen wenn du IPsec nutzt !!
Besser ist es immer die IPsec Sessions direkt auf dem Router zu terminieren, dann hat man diese Probleme mit dem Forwarding auf dem Router gar nicht erst.
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software

vielen Dank für die aussagekräftigen Infos...

ok, beide Seiten nutzen nun dieselbe MTU.

Dein Problem ist aber ein ganz anderes: Der Fehler taucht in der NAT Traversal discovery (NAT-D) auf. Dort kommt es zu einem
Payload Mismatch.
http://www.faqs.org/rfcs/rfc3947.html
Es sieht so aus als ob eine Seite kein NAT-T macht oder es dort nicht aktiviert ist.

Hm, also laut Log-File sprechen beide RFC3947. Aber sollte bei geNATeten Paketen nicht Port 4500 statt Port 500 genutzt werden?

Was noch sein kann ist das der Session Cache für ESP beim Router voll ist mit 3 aktiven IPsec Sessions. Das kannst du leicht
mal checken indem du die Router reloadest und NUR diese eine neue Session (Tunnel) versuchst aufzubauen. Kommt der Zusatande ist
der Buhmann der Router.

Dieses Problem kann ich nach einem Test ausschließen.

Übrigens AH zu forwarden kannst du dir getrost sparen !!! IPsec AH ist niemals über NAT Router zu übertragen, da
die IP durch NAT verändert wird und das gibt bei AH einen sofortigen Sessionabbruch. Über NAT Router kannst du einzig
und allein nur IPsec ESP machen wenn du IPsec nutzt !!
Besser ist es immer die IPsec Sessions direkt auf dem Router zu terminieren, dann hat man diese Probleme mit dem Forwarding auf
dem Router gar nicht erst.
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software

OK, und wieder etwas dazugelernt

Hmm, aber wie soll ich nun vorgehen, damit beide Gegenstellen den passenden Payload verwenden?!

Kann es evtl. auch daran liegen, dass der Cisco-Router die Ports und Protokolle manuell forwarded? Oder ist dabei VPN-passthrough zwingend erforderlich? (nur der ISP kann den Router konfigurieren).

.
"...Aber sollte bei geNATeten Paketen nicht Port 4500 statt Port 500 genutzt werden?"
A.: Nein, denn IKE nutzt immer fest UDP 500. Liest dir dazu bitte spacyfreaks UIPsec Tutorial durch:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen

Wenn deine beteiligten Geräte beide NAT Traversal supporten musst du bei IPsec gar nichts einstellen, dann NAT Traversal überwindet wie der Name schon sagt jeden NAT Router. Dazu wird Port UDP 4500 benutzt.
Ohne NAT Traversal kann IPsec ESP keinen NAT Router überwinden ohne ein dann zwingend notwendiges Port Forwarding von UDP 500 und dem ESP Protokoll (Protokoll Nummer 50, Achtung: nicht UDP/TCP 50 !!, ESP ist ein eigenes IP Protokoll)

Wenn du einen ISP Router benutzt auf den du keinen Zugang hast ist deine einzige Chance mit NAT Traversal zu arbeiten ansonsten kommt IPsec nicht durch ! Viele ISPs die eigene Router verwenden filtern auch oft IPsec, da VPN Support meist ein teurere Tarif ist.
Dann ist natürlich alles aus mit IPsec und du kannst nur SSL mit OpenVPN z.B. verwenden.
Das solltest du in jedem Falle mit dem ISP vorher klären.
Ein statische Port Forwarding auf den Cisco sieht dann so aus für IPsec ESP:

access-list 111 permit udp any eq 500
access-list 111 permit udp any eq 4500 (optional bei NAT Traversal)
access-list 111 permit esp any any

Wenn deine beteiligten Geräte beide NAT Traversal supporten musst du bei IPsec gar nichts einstellen, dann NAT Traversal
überwindet wie der Name schon sagt jeden NAT Router. Dazu wird Port UDP 4500 benutzt.
Ohne NAT Traversal kann IPsec ESP keinen NAT Router überwinden ohne ein dann zwingend notwendiges Port Forwarding von UDP 500
und dem ESP Protokoll (Protokoll Nummer 50, Achtung: nicht UDP/TCP 50 !!, ESP ist ein eigenes IP Protokoll)

Das mit Protokoll 50 ist mir klar, aber wie kann ich das Payload-Mismatch-Problem beim NAT-T suchen/beheben/manipulieren?

Wenn du einen ISP Router benutzt auf den du keinen Zugang hast ist deine einzige Chance mit NAT Traversal zu arbeiten ansonsten
kommt IPsec nicht durch ! Viele ISPs die eigene Router verwenden filtern auch oft IPsec, da VPN Support meist ein teurere Tarif
ist.
Dann ist natürlich alles aus mit IPsec und du kannst nur SSL mit OpenVPN z.B. verwenden.
Das solltest du in jedem Falle mit dem ISP vorher klären.

Also der ISP ist in Tunesien und hat die Rückmeldung gegeben, dass er UDP 500/4500 und ESP geforwarded hat und VPN im Tarif inkludiert ist.

Auf deinem Zugangsrouter musst du am WAN/DSL Interface die MTU verkleinern oder auf "Auto" stellen. Allerdings birg das "Auto" immer die Gefahr das das nicht klappt...viele Hersteller sind hier buggy so das ein statische Setting auf 1440 immer besser ist.

Auf deinem Zugangsrouter musst du am WAN/DSL Interface die MTU verkleinern oder auf "Auto" stellen. Allerdings birg das
"Auto" immer die Gefahr das das nicht klappt...viele Hersteller sind hier buggy so das ein statische Setting auf 1440
immer besser ist.

Erledigt, aber leider hat dies nicht das NAT-T-Problem behoben