IKV2+Lancom VPN Client+Zertifikate

[w.blecker]

Ich habe hier mal wieder einen komischen Fehler:

Windows 11 + Advanced VPN Client (6.22)

Dieser soll ich mittels Zertfiakt an einem ISG 5000 anmelden. Einige Site2Site Verbindung sind über Zertikate da auch schon relisiert. Gateway seitig sollte also alles in Ordnung sein.

Clientseitig ist das ja an und für sich auch kein Hexenwerk. Man errstelle ein entpsrechendes Zertfikat, speicher das als pks#12 ab und importiert es wieder auf dem Client. Dann sagt man dem Client unter Zertifikate->ComputerZertifikate Benutze den Computer Zertfikatsspeicher und die Benutzer CN die im Zertfikat steht + Eintrag bei Benutzerzertifikat. So wie es in dieser Anleitung steht ... https://knowledgebase.lancom-systems.de ... =120062085

Beim Verbindungsaufbau bekomme ich dann erzählt XAUTH Wrong User ID or Passwort.

(Es hab wohl mal ein Problem das man Digital Signatur einstellen muss und nicht (wie in alten Anleitungen beschrieben) RSA Signatur.
Warum das auf einmal bei Site2Site Verbindung anders ist als beim Verbindungen zum VPN Client --- man weis es nicht und munkelt.

Ich habe auch mal auf dem Gateway VPN Debug und IKE protokolliert, da war jetzt auch nicht ungewöhnliches zusehen. Zumindest konnte man sehen, das das richtige Zertfikat vom Client kommt.

Das ist alles ein wenig nebolös ... Hat da irgendjemand eine Idee ?

[Frühstücksdirektor]

So ohne Traces fällt mir nichts ein. Wir brauchen wohl VPN-Status + VPN-Debug Trace und sogar das VPN-Client Logbuch...

[w.blecker]

Im Log vom Client habe ich jetzt gesehen :

Monitor CSP: Das Zertifikat konnte nicht gefunden werden (Hardware Zertifikat)

Wenn ich aber unter Verbindung -> Zertfikate schaue bekomme ich das Richtige Benutzerzertfikat dort angezeigt ...

Hier ist mal ein Log vom Client
14.08.2024 12:36:19 - IPSec: Start building connection
14.08.2024 12:36:19 - IpsDial: Created the following list of provider links:
14.08.2024 12:36:19 - Found default route,NextHop=192.168.254.201,Metric=50,Ifindex=5
14.08.2024 12:36:19 - IpsDial: connection time interface choice,LocIpa=192.168.254.58,AdapterIndex=203,OsIndex=5
14.08.2024 12:36:19 - *********** retrieve_tep() ******************
14.08.2024 12:36:19 - IPSec: DNSREQ: resolving GW=<vpn.City.de> over lan:
14.08.2024 12:36:19 - IPSec: DNSREQ resolved vpn ipadr=08.15.47.11,ipadr6=0.0.0.0
14.08.2024 12:36:19 - ipsdial: resolved at least one remote tunnel endpoint.
14.08.2024 12:36:19 - Found default route,NextHop=192.168.254.201,Metric=50,Ifindex=5
14.08.2024 12:36:19 - IpsDial: connection time interface choice,LocIpa=192.168.254.58,AdapterIndex=203,OsIndex=5
14.08.2024 12:36:19 - IkeV2: ConRef=12, IkeSa2Created - totnumikesa's=1
14.08.2024 12:36:19 - Ikev2: Opening connection in PATHFINDER mode : ADSL_GATE_1-HO-CLIENT-1
14.08.2024 12:36:19 - Ikev2: Outgoing connect request IKEv2 mode - gateway=08.15.47.11 : ADSL_GATE_1-HO-CLIENT-1
14.08.2024 12:36:19 - Ikev2: ConRef=12, XMIT_MSG1_INIT, name=ADSL_GATE_1-HO-CLIENT-1, vpngw=08.15.47.11:500
14.08.2024 12:36:19 - srcadr=192.168.254.58:10952, dstadr=08.15.47.11:500,icookie=75.17.58.62.cd.d1.9a.eb,rcookie=00.00.00.00.00.00.00.00,exchange=IKE_SA_INIT,msgid=00000000,flags=00
14.08.2024 12:36:19 - Ikev2: ConRef=12, RECV_MSG2_INIT, adapterindex=203,name=ADSL_GATE_1-HO-CLIENT-1, remote ip:port=08.15.47.11:500,local ip:port=192.168.254.58:10952
14.08.2024 12:36:19 - Ikev2: ConRef=12,Received notify messages -
14.08.2024 12:36:19 - IPSec: set_local_properties, adapterindex=203,ikelocalip=192.168.254.58
14.08.2024 12:36:19 - Ikev2: Notifymsg=<IKEV2_NOTIFY_NAT_DETECTION_SOURCE_IP>
14.08.2024 12:36:19 - Ikev2: Notifymsg=<IKEV2_NOTIFY_NAT_DETECTION_DESTINATION_IP>
14.08.2024 12:36:19 - Ikev2: Notifymsg=<SIGNATURE_HASH_ALGORITHMS>
14.08.2024 12:36:19 - Ikev2: Notifymsg=<IKEV2_FRAGMENTATION_SUPPORTED>
14.08.2024 12:36:19 - Ikev2: Turning on NATD mode - ADSL_GATE_1-HO-CLIENT-1 - 1
14.08.2024 12:36:19 - IPSec: Final Tunnel EndPoint is=08.15.47.11
14.08.2024 12:36:19 - Ike: Turning on IKE fragment mode - ADSL_GATE_1-HO-CLIENT-1
14.08.2024 12:36:19 - Ikev2: RECV_MSG2_INIT - ConRef=12, Remote supports IKEv2 fragmentation
14.08.2024 12:36:19 - IKESA2_INIT: - ConRef=12, protection suite:
14.08.2024 12:36:19 - PID=1,#ENCR=12,KEYLEN=256,INTEG=12,PRF=5,DHGRP=14,AUTHM=0,CERTON=1
14.08.2024 12:36:19 - INSPIL=0,INSPI=00000000,OUTSPIL=0,OUTSPI=00000000,LifeType=1,LifeSec=28800,LifeKb=50000
14.08.2024 12:36:19 - Ike: ConRef=12, XMIT_MSG1_AUTH, name=ADSL_GATE_1-HO-CLIENT-1, vpngw=08.15.47.11:4500
14.08.2024 12:36:19 - Ike: ConRef=12, Turning on NAT Keep Alive Timer=35 seconds
14.08.2024 12:36:19 - IPSec: Phase1 is Ready,AdapterIndex=203,IkeIndex=12,LocTepIpAdr=192.168.254.58,AltRekey=1
14.08.2024 12:36:19 - Auth: ConRef=12, PKI response with errorcode=0.
14.08.2024 12:36:19 - Ike: ConRef=12, XMIT_MSG1_AUTH_RESUME0, name=ADSL_GATE_1-HO-CLIENT-1, vpngw=08.15.47.11:4500
14.08.2024 12:36:19 - srcadr=192.168.254.58:10954, dstadr=08.15.47.11:4500,icookie=75.17.58.62.cd.d1.9a.eb,rcookie=8e.98.b9.58.2c.8c.7a.44,exchange=IKE_AUTH,msgid=00000001,flags=01
14.08.2024 12:36:19 - Ikev2:send idi payload:ID_DER_ASN1_DN:pid=0,port=0,3081b9310e300c06
14.08.2024 12:36:19 - Auth: ConRef=12, PKI response with errorcode=0.
14.08.2024 12:36:19 - Ike: ConRef=12, XMIT_MSG1_AUTH_RESUME1, name=ADSL_GATE_1-HO-CLIENT-1, vpngw=08.15.47.11:4500
14.08.2024 12:36:19 - Auth: ConRef=12,Local is authenticating with=14,SIGNATURE (RFC7427)
14.08.2024 12:36:19 - Auth: ConRef=12,Local is using hash algorithm SHA2-256
14.08.2024 12:36:19 - Auth: ConRef=12,Local is using RSA-PSS padding
14.08.2024 12:36:19 - IkeV2: ConRef=12,Send CFG(CP) request payload -
14.08.2024 12:36:19 - IkeV2: ConRef=12,cfg_attr=1,IKECFG_ATTR_INTERNAL_IP4_ADDRESS=0
14.08.2024 12:36:19 - IkeV2: ConRef=12,cfg_attr=2,IKECFG_ATTR_INTERNAL_IP4_NETMASK=0
14.08.2024 12:36:19 - IkeV2: ConRef=12,cfg_attr=3,IKECFG_ATTR_INTERNAL_IP4_DNS=0
14.08.2024 12:36:19 - IkeV2: ConRef=12,cfg_attr=4,IKECFG_ATTR_INTERNAL_IP4_NBNS=0
14.08.2024 12:36:19 - IkeV2: ConRef=12,cfg_attr=20002,IKECFG_ATTR_NCP_SEM=0
14.08.2024 12:36:19 - IkeV2: ConRef=12,cfg_attr=13,IKECFG_ATTR_INTERNAL_IP4_SUBNET=0
14.08.2024 12:36:19 - IkeV2: ConRef=12,cfg_attr=25,IKECFG_ATTR_INTERNAL_DNS_DOMAIN=0
14.08.2024 12:36:19 - Ikev2 Child: ConRef=12,send request TSI=0.0.0.0-255.255.255.255
14.08.2024 12:36:19 - Ikev2 Child: ConRef=12,send request TSR=0.0.0.0-255.255.255.255
14.08.2024 12:36:19 - Isakmp: ConRef=12,Sending RFC7383 fragment with length=1000,sequence=1,total fragments=2
14.08.2024 12:36:19 - Isakmp: ConRef=12,Sending RFC7383 fragment with length=817,sequence=2,total fragments=2
14.08.2024 12:36:19 - Isakmp: ConRef=0,Receiving RFC7383 fragment, length=1048, sequence=1, total fragments=2
14.08.2024 12:36:19 - Isakmp: ConRef=0,Receiving RFC7383 fragment, length=328, sequence=2, total fragments=2
14.08.2024 12:36:19 - Ike: ConRef=12, RECV_MSG2_AUTH, name=ADSL_GATE_1-HO-CLIENT-1, vpngw=08.15.47.11:4500
14.08.2024 12:36:19 - Ikev2: ConRef=12,Received notify messages -
14.08.2024 12:36:19 - Ikev2: Notifymsg=<IKEV2_NOTIFY_INTERNAL_ADDRESS_FAILURE>
14.08.2024 12:36:19 - Ikev2: ConRef=12,Received notify ERROR message -
14.08.2024 12:36:19 - Ikev2: Notifymsg=<IKEV2_NOTIFY_INTERNAL_ADDRESS_FAILURE>
14.08.2024 12:36:19 - ERROR - 2110: XAUTH wrong UserId or Password
14.08.2024 12:36:19 - IPSec: AUTOMEDIA DETECT - Tried all available media types
14.08.2024 12:36:19 - IPSec: Disconnected from ADSL_GATE_1-HO-CLIENT-1 on channel 1.
14.08.2024 12:36:19 - INFO - MONITOR: Communication Medium changed - Wi-Fi => Automatic
14.08.2024 12:36:19 - INFO - MONITOR: Disconnected
14.08.2024 12:36:19 - INFO - MONITOR: Media=Wi-Fi, Tx=0 Byte, Rx=0 Byte
14.08.2024 12:36:20 - srcadr=192.168.254.58:10954, dstadr=08.15.47.11:4500,icookie=75.17.58.62.cd.d1.9a.eb,rcookie=8e.98.b9.58.2c.8c.7a.44,exchange=INFORMATIONAL,msgid=00000002,flags=01
14.08.2024 12:36:20 - IkeV2: ConRef=12, IkeSa2Deleted - totnumikesa's=0

[GrandDixence]

/Setup/VPN/IKEv2/IKE-CFG/IPv4 korrekt konfigurieren. Siehe entsprechende VPN-Anleitung unter:
fragen-zum-thema-vpn-f14/windows-phone- ... tml#p86774

Im Trace VPN-Debug wäre ersichtlich, dass der LANCOM-Router den VPN-Tunnelaufbau bei der Wahl der an den VPN-Client zu vergebende IPv4-Adresse abbricht.

[Frühstücksdirektor]

Der Client bekommt vom Router keine IPv4-Adresse zugewiesen.
Zwei möglich Gründe:
- CFG-Mode ist nicht als Server konfiguriert
- Kein Pool konfiguriert oder Pool erschöpft

In der Tat müsstest Du den Fehler auf dem Router suchen.

[w.blecker]

Ja das habe ich auch gesehen, aber nachdem die Verbindung angelegt war mit PSK hat es funktioniert ... Der IKE Config Mode steht auf Server und der Pool ist auch ausgewählt. Der Fehler trat erst auf nachdem die Authentifizierung auf Digital Signatur geändert wurde. Und mehr muss da ja auch nicht verändert werden ...

[Frühstücksdirektor]

Nicht unbedingt, schau mal im Trace auf welchen Eintrag das jetzt überhaupt matcht...

[w.blecker]

So sieht der Trace aus:
[VPN-Debug] 2024/08/14 13:50:04,115 Devicetime: 2024/08/14 13:50:04,081
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 1845 bytes
Gateways: (IP anonymisiert):4500<--192.168.57.48:10954
SPIs: 0x1D6C5AA37E4B2B1CED465F8E6B77330B, Message-ID 1
Payloads: IDI, CERT(X509), NOTIFY(INITIAL_CONTACT), NOTIFY(HTTP_CERT_LOOKUP_SUPPORTED), CERTREQ, AUTH(DIGITAL SIGNATURE), CP(REQUEST), SA, TSI, TSR, VENDOR(ikev2 rfc-3706-dead-peer-detection), NOTIFY(MOBIKE_SUPPORTED), NOTIFY(MULTIPLE_AUTH_SUPPORTED)
+IKE_SA found and assigned
+Exchange created (flags: 0x00000000)
(IKEv2-Exchange 'DEFAULT', 'ISAKMP-PEER-DEFAULT' 0x1D6C5AA37E4B2B1CED465F8E6B77330B00000001, P2, RESPONDER): Setting Negotiation SA
Referencing (CHILD_SA, 0x1D6C5AA37E4B2B1CED465F8E6B77330B0000000100, responder): use_count 3
Looking for payload IDI (35)...Found 1 payload.
Compare: -Received-ID CN=HO-BLECKER-1,O=Gemeinde Beheim,C=DE,L=Beheim,ST=Hessen,OU=10,emailAddress=ho-blecker-1@Beheim.de,postalCode=12345:DER_ASN1_DN != Expected-ID /CN=HO-BLECKER-01:DER_ASN1_DN
Compare: -Received-ID CN=HO-BLECKER-1,O=Gemeinde Beheim,C=DE,L=Beheim,ST=Hessen,OU=10,emailAddress=ho-blecker-1@Beheim.de,postalCode=12345:DER_ASN1_DN != Expected-ID /CN=HO-BLECKER-1:DER_ASN1_DN
Looking for payload VENDOR (43)...Found 1 payload.
Looking for payload CERT(X509) (37)...Found 1 payload.
Subject: CN=HO-BLECKER-1,O=Gemeinde Beheim,C=DE,L=Beheim,ST=Hessen,OU=10,emailAddress=ho-blecker-1@Beheim.de,postalCode=12345
Issuer : CN=GEMEINDE Beheim CA,O=IT,C=DE
Looking for payload NOTIFY(INITIAL_CONTACT) (41)...Found 1 payload.
Dynamic comchannel 83 created

[VPN-Debug] 2024/08/14 13:50:04,115 Devicetime: 2024/08/14 13:50:04,114
Peer HO-BLECKER-1D837: Constructing an IKE_AUTH-RESPONSE for send
Constructing payload NOTIFY(REDIRECT) (41):
+No Redirection
Constructing payload NOTIFY(MANAGEMENT_IP4_ADDRESS) (41):
Constructing payload NOTIFY(MANAGEMENT_IP6_ADDRESS) (41):
Fragment encrypted successfully
Message authenticated successfully
Don't Fragment bit is set
Non-ESP-Marker Prepended
Fragment encrypted successfully
Message authenticated successfully
Don't Fragment bit is set
Non-ESP-Marker Prepended
IKE_SA(0x1D6C5AA37E4B2B1CED465F8E6B77330B).EXPECTED-MSG-ID raised to 2
IPSEC overhead initialized to 42
(IKEv2-Exchange 'HO-BLECKER-1D837', 'ISAKMP-PEER-DEFAULT' 0x1D6C5AA37E4B2B1CED465F8E6B77330B00000001, P2, RESPONDER, comchannel 83): Resetting Negotiation SA
(CHILD_SA, 0x1D6C5AA37E4B2B1CED465F8E6B77330B0000000100, responder): use_count --3
+(request, response) pair inserted into retransmission map
Sending an IKE_AUTH-RESPONSE of 1317 bytes (responder)
Gateways: (IP anonymisiert):4500-->192.168.57.48:10954, tag 0 (UDP)
SPIs: 0x1D6C5AA37E4B2B1CED465F8E6B77330B, Message-ID 1
Sending 1 ikev2 fragment(s) of 1076 bytes and last fragment of size 356 bytes
Payloads: IDR, CERT(X509), AUTH(DIGITAL SIGNATURE), NOTIFY(INTERNAL_ADDRESS_FAILURE)

[VPN-Debug] 2024/08/14 13:50:04,117 Devicetime: 2024/08/14 13:50:04,114
Peer HO-BLECKER-1D837: Trigger next pended request to establish an exchange
Current request is none
IKE_SA is not REPLACED
There are 0 pending requests

[VPN-Debug] 2024/08/14 13:50:04,779 Devicetime: 2024/08/14 13:50:04,705
Peer HO-BLECKER-1D837 [responder]: Received an INFORMATIONAL-REQUEST of 80 bytes (encrypted)
Gateways: (IP anonymisiert):4500<--192.168.57.48:10954
SPIs: 0x1D6C5AA37E4B2B1CED465F8E6B77330B, Message-ID 2
Payloads: ENCR
QUB-DATA: (IP anonymisiert):4500<---192.168.57.48:10954 rtg_tag 0 physical-channel LAN vpn-channel 83
transport: [id: 1209530, UDP (17) {incoming unicast, fixed source address}, dst: 192.168.57.48, tag 0 (U), src: (IP anonymisiert), hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu: 1500, iface: INTRANET (2), mac address: 00:90:7f:d9:a0:6d, port 4], local port: 4500, remote port: 10954, flags: UDP_ENCAPSULATION
+IKE_SA found and assigned
+Exchange created (flags: 0x00000004)
Message verified successfully
Message decrypted successfully
Payloads: ENCR, DELETE

[VPN-Debug] 2024/08/14 13:50:04,781 Devicetime: 2024/08/14 13:50:04,705
Peer HO-BLECKER-1D837: Constructing an INFORMATIONAL-RESPONSE for send
Message encrypted successfully
Message authenticated successfully
Non-ESP-Marker Prepended
IKE_SA(0x1D6C5AA37E4B2B1CED465F8E6B77330B).EXPECTED-MSG-ID raised to 3
+(request, response) pair inserted into retransmission map
Sending an INFORMATIONAL-RESPONSE of 80 bytes (responder encrypted)
Gateways: (IP anonymisiert):4500-->192.168.57.48:10954, tag 0 (UDP)
SPIs: 0x1D6C5AA37E4B2B1CED465F8E6B77330B, Message-ID 2
Payloads: ENCR

[VPN-Debug] 2024/08/14 13:50:04,782 Devicetime: 2024/08/14 13:50:04,705
DISCONNECT-RESPONSE sent for handle 83
IKE-TRANSPORT freed

[Frühstücksdirektor]

Dann ist das das, was sich vermutet habe, der Peer matcht jetzt auf den Default-Peer und damit wird ein dynamischer Peer dem Default-Eintrag generiert. Der Gegenstellenname ist jetzt HO-BLECKER-1D837, für den gibt es vmtl. keinen Pool.
Entweder die Authentifizierung so anpassen, dass diese auf einen konfigurierten Eintrag matcht, oder für HO-BLECKER-1D837 einen Pool anlegen.

[w.blecker]

Das tritt aber nur offensichtlich nur bei Gegenstellen die mit Zertfikaten arbeiten, ansonsten habe ich das noch nie gesehen das er da plötzlich eine Gegenstelle erfindet. (Bei den ganzen PSK basierten passiert das nämlich nicht)

Ist die Frage wo stellt man das denn ein das er die richtige Gegenstelle benutzt und nicht irgendeine selbst generierte ?

Ergänzung:

Ich habe einen Peer mit dem Namen angelegt, rest wie beim Originaleintrag .. Hat aber nichts bewirkt

[Frühstücksdirektor]

Das wird am Ende darüber gesteuert, was Du in der Spalte bei entfernte Identität konfigurierst. Der Typ ist ja ASN.1, bei Dir passt die ankommende Identität nicht zu der Konfiguration.

Er erwartet scheinbar dass die Identität /CN=HO-BLECKER-01 kommt, es kommt aber

Compare: -Received-ID CN=HO-BLECKER-1,O=Gemeinde Beheim,C=DE,L=Beheim,ST=Hessen,OU=10,emailAddress=ho-blecker-1@Beheim.de,postalCode=12345:DER_ASN1_DN != Expected-ID /CN=HO-BLECKER-01:DER_ASN1_DN

Compare: -Received-ID CN=HO-BLECKER-1,O=Gemeinde Beheim,C=DE,L=Beheim,ST=Hessen,OU=10,emailAddress=ho-blecker-1@Beheim.de,postalCode=12345:DER_ASN1_DN != Expected-ID /CN=HO-BLECKER-1:DER_ASN1_DN

[w.blecker]

Ist die Frage wo er das hernimmt ... Eingetragen ist überall der HO-Blecker-1. Wenn ich auf dem Client schaue unter Zertifkate ist das dort auch so eingetragen .. Ich kann den HO-Blecker-01 nirgends finden ....

[GrandDixence]

Ist die Frage wo er das hernimmt ...

Bei Verwendung von X.509-Zertifikaten zur Authentifizierung von VPN-Endpunkten wird das unter:

/Setup/VPN/IKEv2/Auth/Parameter/Local-ID
/Setup/VPN/IKEv2/Auth/Parameter/Remote-ID

konfigurierte Feld vom X.509-Zertifikat verwendet. Der VPN-Endpunkt prüft bei der Authentifizierung das vom anderen VPN-Endpunkt vorgewiesene Zertifikat (Passkontrolle), ob dieses Zertifikat die geforderten Angaben in den vorkonfigurierten Feldern enthält. Üblich ist die Nutzung vom "Common Name" (CN), welcher im Webbrowser Firefox als "Allgemeiner Name" ausgewiesen wird:

CN=natel.invalid => Das vorgewiesene X.509-Zertifikat muss im Feld "Common Name" (CN) die Angabe "natel.invalid" enthalten.

Im Webbrowser Firefox in der Addressleiste auf das Schloss klicken > Verbindung sicher > Weitere Informationen.

Erschwert wird das Ganze durch die SAN-Thematik bei Google-folgsamen VPN-Clients. Das SAN-Feld ist im Webbrowser Firefox als "Alternative Inhaberbezeichnungen" ersichtlich. Je nach Anwendungsfall vewendet man in der Regel im SAN-Feld den DNS-Name oder die IP-Adresse:
https://en.wikipedia.org/wiki/Subject_Alternative_Name

https://www.heise.de/hintergrund/Chrome ... 17594.html

Hauptsache die Angaben im CN- und SAN-Feld sind eindeutig. Die restlichen Angaben wie Organisation (O), Land (C) und E-Mail (emailAddress) kann man sich ersparen. Das macht doch nur Ärger und birgt Datenschutzprobleme.

Noch bequemer als der Webbrowser Firefox ist der Windows Explorer zum Betrachten von X.509-Zertifikaten. Einfach auf das X.509-Zertifikat mit der Maus doppelklicken.

[w.blecker]

So ... jetzt erkennt er den Peer richtig, es wird auch eine IP aus dem pool zugeteilt.
Dafür laufe ich jetzt auf den nächsten Fehler :

AUTH Payload
| Next Payload : NOTIFY
| CRITICAL : NO
| Reserved : 0x00
| Length : 280 Bytes
| Auth. Method : DIGITAL_SIGNATURE
| Reserved : 0x000000
| ASN.1 Length : 0x0F
| ASN.1 Object : sha1WithRSAEncryption
| Signature Data : 9F 37 04 25 D1 D0 8A E5 9E E3 C9 A7 80 F3 D5 64
| 51 F8 80 AE 97 32 03 3C 8E 75 10 C2 9F D9 E3 67
| 30 F5 D3 E4 B5 93 1F EE EA ED DC A9 BD 7C 33 2D
| F2 7B C6 70 2D 4B 5D F6 FF D9 5C F9 EA 68 FA C9
| C6 9F 9B B1 94 8D DB 5C 72 47 BB D0 62 C1 8B D2
| E4 9D 0D D8 65 D6 F4 3B B8 D6 70 BF B9 EB 76 70
| 14 30 82 17 97 C5 62 58 1F 4F 18 B3 E1 1F D3 37
| 8C C3 1C B3 1A 90 03 0A 46 92 AD 62 56 6D F9 2D
| 4F 1D 70 05 52 C2 34 6E EB D3 0B D6 68 FC 08 6C
| 83 1A 11 69 E4 BB 26 DB 75 A0 FD 77 5E DC B2 63
| 82 01 73 21 0E 83 67 F9 F2 E5 71 81 59 FF 48 50
| FE D9 DC 69 9E F5 6E 41 A3 3F 20 4F 79 24 50 AB
| B1 54 9D 1A BF F0 9E 93 A4 CD 92 93 EC BA 59 EE
| D1 4C 2A CC 27 86 7C 89 0B 27 62 05 35 3D D0 A6
| 4F E3 76 09 15 5D CC F0 98 FE 36 45 65 57 8B 7F
| 90 50 CC 87 38 2A 4F CC F5 46 EA 2B A2 D7 2A 5F
NOTIFY Payload
| Next Payload : NONE
| CRITICAL : NO
| Reserved : 0x00
| Length : 8 Bytes
| Protocol ID : <Unknown 0>
| SPI size : 0
| Message type : TS_UNACCEPTABLE

Es bleibt spannend ...

[tobiasr]

TS_UNACCEPTABLE deutet auf ein Routing/IP-Adressen Problem hin. Lokale IP, Remote IP, Routen, etc. alles richtig?