« IPsec-Fehlermeldungen erklärt - Teil 2DPD - wie geht das ? »

IPsec-Fehlermeldungen erklärt - Teil 3

Veröffentlicht am 7 Jan 2006 um 10:47 pm. 12 Kommentare.
Gespeichert unter Tutorials, Tips & Tricks.

23:58:40 pluto[14958] packet from X.X.X.X:500: initial Main Mode message received on X.X.X.X:500 but no connection has been authorized with policy=PSK

Statt policy=PSK kann bei dieser Fehlermeldung alternativ auch policy=RSASIG stehen, wenn Zertifikate verwendet werden. Die Lösung ist unabhängig von der Verbindungsmethode.

Dies ist ein sehr häufiger Fehler der immer zu einem gescheiterten Verbindungsaufbau führt. Diese Meldung bedeutet, dass dieses Ende der Verbindung (wo dieser Eintrag im Log steht) eine IPsec-Verbindungsanfrage bekommen hat, die er nicht von der Source-IP X.X.X.X erwartet hat. In der Folge wird die Anfrage ignoriert und die Verbindung kommt nicht zustande.

Lösung 1:
Wenn die IP-Adresse X.X.X.X der erwarteten IP entspricht, solltest du als Erstes die lokale ipsec.conf und ipsec.secrets überprüfen, zu finden unter /var/ipcop/vpn/.

/var/ipcop/vpn/ipsec.conf (Ausschnitt mit der Verbindungskonfiguration)
conn abc
left=1.2.3.4
leftnexthop=%defaultroute
leftsubnet=192.168.2.0/255.255.255.0
right=5.6.7.8
rightsubnet=192.168.3.0/255.255.255.0
rightnexthop=%defaultroute
dpddelay=30
dpdtimeout=120
dpdaction=hold
authby=secret
auto=start

/var/ipcop/vpn/ipsec.secrets
: RSA /var/ipcop/certs/hostkey.pem
1.2.3.4 5.6.7.8 : PSK “GeheimesPasswort”

Stelle sicher, dass die verwendeten IP-Adressen für left und right mit den tatsächlichen IP-Adressen übereinstimmen und in beiden Dateien (ipsec.conf und ipsec.secrets) korrekt eingetragen sind, dann sollte dieser Fehler verschwinden.

Wenn FQDN’s im Spiel sind, vor allem in Verbindung mit DynDNS und 24h Zwangstrennung, solltest du natürlich zuerst die Namensauflösung überprüfen. Ein einfacher Ping vom IPCop auf den FQDN sollte Klarheit bringen. Wenn die Namensauflösung klappt, der Fehler aber nicht verschwindet, solltest du es zuerst einmal mit IP-Adressen versuchen. Diese müssen dann natürlich in allen oben genannten Dateien, oder über das Web-GUI angepasst werden.

Lösung 2:
Eine alternative Fehlerursache kann auch ein NAT-Device (Router) vor dem Remote-Client sein. In diesem Fall ist die WAN-IP (RED) des Remote-IPCop’s eine private Adresse. In der Verbindungskonfiguration des lokalen IPCops ist aber vermutlich die externe IP des NAT-Devices (Routers) hinterlegt.

Um dieses Problem zu lösen, muss die private IP-Adresse von RED sowohl in der ipsec.conf, als auch in der ipsec.secrets hinzugefügt werden. Dies geschieht für die Datei ipsec.conf mit Hilfe von rightid=192.168.0.2, wobei 192.168.0.2 als IP-RED angenommen wird. In der Datei ipsec.secrets muss nur die IP-Adresse hinterlegt werden.

/var/ipcop/vpn/ipsec.conf (Ausschnitt mit der Verbindungskonfiguration)
conn abc
left=1.2.3.4
leftnexthop=%defaultroute
leftsubnet=192.168.2.0/255.255.255.0
right=5.6.7.8
rightid=192.168.0.2 ####An die private IP-Adresse von IPCop-RED anpassen !!
rightsubnet=192.168.3.0/255.255.255.0
rightnexthop=%defaultroute
dpddelay=30
dpdtimeout=120
dpdaction=hold
authby=secret
auto=start

/var/ipcop/vpn/ipsec.secrets
: RSA /var/ipcop/certs/hostkey.pem
1.2.3.4 5.6.7.8 192.168.0.2 : PSK “GeheimesPasswort”

Viel Spass bei der Fehlersuchen ;-)

Gruss
Ecki

