Továbbítás: [Ipsec-tools-users] freebsd & linux setup question

[krichy@cflinux.hu]

Küldve az én HTC-mről

----- Forwarded message -----
kezdés: "Richard Kojedzinszky" <krichy at cflinux.hu>
Befejezés: <ipsec-tools-users at lists.sourceforge.net>
Tárgy: [Ipsec-tools-users] freebsd & linux setup question
Dátum: H, jan. 21, 2013 17:08


Dear users,

I've a working tunnel setup between two linux hosts.

One end (A) has a fix address, while the other (B) has a dynamic one. 
A is my server, B is my home router. Behind B, I've a private network. 
What I've setup is that my private network reaches A through an IPSEC 
tunnel.

The diagram:

A - { INTERNET } - B - { local network }

So, in my home router, when it acquires an IP address, such script runs 
(A is the server's address, B is the dynamic address):

# echo "spdadd 10.0.0.0/24 A any -P out ipsec esp/tunnel/B-A/require;" | 
setkey -c
# echo "spdadd A 10.0.0.0/24 any -P in ipsec esp/tunnel/A-B/require;" | 
setkey -c

My racoon config has only an anonymous remote section. The server has one 
also, but it has generate_policy set to on. Therefore, when a packet 
initiates the tunnel, the server sets up correct tunnels/policies, and 
everything works fine.

Now, I've decided to switc to freebsd on server side, and the same 
configuration on the server simply does not work. It installs the 
policies, and the tunnels, but it seems, that when a reply packet is 
leaving the server, it tries to initiate a new tunnel. If I've "passive 
on" on my server's remote section, then I've the following error:

Jan 21 16:06:11 pi racoon: ERROR: no configuration found for B.
Jan 21 16:06:11 pi racoon: ERROR: failed to begin ipsec sa negotication.

If I disable passive mode, then racoon tries to establish another tunnel, 
but for some reason it does not succeed also. But I think, as in linux 
it should work with passive on.

FreeBSD is 9.1-RELEASE, the linux side is a linux 3.5.4.

racoon on linux is:
# racoon -V
@(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net)

Compiled with:
- OpenSSL 1.0.0e 6 Sep 2011 (http://www.openssl.org/)
- Dead Peer Detection
- IKE fragmentation
- NAT Traversal
- Monotonic clock


racoon on freebsd is:
# racoon -V
@(#)ipsec-tools 0.8.0 (http://ipsec-tools.sourceforge.net)

Compiled with:
- OpenSSL 0.9.8x 10 May 2012 (http://www.openssl.org/)
- Dead Peer Detection
- IKE fragmentation
- Hybrid authentication
- Monotonic clock


Unfortunately I've no idea.

Before the first packet, on the server:
# setkey -D
No SAD entries.

After an icmp packet sent from my private network to A:
# setkey -D
A B
 	esp mode=tunnel spi=76859998(0x0494ca5e) reqid=0(0x00000000)
 	E: rijndael-cbc  1c80b80d b006e3a3 772c2a9b 5c475213
 	A: hmac-md5  d43ff29c 034c896a fb2e7d1c 95f73ff5
 	seq=0x00000000 replay=4 flags=0x00000000 state=mature
 	created: Jan 21 17:03:39 2013	current: Jan 21 17:05:54 2013
 	diff: 135(s)	hard: 14400(s)	soft: 11520(s)
 	last:                     	hard: 0(s)	soft: 0(s)
 	current: 0(bytes)	hard: 0(bytes)	soft: 0(bytes)
 	allocated: 0	hard: 0	soft: 0
 	sadb_seq=1 pid=93091 refcnt=1
B A
 	esp mode=tunnel spi=144790000(0x08a151f0) reqid=0(0x00000000)
 	E: rijndael-cbc  8bd59c29 9800d10f 8f9d7e84 a720aa9c
 	A: hmac-md5  188070e2 a3220772 78efcb06 3457db62
 	seq=0x00000037 replay=4 flags=0x00000000 state=mature
 	created: Jan 21 17:03:39 2013	current: Jan 21 17:05:54 2013
 	diff: 135(s)	hard: 14400(s)	soft: 11520(s)
 	last: Jan 21 17:04:50 2013	hard: 0(s)	soft: 0(s)
 	current: 5720(bytes)	hard: 0(bytes)	soft: 0(bytes)
 	allocated: 55	hard: 0	soft: 0
 	sadb_seq=0 pid=93091 refcnt=1
# setkey -DP
10.0.0.0/24[any] A[any] any
 	in ipsec
 	esp/tunnel/B-A/require
 	created: Jan 21 17:03:39 2013  lastused: Jan 21 17:03:39 2013
 	lifetime: 14400(s) validtime: 0(s)
 	spid=25 seq=1 pid=5232
 	refcnt=1
A[any] 10.0.0.0/24[any] any
 	out ipsec
 	esp/tunnel/A-B/require
 	created: Jan 21 17:03:39 2013  lastused: Jan 21 17:04:50 2013
 	lifetime: 14400(s) validtime: 0(s)
 	spid=26 seq=0 pid=5232
 	refcnt=1

Everything seems fine, as well it is in linux, howewer, the attached log 
shows that the kernel or racoon does not try to use the new tunnel, 
instead it wants another one.

Is it a bug in freebsd, or a feature in linux? Do somebody have experience 
with such a setup?

Thanks in advance,
Kojedzinszky Richard