shrimps
Apr 23, 2010, updated at Oct 18, 2012 (UTC)
view5618
view6
1
Goto Top

Ipsec mit CentOS und openSUSE

GermanQuestionRedHat, CentOS, FedoraLinux

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.

back-to-topZuerst 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

back-to-topNun 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:

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

back-to-topLog 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.
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 141344

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

Printed on: April 25, 2024 at 18:04 o'clock

6 Comments
Latest comment
Goto Top
Member: aqui
aqui Apr 24, 2010, updated at Oct 18, 2012 at 16:41:51 (UTC)
Goto Top
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
Member: shrimps
shrimps Apr 24, 2010, updated at Oct 18, 2012 at 16:41:51 (UTC)
Goto Top
vielen Dank für die aussagekräftigen Infos...

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.

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 face-smile

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).
Member: aqui
aqui Apr 25, 2010, updated at Oct 18, 2012 at 16:41:51 (UTC)
Goto Top
.
"...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
Member: shrimps
shrimps Apr 25, 2010 at 17:06:00 (UTC)
Goto Top
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.
Member: aqui
aqui Apr 26, 2010 at 09:58:56 (UTC)
Goto Top
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.
Member: shrimps
shrimps Apr 26, 2010 at 10:02:06 (UTC)
Goto Top
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 face-sad
GermanQuestionRedHat, CentOS, FedoraLinux
Hotly discussed
gleixnerdCheck of ZFW Firewallgleixnerd - 5 Comments