Probleme mit freeswan/x.509 und Safenet's SoftremoteLT bei Phase 2

[meinereinerseiner]

Hallo,

ich habe probleme eine vpn verbindung aufzubauen, anscheinend scheitert das ganze an phase 2 - hier mal meine konfig und ein bissl logfile:

/etc/ipsec.conf


config setup
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=no

conn %default
keyingtries=0
authby=rsasig
leftrsasigkey=%cert
rightrsasigkey=%cert

left=%defaultroute
leftsubnet=192.168.100.0/24
leftid="C=DE, ST=Berlin, L=Berlin, O=CA, OU=private, CN=bonsaiGW, Email=root@plepps.linux-site.net"

conn Roadwarrior
right=%any
type=tunnel
keyexchange=ike
pfs=yes
auto=add



Die Security policy Settings am Client:


Authentification Phase 1:
Authentification Method: RSA Signatures
Encrypt Alg: DES3
Hash Alg: MD5
SA Life: unspecified
Keygroup: Diffie-Hellmann Group 1

Key Exchange Phase 2:
SA Life: unspecified
Compression: none
Encapsulation ESP
Encrypt Alg: DES3
Hash Alg: MD5
Encapsulation: Tunnel
Authentification Protocol AH (is not active)



/var/log/secure


Apr 4 19:08:24 bonsai pluto[15832]: Starting Pluto (FreeS/WAN Version super-freeswan-1.99.6)
Apr 4 19:08:24 bonsai pluto[15832]: including X.509 patch with traffic selectors (Version 0.9.25)
Apr 4 19:08:24 bonsai pluto[15832]: including NAT-Traversal patch (Version 0.5a) [disabled]
Apr 4 19:08:24 bonsai pluto[15832]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
Apr 4 19:08:24 bonsai pluto[15832]: ike_alg_register_enc(): Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Apr 4 19:08:24 bonsai pluto[15832]: ike_alg_register_enc(): Activating OAKLEY_CAST_CBC: Ok (ret=0)
Apr 4 19:08:24 bonsai pluto[15832]: ike_alg_register_enc(): Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Apr 4 19:08:24 bonsai pluto[15832]: ike_alg_register_hash(): Activating OAKLEY_SHA2_256: Ok (ret=0)
Apr 4 19:08:24 bonsai pluto[15832]: ike_alg_register_hash(): Activating OAKLEY_SHA2_512: Ok (ret=0)
Apr 4 19:08:24 bonsai pluto[15832]: ike_alg_register_enc(): Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Apr 4 19:08:24 bonsai pluto[15832]: ike_alg_register_enc(): Activating OAKLEY_SSH_PRIVATE_65289: Ok (ret=0)
Apr 4 19:08:24 bonsai pluto[15832]: Changing to directory '/etc/ipsec.d/cacerts'
Apr 4 19:08:24 bonsai pluto[15832]: loaded cacert file 'caCert.pem' (1619 bytes)
Apr 4 19:08:24 bonsai pluto[15832]: Changing to directory '/etc/ipsec.d/crls'
Apr 4 19:08:24 bonsai pluto[15832]: loaded crl file 'crl.pem' (686 bytes)
Apr 4 19:08:24 bonsai pluto[15832]: loaded my default X.509 cert file '/etc/x509cert.der' (1050 bytes)
Apr 4 19:08:24 bonsai pluto[15832]: | from whack: got --esp=3des
Apr 4 19:08:24 bonsai pluto[15832]: | from whack: got --ike=3des
Apr 4 19:08:24 bonsai pluto[15832]: added connection description "Roadwarrior"
Apr 4 19:08:24 bonsai pluto[15832]: listening for IKE messages
Apr 4 19:08:24 bonsai pluto[15832]: adding interface ipsec0/ppp0 213.23.128.162
Apr 4 19:08:24 bonsai pluto[15832]: IP interfaces tun0 and eth0 share address 192.168.100.1!
Apr 4 19:08:24 bonsai pluto[15832]: loading secrets from "/etc/ipsec.secrets"
Apr 4 19:08:25 bonsai pluto[15832]: loaded private key file '/etc/ipsec.d/private/gwKey.pem' (963 bytes)
.
.
.
.
.
Apr 4 19:10:30 bonsai pluto[15832]: packet from 62.80.62.77:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Apr 4 19:10:30 bonsai pluto[15832]: "Roadwarrior"[3] 62.80.62.77 #9: responding to Main Mode from unknown peer 62.80.62.77
Apr 4 19:10:31 bonsai pluto[15832]: "Roadwarrior"[3] 62.80.62.77 #9: ignoring Vendor ID payload [47bbe7c993f1fc13...]
Apr 4 19:10:31 bonsai pluto[15832]: "Roadwarrior"[3] 62.80.62.77 #9: ignoring Vendor ID payload [da8e937880010000]
Apr 4 19:10:31 bonsai pluto[15832]: "Roadwarrior"[3] 62.80.62.77 #9: ignoring Vendor ID payload [XAUTH]
Apr 4 19:10:31 bonsai pluto[15832]: "Roadwarrior"[3] 62.80.62.77 #9: ignoring informational payload, type IPSEC_INITIAL_CONTACT
Apr 4 19:10:31 bonsai pluto[15832]: "Roadwarrior"[3] 62.80.62.77 #9: Main mode peer ID is ID_DER_ASN1_DN: 'C=DE, ST=Berlin, O=CA, OU=private, CN=schleppi, E=schleppi@plepps.linux-site.net'
Apr 4 19:10:31 bonsai pluto[15832]: "Roadwarrior"[4] 62.80.62.77 #9: deleting connection "Roadwarrior" instance with peer 62.80.62.77
Apr 4 19:10:31 bonsai pluto[15832]: "Roadwarrior"[4] 62.80.62.77 #9: sent MR3, ISAKMP SA established
Apr 4 19:10:32 bonsai pluto[15832]: "Roadwarrior"[4] 62.80.62.77 #10: we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION
Apr 4 19:10:32 bonsai pluto[15832]: "Roadwarrior"[4] 62.80.62.77 #10: sending encrypted notification NO_PROPOSAL_CHOSEN to 62.80.62.77:500
Apr 4 19:10:33 bonsai pluto[15832]: "Roadwarrior"[4] 62.80.62.77 #11: we require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION
Apr 4 19:10:33 bonsai pluto[15832]: "Roadwarrior"[4] 62.80.62.77 #11: sending encrypted notification NO_PROPOSAL_CHOSEN to 62.80.62.77:500



