Hi guys,
I came across one strange thing, when I tried to make IPSEC work on
GNU/Linux. Packages came from Debian Sarge, so ipsec-tools (0.5.2),
running kernel is 2.6.11.2, but the same is valid for 2.6.12.4, for example.
My setup is little more complicated, so I will describe it later. First,
the real problem:
If you check the following output from Ethereal, showing two captured
packets, you can notice a strange thing, considering SPI numbers. Both
packets are part of NAT-T communication, so one would expect, that in
both cases there will be ESP packet encapsulated in UDP protocol, port
numbers 4500.
In fact, both are encapsulated. But the packet number 14, has wrong
value in 'Protocol:' field of IP header. There should be 0x11 (UDP), but
0x32 (ESP) is there. And therefore, the SPI number in packet number 14
is actually a part of UDP header. :-(
So obviously, connection doesn't work. I have to state, that all SAs are
negotiated properly, and also policy databases look filled with correct
entries. On server side, which is sending packets like packet #14, the
policy is generated, because client's public IP address can change.
This example was sniffed in lab conditions, were no nat was necessary,
but it was forced from config file. The same behaviour is visible, when
real nat is there, so addresses are actually translated.
No. Time Source Destination Protocol
Info
13 2.963373 10.16.250.5 10.16.250.6 ESP
ESP (SPI=0x0f7d3399)
Frame 13 (190 bytes on wire, 190 bytes captured)
Ethernet II, Src: 00:01:b4:02:08:bd, Dst: 00:0b:6b:35:4d:f0
Internet Protocol, Src Addr: 10.16.250.5 (10.16.250.5), Dst Addr:
10.16.250.6 (10.16.250.6)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 176
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x3211 (correct)
Source: 10.16.250.5 (10.16.250.5)
Destination: 10.16.250.6 (10.16.250.6)
User Datagram Protocol, Src Port: 4500 (4500), Dst Port: 4500 (4500)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
SPI: 0x0f7d3399
Sequence: 1
Data (140 bytes)
0000 00 0b 6b 35 4d f0 00 01 b4 02 08 bd 08 00 45 00 ..k5M.........E.
0010 00 b0 00 00 40 00 40 11 32 11 0a 10 fa 05 0a 10 ....@.@.2.......
0020 fa 06 11 94 11 94 00 9c 00 00 0f 7d 33 99 00 00 ...........}3...
0030 00 01 ae f6 71 e6 39 df b5 ad f9 15 d0 53 1a 48 ....q.9......S.H
0040 12 b9 1e 00 5a 42 b3 e6 3d 6f 75 ee 22 ea fb a6 ....ZB..=ou."...
0050 e5 4e e0 02 00 a1 aa 6b 97 3a f0 b7 3a 2c b9 70 .N.....k.:..:,.p
0060 1a 3e 9c b5 b5 a1 c4 33 1c 7a 8d 05 50 f4 2f e6 .>.....3.z..P./.
0070 18 43 e0 5d 9b 11 3f 68 62 aa 32 c7 e4 0b 62 93 .C.]..?hb.2...b.
0080 27 00 2b 0f 9b 23 a3 fa 90 45 68 46 d4 80 1d 89 '.+..#...EhF....
0090 fb 90 54 d6 c2 91 21 de e0 ca ff a4 80 38 28 68 ..T...!......8(h
00a0 d0 99 62 c9 59 74 12 af 74 ab a1 09 0a a1 6a ce ..b.Yt..t.....j.
00b0 70 bc d4 1e ab 99 3e 92 18 b3 e2 1f ad 31 p.....>......1
No. Time Source Destination Protocol
Info
14 3.963150 10.16.250.6 10.16.250.5 ESP
ESP (SPI=0x11941194)
Frame 14 (190 bytes on wire, 190 bytes captured)
Ethernet II, Src: 00:0b:6b:35:4d:f0, Dst: 00:01:b4:02:08:bd
Internet Protocol, Src Addr: 10.16.250.6 (10.16.250.6), Dst Addr:
10.16.250.5 (10.16.250.5)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
Total Length: 168
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: ESP (0x32)
Header checksum: 0x3211 (incorrect, should be 0x31f8)
Source: 10.16.250.6 (10.16.250.6)
Destination: 10.16.250.5 (10.16.250.5)
Encapsulating Security Payload
SPI: 0x11941194
Sequence: 10223616
Data (140 bytes)
0000 00 01 b4 02 08 bd 00 0b 6b 35 4d f0 08 00 45 00 ........k5M...E.
0010 00 a8 00 00 40 00 40 32 32 11 0a 10 fa 06 0a 10 ....@.@22.......
0020 fa 05 11 94 11 94 00 9c 00 00 0c 5b 32 66 00 00 ...........[2f..
0030 00 03 af 48 ff b4 ee 53 79 82 68 e2 eb ec b1 b7 ...H...Sy.h.....
0040 83 90 3e 6c 24 58 09 0c 67 03 2f ca 76 b2 03 bb ..>l$X..g./.v...
0050 97 3d 46 cf 8f 0c 0b 8d 97 31 79 94 f7 e8 94 87 .=F......1y.....
0060 62 68 ed 2e 28 57 e6 a0 37 3f 4a e7 06 13 09 d5 bh..(W..7?J.....
0070 ef ab 39 46 ed 25 38 e6 83 36 54 d5 09 29 86 dd ..9F.%8..6T..)..
0080 6f f9 42 c9 1d a6 21 30 eb 83 74 ef 82 da a9 5d o.B...!0..t....]
0090 e8 c2 c3 50 ba cc 68 2f 4e 50 71 39 66 2b 40 db ...P..h/NPq9f+@.
00a0 9b 6e c0 c1 e2 f7 69 be 67 ea 44 bd 4e 43 eb 1a .n....i.g.D.NC..
00b0 08 f6 a6 f8 19 01 9c 31 63 8f d7 db f1 20 .......1c....
Considering my setup, the goal is to connect two routers with encrypted
GRE tunnel. First router have dummy interface, with address like
192.168.250.5/32 and this dummy interface's address is known in routing
table of the other router. The other router has 192.168.250.6/32 address
on its dummy interface.
The endpoints of the GRE tunnel are these addresses of dummy interfaces.
When policy database is empty (so no encryption in place), the tunnel
works perfectly. Of course, only in case when NAT-T was forced, but
otherwise not needed.
The policy database on initiatior looks like:
10.16.250.5[any] 10.16.250.6[any] gre
in ipsec
esp/tunnel/10.16.250.5-10.16.250.6/require
created: Nov 30 19:11:42 1999 lastused: Nov 30 19:20:45 1999
lifetime: 0(s) validtime: 0(s)
spid=120 seq=6 pid=6066
refcnt=1
10.16.250.6[any] 10.16.250.5[any] gre
out ipsec
esp/tunnel/10.16.250.6-10.16.250.5/require
created: Nov 30 19:11:42 1999 lastused: Nov 30 19:20:45 1999
lifetime: 0(s) validtime: 0(s)
spid=113 seq=5 pid=6066
refcnt=1
10.16.250.5[any] 10.16.250.6[any] gre
fwd ipsec
esp/tunnel/10.16.250.5-10.16.250.6/require
created: Nov 30 19:11:42 1999 lastused:
lifetime: 0(s) validtime: 0(s)
spid=130 seq=4 pid=6066
refcnt=1
and I think, that it's correct. Similar, by my opinion valid policy, is
generated on the other side:
10.16.250.6[any] 10.16.250.5[any] gre
in ipsec
esp/tunnel/10.16.250.6-10.16.250.5/require
created: Oct 29 06:30:41 2005 lastused: Oct 29 06:30:48 2005
lifetime: 28800(s) validtime: 0(s)
spid=840 seq=6 pid=31783
refcnt=2
10.16.250.5[any] 10.16.250.6[any] gre
out ipsec
esp/tunnel/10.16.250.5-10.16.250.6/require
created: Oct 29 06:30:41 2005 lastused: Oct 29 06:30:48 2005
lifetime: 28800(s) validtime: 0(s)
spid=857 seq=5 pid=31783
refcnt=2
10.16.250.6[any] 10.16.250.5[any] gre
fwd ipsec
esp/tunnel/10.16.250.6-10.16.250.5/require
created: Oct 29 06:30:41 2005 lastused:
lifetime: 28800(s) validtime: 0(s)
spid=850 seq=4 pid=31783
refcnt=2
Also logs at the first sight looks, like everything was properly
established. So, why an IP header of returning packets has ESP protocol
in 'Protocol:' field?? Because such packet is clearly bad, useless and
denied by the other side. I greatly appreciate any explanation. :-)
If some more information, like debug logs or anything is needed, it is
immediately available upon request.
Thank you very much in advance, and sorry for this long post. I hope,
that I asked on the right list.
Best Regards,
Martin
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
