vpn trouble

[ralf at dzie-ciuch.pl]

Hi,

I set everything like you wrote and I can send and receice packets but
still I can't ping to host 10.10.1.90,
and when I type #setkey -D there is no SAD entry

What could it be?

This is part of racoon log:


Jun 23 09:43:57 czesio racoon: DEBUG: ===
Jun 23 09:43:57 czesio racoon: DEBUG: compute DH's private.
Jun 23 09:43:57 czesio racoon: DEBUG:  5b119f45 9108a35d 61341d54 ce28f645
fac5ef8d 417013a1 455ba09f 945ab1ef 81243118 8efcdc9c f6721a38 e230ab74
8302deeb c92c06c3 6324cdf0 2bc52859 032a0bcf 516c94e3 7c99eb28 1f0cde23
9afc4515 07795202 666d124d 76d74e47 8ab70799 b48d5f67 9d228ef9 1a266f0b
194b327a 15fffe6c b87cdbd0 650ee521
Jun 23 09:43:57 czesio racoon: DEBUG: compute DH's public.
Jun 23 09:43:57 czesio racoon: DEBUG:  3492c8a7 2662325a d8039260 2fc9c105
0299b9dc 3c5db323 0097677b 5d8b9f12 a9151df0 b4a9b7f5 a9121ca5 976e7a3c
d7ba8024 9542fd10 2d8094e1 101c1df7 6f951335 eb12545a 51dcbea3 1bf34baa
0f673aca f8ab4dfa d93d15dc 0cd37c81 c4828967 223c4923 26b0455a 7991f75c
821d818a 1370a9dd b100a947 3f782a00
Jun 23 09:43:57 czesio racoon: DEBUG: add payload of len 128, next type 10
Jun 23 09:43:57 czesio racoon: DEBUG: add payload of len 16, next type 0
Jun 23 09:43:57 czesio racoon: DEBUG: 180 bytes from 78.x.x.x[500] to
95.x.x.x[500]
Jun 23 09:43:57 czesio racoon: DEBUG: sockname 78.x.x.x[500]
Jun 23 09:43:57 czesio racoon: DEBUG: send packet from 78.x.x.x[500]
Jun 23 09:43:57 czesio racoon: DEBUG: send packet to 95.x.x.x[500]
Jun 23 09:43:57 czesio racoon: DEBUG: 1 times of 180 bytes message will be
sent to 95.x.x.x[500]
Jun 23 09:43:57 czesio racoon: DEBUG:  01505a49 433e1cff 8cb6b14b 5ec59b4e
04100200 00000000 000000b4 0a000084 3492c8a7 2662325a d8039260 2fc9c105
0299b9dc 3c5db323 0097677b 5d8b9f12 a9151df0 b4a9b7f5 a9121ca5 976e7a3c
d7ba8024 9542fd10 2d8094e1 101c1df7 6f951335 eb12545a 51dcbea3 1bf34baa
0f673aca f8ab4dfa d93d15dc 0cd37c81 c4828967 223c4923 26b0455a 7991f75c
821d818a 1370a9dd b100a947 3f782a00 00000014 c75cf3fa 12f5c5dc 0b66e5a2
4e37bdf6
Jun 23 09:43:57 czesio racoon: DEBUG: resend phase1 packet
01505a49433e1cff:8cb6b14b5ec59b4e
Jun 23 09:43:57 czesio racoon: DEBUG: ===
Jun 23 09:43:57 czesio racoon: DEBUG: 180 bytes message received from
95.x.x.x[500] to 78.x.x.x[500]
Jun 23 09:43:57 czesio racoon: DEBUG:  01505a49 433e1cff 8cb6b14b 5ec59b4e
04100200 00000000 000000b4 0a000084 38b0ea0f 68a0d78e b41143b5 0b52d522
8b6a5a44 892d78fa a5ff87e5 1fdd2df8 51246c25 1743a162 0785ff3d 9e0ac5b0
39568149 8e327c35 d20459cc 44512c02 cf620450 b04a708a ae85f00d 11d58f58
c19f9b65 f8ec1cf9 160406e3 a072036c 6b2c82f2 4cc8fed5 312d4abe 75c05d7d
f8f12fc9 d0cbca01 aaa62b6e 0c491a30 00000014 0fdab028 1038d6ff 32782dd2
97d9208e
Jun 23 09:43:57 czesio racoon: DEBUG: begin.
Jun 23 09:43:57 czesio racoon: DEBUG: seen nptype=4(ke)
Jun 23 09:43:57 czesio racoon: DEBUG: seen nptype=10(nonce)
Jun 23 09:43:57 czesio racoon: DEBUG: succeed.
Jun 23 09:43:57 czesio racoon: DEBUG: ===



On Tue, 22 Jun 2010 20:41:07 +0200, Maciej Suszko <maciej at suszko.eu>
wrote:
> "David DeSimone" <fox at verio.net> wrote:
>> Maciej Suszko <maciej at suszko.eu> wrote:
>> >
>> > > So as you write they should set: ??
>> > > 10.20.0.1 (my ip on gif device) <-> 78.x <-> 95.x <-> 10.10.1.90
>> > > (other side)
>> > 
>> > Yes, indeed.
>> > 
>> > > And additionaly I thing I should correct set spd policy to:
>> > > 
>> > > spdadd 10.20.0.1 10.10.1.90 any -P out ipsec
>> > > esp/tunnel/78.x.x.x-95.x.x.x/require;
>> > > spdadd 10.10.1.90 10.20.0.1 any -P in ipsec
>> > > esp/tunnel/95.x.x.x-78.x.x.x/require;
>> > > 
>> > > Am I wrong?
>> > 
>> > No, you're right :)
>> > 
>> > You can set up the tunnel first - check whether both 10. are
>> > accessible from both sides, then you "cover" communication between
>> > them with IPSEC.
>> 
>> Will this sort of GIF tunnel interoperate with Cisco and/or Checkpoint
>> VPN equipment?  In our tests we were able to use pure IPSEC tunnel
>> encapsulation to interoperate with these sorts of devices, so we never
>> found a need for GIF encapsulation.
> 
> I'm not sure what's on the other side, AFAIK some hardware solution.