das log vom client


19:09:44.598
19:09:44.708 My Connections\New Connection - Initiating IKE Phase 1 (IP ADDR=213.23.128.162)
19:09:44.708 My Connections\New Connection - SENDING>>>> ISAKMP OAK MM (SA, VID)
19:09:44.908 My Connections\New Connection - RECEIVED<<< ISAKMP OAK MM (SA)
19:09:44.928 My Connections\New Connection - SENDING>>>> ISAKMP OAK MM (KE, NON, VID, VID, VID)
19:09:45.118 My Connections\New Connection - RECEIVED<<< ISAKMP OAK MM (KE, NON, CERT_REQ)
19:09:45.159 My Connections\New Connection - Using configured machine certificate "schleppi's CA private ID".
19:09:45.219 My Connections\New Connection - SENDING>>>> ISAKMP OAK MM *(ID, CERT, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, SIG, NOTIFY:STATUS_INITIAL_CONTACT)
19:09:46.210 My Connections\New Connection - RECEIVED<<< ISAKMP OAK MM *(ID, CERT, SIG)
19:09:46.260 My Connections\New Connection - Established IKE SA
19:09:46.260 MY COOKIE 5f 46 b4 8f 7f 8b ed 69
19:09:46.260 HIS COOKIE 0 88 95 51 60 1d 59 28
19:09:46.260 My Connections\New Connection - Initiating IKE Phase 2 with Client IDs (message id: D0D81194)
19:09:46.260 Initiator = IP ADDR=62.80.62.77, prot = 0 port = 0
19:09:46.260 Responder = IP SUBNET/MASK=192.168.100.0/255.255.255.0, prot = 0 port = 0
19:09:46.260 My Connections\New Connection - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID)
19:09:46.360 My Connections\New Connection - RECEIVED<<< ISAKMP OAK INFO *(HASH, NOTIFY:NO_PROPOSAL_CHOSEN)
19:09:46.360 My Connections\New Connection - Discarding IPSec SA negotiation
19:09:46.981
19:09:47.612 My Connections\New Connection - Initiating IKE Phase 2 with Client IDs (message id: 3D5656AF)
19:09:47.612 Initiator = IP ADDR=62.80.62.77, prot = 0 port = 0
19:09:47.612 Responder = IP SUBNET/MASK=192.168.100.0/255.255.255.0, prot = 0 port = 0
19:09:47.612 My Connections\New Connection - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, ID, ID)
19:09:47.882 My Connections\New Connection - RECEIVED<<< ISAKMP OAK INFO *(HASH, NOTIFY:NO_PROPOSAL_CHOSEN)
19:09:47.882 My Connections\New Connection - Discarding IPSec SA negotiation