12 Kommentare zu ‘IPsec-Fehlermeldungen erklärt - Teil 3’:

  1. JoachimK am 30 May 2006 um 11:15 pm: 1

    Hi,
    ich bekomme genau so eine Fehlermeldung. Mein setup:

    Roadwarrior internet DSL-Router (FritzBox) ipcop

    RED: 192.168.178.0/24
    DSL-Router: 192.168.178.1
    IPcop: 192.168.178.10

    GREEN: 192.168.1.0/24
    IPCop: 192.168.1.1
    + div. andere

    Wenn ich versuche, von dem RW einen Rechner im grünen Netz per ping
    zu erreichen, dann erscheint im logfile des ipcop:
    “packet from w.x.y.z:500: initial Main Mode message
    received on 192.168.178 .10:500 but no connection
    has been authorized with policy=RSASIG”

    Da der DSL-Router NAT macht, habe ich, dem zweiten Lösungsvorschlag folgend, in ipsec.conf
    eine Zeile mit “leftid=192.168.178.10″ eingefügt.
    Leider ohne Erfolg - das logfile sieht exakt gleich aus!

    Woran könnte es sonst noch hängen?
    Die Verbindung ist eingerichtet, alle Zertifikate installiert,
    und sonst kommen auch keine Fehlermeldungen?

    Gruß, Joachim.
    P.S. Vielen Dank für die tolle website!

  2. Ecki am 31 May 2006 um 9:30 pm: 2

    Hast du den Eintrag in der ipsec.secrets auch angepasst ?

    Stehen beide IPCop hinter einem NAT-Router ?

    Hast du die Änderungen dann auch auf beiden IPCop gemacht ?

    Gruss
    Ecki

  3. JoachimK am 1 Jun 2006 um 12:02 am: 3

    Es gibt nur einen ipcop, der Partner ist ein Roadwarrior (WinXP SP2, Verbindung eingerichtet mit dem Tool von Marcus Müller).
    ipsec.secrets habe ich nicht angepasst, da ich X.509-certs benutze und daher ohnehin nur die Zeile
    “: RSA /var/ipcop/certs/hostkey.pem”
    drinsteht. Oder muss ich da trotzdem die IP-Adresse mit reinschreiben?

    Beim Roadwarrior habe ich keine Anpassung gemacht.

    Ich weiss nicht ob’s hilft, aber hier mal meine ipsec.conf:
    8

  4. JoachimK am 1 Jun 2006 um 12:07 am: 4

    irgendwie hat das webinterface meine ipsec.conf geschluckt. zweiter Versuch:

    root@ipcop1:/var/ipcop/vpn # cat ipsec.conf
    config setup
    interfaces=%defaultroute
    klipsdebug=none
    plutodebug=”none”
    plutoload=%search
    plutostart=%search
    uniqueids=yes
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.1.0/255.255.255.0,%v4:!192.168.2.0/255.255.255.0

    conn %default
    keyingtries=0
    disablearrivalcheck=no

    conn joalapspk
    left=abcdefgh.dyndns.org
    leftnexthop=%defaultroute
    leftsubnet=192.168.1.0/255.255.255.0
    leftcert=/var/ipcop/certs/hostcert.pem
    right=%any
    rightsubnet=vhost:%no,%priv
    rightcert=/var/ipcop/certs/joalapspkcert.pem
    ike=aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
    esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
    ikelifetime=1h
    keylife=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=clear
    pfs=yes
    authby=rsasig
    auto=add

    root@ipcop1:/var/ipcop/vpn #

  5. Ecki am 1 Jun 2006 um 9:19 pm: 5

    Bitte füge die IP-Adresse auch in die Datei ipsec.secrets ein.

    Gruss
    Ecki

  6. Wingie am 13 Jul 2006 um 9:13 pm: 6

    Hi there,

    I’ve got the same problem here, and up to now didn’t find a solution read something about a bug in strongswan but don’t know exact what ipcop is using.

    Below you find an overview and after that the config files:

    Wingie’s side (left) || real ipadres Livebox 192.168.1.1 192.168.1.10 IpCop Server 192.168.72.10 192.168.72/24 (private network)
    Bonus’s side (right) || real ipadres IpCop Server 192.168.73.1 192.168.73/24 (private network)

    PS firewall in my livebox has been disabled just as dhcp.

    ipsec.conf (Wingie’s Side)
    Code:
    config setup
    interfaces=%defaultroute
    klipsdebug=none
    plutodebug=”none”
    plutoload=%search
    plutostart=%search
    uniqueids=yes
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.72.0/255.255.255.0,%v4:!192.168.73.0/255.255.255.0

    conn %default
    keyingtries=0
    disablearrivalcheck=no

    conn bonus
    left=192.168.1.10 => this is because this is the ipaddress of the red interface in Ipcop
    #leftid=real ipadres wingie => have also tried to add this but didn’t help
    leftnexthop=%defaultroute
    leftsubnet=192.168.72.0/255.255.255.0
    right=real ipadres bonus
    rightsubnet=192.168.73.0/255.255.255.0
    rightnexthop=%defaultroute
    ike=aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
    esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
    ikelifetime=1h
    keylife=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=hold
    pfs=yes
    authby=secret
    auto=start

    ipsec.conf (Bonus’s Side)
    Quote:
    Just tried and change right to left in this config and visa versa but now it stops with the message
    “bonus” #25: initiating Main Mode
    packet from xx.xx.xx.xx:500: received Vendor ID payload [RFC 3947]
    packet from xx.xx.xx.xx:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
    packet from xx.xx.xx.xx:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
    packet from xx.xx.xx.xx:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
    packet from xx.xx.xx.xx:500: received Vendor ID payload [Dead Peer Detection]
    “bonus” #26: responding to Main Mode
    “bonus” #26: transition from state (null) to state STATE_MAIN_R1
    “bonus” #26: NAT-Traversal: Result using RFC 3947: i am NATed
    “bonus” #26: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
    “bonus” #26: max number of retransmissions (2) reached STATE_MAIN_R2

    Code:
    config setup
    interfaces=%defaultroute
    klipsdebug=none
    plutodebug=”none”
    plutoload=%search
    plutostart=%search
    uniqueids=yes
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!192.168.73.0/255.255.255.0,%v4:!192.168.72.0/255.255.255.0

    conn %default
    keyingtries=0
    disablearrivalcheck=no

    conn wingie
    right=real ipadres bonus
    rightsubnet=192.168.73.0/255.255.255.0
    rightnexthop=%defaultroute
    left=real ipadres wingie
    leftid=192.168.1.10 => added this line because Ipcop server is behind the livebox router so this is the red interface address.
    leftsubnet=192.168.72.0/255.255.255.0
    leftnexthop=%defaultroute
    ike=aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
    esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
    ikelifetime=1h
    keylife=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=hold
    pfs=yes
    authby=secret
    auto=start

    ipsec.secrets
    192.168.1.10 realipadres wingie realipadres bonus: PSK “password”

    If necessary I can post more information about the network configs.

    I hope someone can help us,
    Regards Wingleader

    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
    192.168.1.0 * 255.255.255.0 U 0 0 0 ipsec0
    192.168.72.0 * 255.255.255.0 U 0 0 0 eth0
    default 192.168.1.1 0.0.0.0 UG 0 0 0 eth1

  7. Ecki’s Place : Update 1.4.11 - Neue VPN Features am 26 Aug 2006 um 7:04 pm: 7

    […] Bei Roadwarrior Konfigurationen ist es nun möglich, über die GUI den Parameter “leftid” bzw. “rightid” zu setzen, s. diesen Beitrag […]

  8. thausmann am 23 Mar 2007 um 6:04 pm: 8

    Hallo zusammen,

    Der Parameter rightid=192.168.0.2 lässt sich so gar nicht setzen weil die GUI meldet es müsse ein @ Zeichen verwendet werden. Wollte dieses nämlich tun da meine VPN Verbindung scheitert weil der IPCop scheinbar sein Gegenüber nicht erkennt.

    packet from … but no connection has been authorized with policy=RSASIG.

    Verbindung ist zwischen zwei IPCops definiert mit Zertifikaten. Zertifikate und Parameter stimmen hundertprozentig.

    Wenn ich dann zusätzlich eine Road Warrior Verbindung mit Zertifikat definiere dann kommt die Verbindung zwichen den IPCops zustande. Beim Aushandeln geht der eine IPCop zuerst auf die Road Warrior Verbindung und switched dann um auf die eigentlich definerte Verbindung!?

    17:07:41 pluto[872] “IPCop1″ #163890: IPsec SA established
    17:07:41 pluto[872] “IPCop1″ #163890: transition from state STATE_QUICK_R1 to state STATE_QUICK_R 2
    17:07:41 pluto[872] “IPCop1″ #163890: Dead Peer Detection (RFC3706) enabled
    17:07:41 pluto[872] “IPCop1″ #163889: IPsec SA established
    17:07:41 pluto[872] “IPCop1″ #163889: transition from state STATE_QUICK_R1 to state STATE_QUICK_R 2
    17:07:41 pluto[872] “IPCop1″ #163889: Dead Peer Detection (RFC3706) enabled
    17:07:41 pluto[872] “IPCop1″ #163890: transition from state (null) to state STATE_QUICK_R1
    17:07:41 pluto[872] “IPCop1″ #163890: responding to Quick Mode
    17:07:41 pluto[872] “IPCop1″ #163889: transition from state (null) to state STATE_QUICK_R1
    17:07:41 pluto[872] “IPCop1″ #163889: responding to Quick Mode
    17:07:41 pluto[872] “IPCop1″ #163888: sent MR3, ISAKMP SA established
    17:07:41 pluto[872] | NAT-T: new mapping xxx.xxx.xxx.xxx:500/4500)
    17:07:41 pluto[872] “sth7srv71″ #163888: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
    17:07:41 pluto[872] “sth7srv71″ #163888: deleting connection “THausmann” instance with peer xxx.xxx.xxx.xxx
    17:07:41 pluto[872] “RoadWaarior”[1] xxx.xxx.xxx.xxx:4500 #163888: Issuer CRL not found
    17:07:41 pluto[872] “RoadWaarior”[1] xxx.xxx.xxx.xxx:4500 #163888: Issuer CRL not found
    17:07:41 pluto[872] “RoadWaarior”[1] xxx.xxx.xxx.xxx:4500 #163888: Main mode peer ID is ID_DER_ASN1_DN: ‘C =xx, ST=xx, O=xx, OU=xx, CN=xxxxxx’
    17:07:40 pluto[872] “RoadWaarior”[1] xxx.xxx.xxx.xxx:4500 #163888: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
    17:07:40 pluto[872] “RoadWaarior”[1] xxx.xxx.xxx.xxx:4500 #163888: NAT-Traversal: Result using RFC 3947: i am NATed
    17:07:40 pluto[872] “RoadWaarior”[1] xxx.xxx.xxx.xxx:4500 #163888: transition from state (null) to state S TATE_MAIN_R1
    17:07:40 pluto[872] “RoadWaarior”[1] xxx.xxx.xxx.xxx:4500 #163888: responding to Main Mode from unknown pe er xxx.xxx.xxx.xxx:4500
    17:07:40 pluto[872] packet from xxx.xxx.xxx.xxx:4500: received Vendor ID payload [Dead Peer Detection]
    17:07:40 pluto[872] packet from xxx.xxx.xxx.xxx:4500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t -ike-00]
    17:07:40 pluto[872] packet from xxx.xxx.xxx.xxx:4500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t -ike-02]
    17:07:40 pluto[872] packet from xxx.xxx.xxx.xxx:4500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t -ike-03]
    17:07:40 pluto[872] packet from xxx.xxx.xxx.xxx:4500: received Vendor ID payload [RFC 3947]

    Vielleicht kann mir da jemand etwas dazu sagen.

    Danke

    Gruß

    THausmann

  9. Ecki am 23 Mar 2007 um 10:11 pm: 9

    Wenn du die IP-Adresse als @192.168.0.2 in der GUI eingibst, wird die Einstellung problemlos übernommen. Dieses Feld existierte in früheren IPCop Versionen noch nicht. Erst sein der 1.4.11 kann die rightid über die GUI konfiguriert werden.

    Gruss
    Ecki

  10. EQ5 am 9 Jan 2008 um 2:43 pm: 10

    Hallo zusammen,

    ich bekomme den Fehler auch. Habe den oben genannten Lösungsweg 2 habe ich versucht doch ohne Erfolg.

    Mein Netz sieht folgendermaßen aus:
    (green 192.168.50.2)IPCOPHome(red 192.168.178.20)-(192.168.178.1)Fritzbox-
    DSL-ISDN(Testzwecke)-(red öffentlicheIP)IPCOPOff(green 192.168.0.11)

    Die beiden ConfigFiles des IpcopHome
    ipsec.conf
    config setup
    interfaces=”%defaultroute ”
    klipsdebug=”none”
    plutodebug=”crypt parsing emitting control klips dns nat_t ”
    plutoload=%search
    plutostart=%search
    uniqueids=yes
    nat_traversal=yes
    overridemtu=1000
    virtual_private=%v4:10.0.0.0/8,%v4:
    172.16.0.0/12,%v4:192.168.0.0/16,%v4:
    !192.168.50.0/255.255.255.0,%v4:!
    192.168.60.0/255.255.255.0,%v4:!
    192.168.0.200/255.255.255.0

    conn %default
    keyingtries=0
    disablearrivalcheck=no

    conn Net2NetOff #RED
    left=77.188.0.128
    leftnexthop=%defaultroute leftsubnet=192.168.50.0/255.255.255.0
    right=89.51.57.60
    rightid=192.168.178.20/255.255.255.0
    rightsubnet=192.168.0.200/255.255.255.0
    rightnexthop=%defaultroute
    ike=aes128-sha-modp1536,aes128-sha-modp1024,
    aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,
    3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
    esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
    ikelifetime=1h
    keylife=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=hold
    pfs=yes
    authby=secret
    auto=start

    ipsec.secrets
    77.188.0.128 89.51.57.60 192.168.178.20 : PSK ‘passwort’

    ie beiden ConfigFiles des IpcopOff
    ipsec.conf
    config setup
    interfaces=”%defaultroute ”
    klipsdebug=”none”
    plutodebug=”crypt parsing emitting control klips dns nat_t ”
    plutoload=%search
    plutostart=%search
    uniqueids=yes
    nat_traversal=yes
    overridemtu=1000
    virtual_private=%v4:10.0.0.0/8,
    %v4:172.16.0.0/12,%v4:192.168.0.0/
    16,%v4:!192.168.0.0/255.255.255.0,
    %v4:!192.168.50.20/255.255.255.0

    conn %default
    keyingtries=0
    disablearrivalcheck=no

    conn Net2NetHome #RED
    left=89.51.57.60
    leftnexthop=%defaultroute
    leftsubnet=192.168.0.0/255.255.255.0
    right=77.188.0.128
    rightsubnet=192.168.50.20/255.255.255.0
    rightnexthop=%defaultroute
    ike=aes128-sha-modp1536,aes128-sha-modp1024,
    aes128-md5-modp1536,aes128-md5-modp1024,
    3des-sha-modp1536,3des-sha-modp1024,
    3des-md5-modp1536,3des-md5-modp1024
    esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
    ikelifetime=1h
    keylife=8h
    dpddelay=30
    dpdtimeout=120
    dpdaction=hold
    pfs=yes
    authby=secret
    auto=start

    ipsec.secrets
    89.51.57.60 77.188.0.128 : PSK ‘passwort’

    Mein erster Verdacht war, dass es beim COPhome ein Problem mit der Rotenschnittstelle gibt. Doch komischer weiße bekomme ich die Meldung beim COPOff der gar nicht hinter einem Router sitzt. Die Adresse in der conf und secret hab ich nachgeschaut konnte aber keinen Fehler entdecken.
    Vielleicht findest du noch etwas. Danke schon mal im Vorraus

    Gruß Manu

  11. normi am 7 Nov 2008 um 11:47 am: 11

    Hallo zusammen,

    wir versuchen schon seit längerem eine roadwarrior vpn verbindung zu unserm ipcop ( version 1.4.19 ) mit zertifikaten herzustellen.
    intern, also nicht über das internet hat das auch in mehrern versuchen geklappt, dank der sehr infomativen anleitungen.
    leider scheitern wir aber daran wenn wir das vpn zum ipcop dann über das internet aufbauen wollen.

    ich muss dazu sagen, das die red schnittstelle des ipcop nicht direkt im internet hängt sondern an der fritzbox 7050. als vpn client haben wir den tauvpn (version 0.43) verwendet.wenn man ins logfile schaut ist zu sehen das dieser sich als endpoint mit der öffentlichen ip der fritzbox verbindet.in dieser ist zwar alles in richtung ipcop durchgewardet ( esp; udp 500 usw )aber leider kommt die verbindung nicht zustande. wir möchten gerne zertifikate verwenden. kann es sein das ipsec über den fitz nat router gar nicht funktioniert und der ipcop direkt sich mit dem provider verbinden muss? ich weiß momentan nicht weiter, bitte um hilfe. danke im vorraus.
    gruß norman

  12. Ecki am 9 Nov 2008 um 9:54 pm: 12

    Hallo Norman

    Ist der “rightid=” Parameter auf dem IPCop korrekt gesetzt (auf die externe IP der Fritzbox) :?:

    Gruss
    Ecki

Kommentar/Ergänzungen schreiben

(wird nicht veröffentlicht)

:mrgreen: :| :twisted: :arrow: 8O :) :? 8) :evil: :D :idea: :oops: :P :roll: ;) :cry: :o :lol: :x :( :!: :?: