I'm not sure if this is the right list for such a questions..
But still.
Recently we tried to set up an IPSEC tunnel in a branch office
of a large company, using linux (currently 2.6.14). The endpoint
is running some Cisco PIX device. Everything's fine, using any
userspace tools available, except of one strangeness: the company
is routing several networks to their central hub (that Cisco PIX)
from each branch office, instead of "usual" one.
Ie, in all HOWTOs etc about this topic (IPSEC tunneling), there
are exactly two networks mentioned: "local" network and "remote"
network, usually with private 10/8 or 192.168/16 addresses, to
be routed using IPSEC tunnel. I haven't found any reference so
far where there are more than two networks involved this way.
More, in some configurations/software, it isn't even possible
to configure tunnel for more than two networks - eg, for
isakmpd package (available on linux too), there are exactly
*two* config settings -- something aking 'my-net' and 'their-net'.
As far as I understand (from Cisco documentation - I'm a total
newbie in cisco world), the SAs in their equipment are based on
ACLs (which is somewhat more broad term than "access control list",
to mean routes etc as well), and each ACL entry is based on two
network ranges - 'from' and 'to' networks.
So, the Cisco device tries to establish several tunnels to each
endpoint, for every network being routed. And this is clearly
seen by racoon traces - when I ping local network L from first
remote network A, racoon receives a request to establish tunnel
At, and when I ping it from second remote network B, racoon sees
request to establish tunnel Bt. So this is working fine, at least
according to the Cisco docs.
But what happens next is somewhat weird.
With two tunnels established, linux box tries to tunnel replies
using somewhat random tunnel from the two. *Usually* (but not
always), the first established tunnel (A/At) works OK, but replies
to pings coming from network B *sometimes* goes with SPI belonging
to Bt, and *sometimes* to At -- and in this last case, Cisco just
drops the "wrong" packets.
>From the SPD dump (setkey -DP), I see both entries (actually 4,
as each tunnel is bi-directional), but I see no way to determine
which tunnel "instance" to use in each case (IP addresses and
network ranges changed to letters for readability; LE = local
'external' ip-address, and RE = remote 'external' IP, ie, the
IP addresses of the IPSEC endpoints):
For A <=> L tunnel (At):
A[any] L[any] any
in ipsec
esp/tunnel/RE-LE/require
created: Dec 12 16:06:44 2005 lastused: Dec 13 17:47:21 2005
lifetime: 0(s) validtime: 0(s)
spid=544 seq=9 pid=6430
refcnt=2
L[any] A[any] any
out ipsec
esp/tunnel/LE-RE/require
created: Dec 12 16:06:44 2005 lastused: Dec 13 17:47:21 2005
lifetime: 0(s) validtime: 0(s)
spid=537 seq=6 pid=6430
refcnt=2
For B <=> L tunnel (Bt):
B[any] L[any] any
in ipsec
esp/tunnel/RE-LE/require
created: Dec 12 16:06:44 2005 lastused: Dec 13 17:47:23 2005
lifetime: 0(s) validtime: 0(s)
spid=568 seq=8 pid=6430
refcnt=2
L[any] B[any] any
out ipsec
esp/tunnel/LE-RE/require
created: Dec 12 16:06:44 2005 lastused: Dec 13 17:47:23 2005
lifetime: 0(s) validtime: 0(s)
spid=561 seq=5 pid=6430
refcnt=2
And here are the SAD entries:
LE RE
esp mode=tunnel spi=2591183185(0x9a725151) reqid=0(0x00000000)
E: des-cbc bc64154f 70de4e2d
A: hmac-md5 c7db01fd 85e076f3 cbe9997e 56345808
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 13 17:47:10 2005 current: Dec 13 17:52:58 2005
diff: 348(s) hard: 28800(s) soft: 23040(s)
last: Dec 13 17:47:11 2005 hard: 0(s) soft: 0(s)
current: 2312(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 17 hard: 0 soft: 0
sadb_seq=3 pid=6437 refcnt=0
LE RE
esp mode=tunnel spi=2352252189(0x8c34851d) reqid=0(0x00000000)
E: des-cbc 5dd71a3d 50632fe7
A: hmac-md5 7cf08c5d 26b45e6e 9a6d6cf2 2c1fe68c
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 13 17:47:05 2005 current: Dec 13 17:52:58 2005
diff: 353(s) hard: 28800(s) soft: 23040(s)
last: Dec 13 17:47:06 2005 hard: 0(s) soft: 0(s)
current: 1632(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 12 hard: 0 soft: 0
sadb_seq=2 pid=6437 refcnt=0
RE LE
esp mode=tunnel spi=209233273(0x0c78a579) reqid=0(0x00000000)
E: des-cbc bd1c8e9c 038d38d4
A: hmac-md5 8738c7c5 5035559b 718ae30b 9e1f7192
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 13 17:47:10 2005 current: Dec 13 17:52:58 2005
diff: 348(s) hard: 28800(s) soft: 23040(s)
last: Dec 13 17:47:11 2005 hard: 0(s) soft: 0(s)
current: 924(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 11 hard: 0 soft: 0
sadb_seq=1 pid=6437 refcnt=0
RE LE
esp mode=tunnel spi=23137318(0x01610c26) reqid=0(0x00000000)
E: des-cbc 4babd8e7 134b5140
A: hmac-md5 3bf09974 de3de6b9 02d4f4aa c80f4798
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Dec 13 17:47:05 2005 current: Dec 13 17:52:58 2005
diff: 353(s) hard: 28800(s) soft: 23040(s)
last: Dec 13 17:47:06 2005 hard: 0(s) soft: 0(s)
current: 1512(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 18 hard: 0 soft: 0
sadb_seq=0 pid=6437 refcnt=0
>From this output, I see no way to determine which SAD entry (from the
two available in each direction) to use for each SPD entry... the only
'key' frmo SPD to SAD is the RE-LE pair, which have two entries in SAD.
And it seems that linux is choosing between them somewhat randomly.
When the number of networks/tunnels increases, number of entries increases
as well, and the chances for single tunnel to work decreases appropriately.
So the question is: is the setup like this one supposed to work at all
in linux?
I know there are other "less ugly" ways to achieve the same effect, eg
by using GRE/IPIP tunnels and incapsulating the traffic into IPSEC (this
way, we'll have only one transport-mode IPSEC "connection" and normal
interfaces to route traffic to/via), but this is NOT how the whole
infrastrtructure in their network is implemented - they - it seems, for
whatever reason - use separate tunnels to route each network.
Thanks.
/mjt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