ich hoffe mal, jemand sieht da durch und findet meinen fehler,

danke
der tom

[linuxhanz]

Habe den Artikel im LinuxMag noch nicht fertig aber
schau mal nach SA.



"Discarding IPSec SA negotiation"



EDIT: Das
NOTIFY:NO_PROPOSAL_CHOSEN
fiel mir auch noch grad auf. Hast Du die ipsec.secrets gesetzt?

[meinereinerseiner]

hi,

also hab mal nochmal google gefragt der sagt mir einmal:

Best guess, you have not read vpn(8) or similar and thus missing to
change two sysctl values (net.inet.(ah/esp).enable)
(ist im zusammenhang mit BSD)

und dann noch das:
5) If you see log messages like "Initiating IKE Phase 1" followed by "No Proposal Chosen" and "Discarding IKE SA negotiation", your VPN client/box and corporate gateway have an IKE policy mismatch. Double-check your client/box security parameters (encryption and authentication algorithms) to make sure they match the settings required by your company.


sagt mir erstmal beides nicht.

ipsec.secrets ist eigentlich ok, weil im secure log kommt:
Apr 4 19:08:24 bonsai pluto[15832]: loading secrets from "/etc/ipsec.secrets"
Apr 4 19:08:25 bonsai pluto[15832]: loaded private key file '/etc/ipsec.d/private/gwKey.pem' (963 bytes)


ich weis absolut nicht mehr weiter.


der tom

[meinereinerseiner]

ich schon wieder - bin einen schritt weiter!
Hatte auf dem Client PFS Forwarding nicht aktiviert!

anscheinend steht die verbindung jetzt - aber kein ping geht durch - warum auch immer??????


secure log:



Apr 4 20:00:32 bonsai ipsec__plutorun: Starting Pluto subsystem...
Apr 4 20:00:32 bonsai pluto[23636]: Starting Pluto (FreeS/WAN Version super-freeswan-1.99.6)
Apr 4 20:00:32 bonsai pluto[23636]: including X.509 patch with traffic selectors (Version 0.9.25)
Apr 4 20:00:32 bonsai pluto[23636]: including NAT-Traversal patch (Version 0.5a) [disabled]
Apr 4 20:00:32 bonsai pluto[23636]: ike_alg_register_enc(): Activating OAKLEY_AES_CBC: Ok (ret=0)
Apr 4 20:00:32 bonsai pluto[23636]: ike_alg_register_enc(): Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0)
Apr 4 20:00:32 bonsai pluto[23636]: ike_alg_register_enc(): Activating OAKLEY_CAST_CBC: Ok (ret=0)
Apr 4 20:00:32 bonsai pluto[23636]: ike_alg_register_enc(): Activating OAKLEY_SERPENT_CBC: Ok (ret=0)
Apr 4 20:00:32 bonsai pluto[23636]: ike_alg_register_hash(): Activating OAKLEY_SHA2_256: Ok (ret=0)
Apr 4 20:00:32 bonsai pluto[23636]: ike_alg_register_hash(): Activating OAKLEY_SHA2_512: Ok (ret=0)
Apr 4 20:00:32 bonsai pluto[23636]: ike_alg_register_enc(): Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
Apr 4 20:00:32 bonsai pluto[23636]: ike_alg_register_enc(): Activating OAKLEY_SSH_PRIVATE_65289: Ok (ret=0)
Apr 4 20:00:32 bonsai pluto[23636]: Changing to directory '/etc/ipsec.d/cacerts'
Apr 4 20:00:32 bonsai pluto[23636]: loaded cacert file 'caCert.pem' (1619 bytes)
Apr 4 20:00:32 bonsai pluto[23636]: Changing to directory '/etc/ipsec.d/crls'
Apr 4 20:00:32 bonsai pluto[23636]: loaded crl file 'crl.pem' (686 bytes)
Apr 4 20:00:32 bonsai pluto[23636]: loaded my default X.509 cert file '/etc/x509cert.der' (1050 bytes)
Apr 4 20:00:33 bonsai pluto[23636]: | from whack: got --esp=3des
Apr 4 20:00:33 bonsai pluto[23636]: | from whack: got --ike=3des
Apr 4 20:00:33 bonsai pluto[23636]: added connection description "Roadwarrior"
Apr 4 20:00:33 bonsai pluto[23636]: listening for IKE messages
Apr 4 20:00:33 bonsai pluto[23636]: adding interface ipsec0/ppp0 213.23.128.162
Apr 4 20:00:33 bonsai pluto[23636]: IP interfaces tun0 and eth0 share address 192.168.100.1!
Apr 4 20:00:33 bonsai pluto[23636]: loading secrets from "/etc/ipsec.secrets"
Apr 4 20:00:33 bonsai pluto[23636]: loaded private key file '/etc/ipsec.d/private/gwKey.pem' (963 bytes)
Apr 4 20:00:47 bonsai pluto[23636]: packet from 213.221.73.158:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Apr 4 20:00:47 bonsai pluto[23636]: "Roadwarrior"[1] 213.221.73.158 #1: responding to Main Mode from unknown peer 213.221.73.158
Apr 4 20:00:48 bonsai pluto[23636]: "Roadwarrior"[1] 213.221.73.158 #1: ignoring Vendor ID payload [47bbe7c993f1fc13...]
Apr 4 20:00:48 bonsai pluto[23636]: "Roadwarrior"[1] 213.221.73.158 #1: ignoring Vendor ID payload [da8e937880010000]
Apr 4 20:00:48 bonsai pluto[23636]: "Roadwarrior"[1] 213.221.73.158 #1: ignoring Vendor ID payload [XAUTH]
Apr 4 20:00:48 bonsai pluto[23636]: "Roadwarrior"[1] 213.221.73.158 #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=DE, ST=Berlin, O=CA, OU=private, CN=schleppi, E=schleppi@devil.linux-site.net'
Apr 4 20:00:48 bonsai pluto[23636]: "Roadwarrior"[2] 213.221.73.158 #1: deleting connection "Roadwarrior" instance with peer 213.221.73.158
Apr 4 20:00:48 bonsai pluto[23636]: "Roadwarrior"[2] 213.221.73.158 #1: sent MR3, ISAKMP SA established
Apr 4 20:00:49 bonsai pluto[23636]: "Roadwarrior"[2] 213.221.73.158 #2: responding to Quick Mode
Apr 4 20:00:49 bonsai pluto[23636]: "Roadwarrior"[2] 213.221.73.158 #2: IPsec SA established



das log vom client


20:00:01.546
20:00:01.656 My Connections\New Connection - Initiating IKE Phase 1 (IP ADDR=213.23.128.162)
20:00:01.656 My Connections\New Connection - SENDING>>>> ISAKMP OAK MM (SA, VID)
20:00:01.856 My Connections\New Connection - RECEIVED<<< ISAKMP OAK MM (SA)
20:00:01.886 My Connections\New Connection - SENDING>>>> ISAKMP OAK MM (KE, NON, VID, VID, VID)
20:00:02.037 My Connections\New Connection - RECEIVED<<< ISAKMP OAK MM (KE, NON, CERT_REQ)
20:00:02.077 My Connections\New Connection - Using configured machine certificate "schleppi's CA private ID".
20:00:02.137 My Connections\New Connection - SENDING>>>> ISAKMP OAK MM *(ID, CERT, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, CERT_REQ, SIG)
20:00:02.958 My Connections\New Connection - RECEIVED<<< ISAKMP OAK MM *(ID, CERT, SIG)
20:00:02.998 My Connections\New Connection - Established IKE SA
20:00:02.998 MY COOKIE 62 d5 ae f2 8a e9 93 aa
20:00:02.998 HIS COOKIE 89 76 44 a3 9f 64 9f 1f
20:00:03.028 My Connections\New Connection - Initiating IKE Phase 2 with Client IDs (message id: 525CC474)
20:00:03.028 Initiator = IP ADDR=213.221.73.158, prot = 0 port = 0
20:00:03.028 Responder = IP SUBNET/MASK=192.168.100.0/255.255.255.0, prot = 0 port = 0
20:00:03.028 My Connections\New Connection - SENDING>>>> ISAKMP OAK QM *(HASH, SA, NON, KE, ID, ID)
20:00:03.208 My Connections\New Connection - RECEIVED<<< ISAKMP OAK QM *(HASH, SA, NON, KE, ID, ID)
20:00:03.208 My Connections\New Connection - SENDING>>>> ISAKMP OAK QM *(HASH)
20:00:03.228 My Connections\New Connection - Loading IPSec SA (Message ID = 525CC474 OUTBOUND SPI = 86208590 INBOUND SPI = 7890E5C1)
20:00:03.228





any ideas?


der tom

[meinereinerseiner]

hab ich jetzt evtl noch ein routingproblem?

auf dem gateway:


Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
145.253.1.92 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
145.253.1.92 0.0.0.0 255.255.255.255 UH 0 0 0 ipsec0
213.221.73.158 145.253.1.92 255.255.255.255 UGH 0 0 0 ipsec0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.111.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 145.253.1.92 0.0.0.0 UG 0 0 0 ppp0


wobei 213.221.73.158 die ip des clients ist
ich kann aber weder vom GW zum client noch umgekehrt pingen.


de rtom

[linuxhanz]

und wenn du mal die ipsec Mailinglisten durchforstest?

[meinereinerseiner]

mit den mailinglisten quäle ich mich schon den ganzen tag lang :-((

pinge ich vom client auf das gw zeigt tcp dump:

[root@bonsai log]# tcpdump -i ipsec0
tcpdump: listening on ipsec0
20:22:34.352670 213.23.128.162 > 213.221.73.158: icmp: 213.23.128.162 protocol 50 port 37738 unreachable [tos 0xc0]
20:22:35.749582 213.23.128.162 > 213.221.73.158: icmp: 213.23.128.162 protocol 50 port 37738 unreachable [tos 0xc0]
20:22:36.746893 213.23.128.162 > 213.221.73.158: icmp: 213.23.128.162 protocol 50 port 37738 unreachable [tos 0xc0]
20:22:37.754345 213.23.128.162 > 213.221.73.158: icmp: 213.23.128.162 protocol 50 port 37738 unreachable [tos 0xc0]
20:22:38.741238 213.23.128.162 > 213.221.73.158: icmp: 213.23.128.162 protocol 50 port 37738 unreachable [tos 0xc0]


vom gw zum client bekomme ich das:

[root@bonsai log]# tcpdump -i ipsec0
tcpdump: listening on ipsec0
20:25:14.305042 213.23.128.162 > 213.221.73.158: icmp: echo request (DF)
20:25:15.324892 213.23.128.162 > 213.221.73.158: icmp: echo request (DF)
20:25:16.324336 213.23.128.162 > 213.221.73.158: icmp: echo request (DF)
20:25:17.342741 213.23.128.162 > 213.221.73.158: icmp: echo request (DF)
20:25:18.361560 213.23.128.162 > 213.221.73.158: icmp: echo request (DF)
20:25:19.361594 213.23.128.162 > 213.221.73.158: icmp: echo request (DF)

[linuxhanz]

Waren es nicht 2 Protokolle die da zusätzlich genutzt werden?

Was genau ist [tos 0xc0] ?


Sitz hier leider an ner Win Kiste. ;(

Increase dochmal tcpdump mit -vvv o.ä.

[linuxhanz]

He schalt doch mal den ppp0 ab.
Habe sowas in Erinnerung daß entweder ppp oder ipsec nur möglich ist.

Probieren kannst ja mal...

Auch häufig sehe ich das in /etc/ipsec.conf:

config setup > interfaces="ipsec0=ppp0"

[meinereinerseiner]

hmm,

ich schalte den ppp ab - und wie bitte komm ich dann von außen per vpn auf meine kiste, wenn der ppp wech is???

...das meinst du doch nicht im ernst, oder?


der tom

[linuxhanz]

...das meinst du doch nicht im ernst, oder?


D*amn das war dann wohl doch zu voreilig, bzw unüberlegt :(

Für Wochenende:

http://vpn.shmoo.com/vpn/ipsec_troubleshooting.pdf

[linuxhanz]

Und was ist daraus geworden?

[meinereinerseiner]

das geht immer noch nicht - stehe vor noch dem gleichen problem
und komme nicht weiter, das web schweigt dazu, im irc komm ich
auch nicht weiter - ich lass es einfach sein und fertig.
hab jetzt linux auf'm schleppi und mach das ganze via openvpn, das geht
wenigstens problemlos.

der trom

[Thanil.Bernetar]

Ganz genau meine Rede! Mir wächst so ein Hals, wenn nur jemand FreeS/WAN erwähnt!

Mit openvpn lief alles prima, prächtig, supergeil. Das war so easy. Bei FreeS/WAN steht überall wie einfach das ist, und ich kriege es einfach nicht hin. Bin ich zu blöd oder was?

Ich habe jedenfalls ein ähnliches Problem. Die Verbindung *scheint* zu stehen, aber der Ping geht nicht durch den Tunnel.

client-gateway:

Startmeldung:
eru:~ # ipsec auto --up Verbindungsname
104 "Verbindungsname" #4: STATE_MAIN_I1: initiate
106 "Verbindungsname" #4: STATE_MAIN_I2: sent MI2, expecting MR2
108 "Verbindungsname" #4: STATE_MAIN_I3: sent MI3, expecting MR3
004 "Verbindungsname" #4: STATE_MAIN_I4: ISAKMP SA established
112 "Verbindungsname" #5: STATE_QUICK_I1: initiate
004 "Verbindungsname" #5: STATE_QUICK_I2: sent QI2, IPsec SA established
eru:~ #

Dann starte ich einen Ping von einem Rechner im Client-Netzwerk auf einen Rechner im Server-Netzwerk. Ich horche auf eth0 des Client-gateway:

eru:~ # tcpdump -i eth0 not port ssh
tcpdump: listening on eth0
18:04:54.148891 192.168.10.66 > 192.168.0.1: icmp: echo request (DF)
18:04:55.148828 192.168.10.66 > 192.168.0.1: icmp: echo request (DF)
18:04:56.148701 192.168.10.66 > 192.168.0.1: icmp: echo request (DF)

==> der Ping vom Rechner 192.168.10.66 kommt also hier an über eth0

Ich horche also auf ppp0, ob der Ping rausgeht:

eru:~ # tcpdump -i ppp0 not port ssh
tcpdump: listening on ppp0

0 packets received by filter
0 packets dropped by kernel

==> das große Schweigen im Walde. Hier tut sich *GAR* nichts

eru:~ # tcpdump -i ipsec0 not port ssh
tcpdump: listening on ipsec0
18:01:40.779335 213.196.208.157 > 192.168.0.1: icmp: echo request (DF)
18:01:41.779440 213.196.208.157 > 192.168.0.1: icmp: echo request (DF)
18:01:42.779088 213.196.208.157 > 192.168.0.1: icmp: echo request (DF)

==> und das obwohl der Ping sogar auf ipsec0 registriert wird, d.h. er wird scheinbar hierher geroutet!!!

Meine Routing-Tabelle:
eru:~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
213.196.208.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
213.196.208.1 0.0.0.0 255.255.255.255 UH 0 0 0 ipsec0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 213.196.208.1 255.255.255.0 UG 0 0 0 ipsec0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 213.196.208.1 0.0.0.0 UG 0 0 0 ppp0

Der Fehler müsste also doch sein, dass die Pakete auf dem Client-Gateway *NICHT* wie vorgesehen durch den Tunnel und dann über ppp0 geroutet werden, oder?

Aber wie kriege ich das hin, dass der das richtig routet??

Mir fällt bald das letzte Haar aus...

:-(((