[Openswan dev]
IPCOMP and NAT-T problems (maybe SA creation related)
Egon Burgener
egon.burgener at terreactive.ch
Wed May 31 16:54:46 CEST 2006
Hello,
Referring to the initial message sent to the users mailinglist:
http://lists.openswan.org/pipermail/users/2006-May/009714.html
we've been digging further into this issue and would like to ask for
some support from the experts. Our findings so far are vaguely summoned
as follows:
The COMP SA does not contain information about NAT-T (eg. natt_type),
whereas the ESP SA certainly does, which is shown in a real life except
of this ipsec spi dump:
esp0x225b2057 at 1.1.1.201 ESP_AES_HMAC_SHA1: dir=out src=1.1.1.203
iv_bits=128bits iv=0xd8c64bd5f9f23abc5502b3aef69fd206 ooowin=64 seq=3
alen=160 aklen=160 eklen=256
life(c,s,h)=bytes(456,0,0)addtime(7,0,0)usetime(6,0,0)packets(3,0,0)
idle=4 natencap=nonesp natsport=4500 natdport=4500 refcount=4 ref=1862
reftable=0 refentry=1862
comp0x629a at 1.1.1.203 COMP_DEFLATE: dir=in src=1.1.1.201
life(c,s,h)=addtime(7,0,0) ratio=330:330 natencap=none natsport=0
natdport=0 refcount=5 ref=1853 reftable=0 refentry=1853
esp0x8ec9fab7 at 1.1.1.203 ESP_AES_HMAC_SHA1: dir=in src=1.1.1.201
iv_bits=128bits iv=0x67dd3d2cd4beb553aeefcf05c47cab34 ooowin=64 seq=3
bit=0x7 alen=160 aklen=160 eklen=256
life(c,s,h)=bytes(354,0,0)addtime(7,0,0)usetime(6,0,0)packets(3,0,0)
idle=4 natencap=nonesp natsport=4500 natdport=4500 refcount=7 ref=1854
reftable=0 refentry=1854
comp0x7e8c at 1.1.1.201 COMP_DEFLATE: dir=out src=1.1.1.203
life(c,s,h)=bytes(330,0,0)addtime(7,0,0)usetime(6,0,0)packets(3,0,0)
idle=4 ratio=330:330 natencap=none natsport=0 natdport=0 refcount=5
ref=1861 reftable=0 refentry=1861
tun0x108f at 1.1.1.203 IPIP: dir=in src=1.1.1.201
policy=172.20.0.145/32->1.1.1.204/30 flags=0x8<>
life(c,s,h)=bytes(354,0,0)addtime(7,0,0)usetime(6,0,0)packets(3,0,0)
idle=4 natencap=none natsport=0 natdport=0 refcount=4 ref=1852
reftable=0 refentry=1852
tun0x1090 at 1.1.1.201 IPIP: dir=out src=1.1.1.203
life(c,s,h)=bytes(330,0,0)addtime(7,0,0)usetime(6,0,0)packets(3,0,0)
idle=4 natencap=none natsport=0 natdport=0 refcount=7 ref=1860
reftable=0 refentry=1860
Looking at the inbound policy check for the NAT-T code in the receive
path of the ipsec handling:
#ifdef CONFIG_IPSEC_NAT_TRAVERSAL
KLIPS_PRINT(debug_rcv,
"klips_debug:ipsec_rcv: "
"natt_type=%u tdbp->ips_natt_type=%u : %s\n",
irs->natt_type, newipsp->ips_natt_type,
(irs->natt_type==newipsp->ips_natt_type)?"ok":"bad");
if (irs->natt_type != newipsp->ips_natt_type) {
KLIPS_PRINT(debug_rcv,
"klips_debug:ipsec_rcv: "
"SA:%s does not agree with expected
NAT-T policy.\n",
irs->sa_len ? irs->sa : " (error)");
if(irs->stats) {
irs->stats->rx_dropped++;
}
ipsec_sa_put(newipsp);
return IPSEC_RCV_FAILEDINBOUND;
}
#endif
The SA which is looked up from the SADB in-kernel contains a different
ips_natt_type for the newipsp for packets > 90 bytes payload (meaning
IPCOMP is in use) and thus the comparison fails, as shown below:
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv_decap_once: decap (50)
from 1.1.1.201 -> 1.1.1.203
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_sa_getbyid: linked entry in
ipsec_sa table for hash=177 of SA:esp.8ec9faac at 1.1.1.203 requested.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv:
SA:esp.8ec9faac at 1.1.1.203, src=1.1.1.201 of pkt agrees with expected SA
source address policy.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv:
SA:esp.8ec9faac at 1.1.1.203 First SA in group.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv: natt_type=2
tdbp->ips_natt_type=2 : ok
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv: packet from 1.1.1.201
received with seq=9 (iv)=0x6aa689968a227a96 iplen=128 esplen=88
sa=esp.8ec9faac at 1.1.1.203
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv: encalg = 12, authalg =
3.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv: authentication
successful.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv: encalg=12 esphlen=24
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_alg_esp_encrypt: entering
with encalg=12, ixt_e=d08dc880
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_alg_esp_encrypt: calling
cbc_encrypt encalg=12 ips_key_e=c6a87c00 idat=ce3904b4 ilen=64
iv=ce3904a4, encrypt=0
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_alg_esp_encrypt: returned
ret=64
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv:
SA:esp.8ec9faac at 1.1.1.203, Another IPSEC header to process.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv_decap_once: decap (108)
from 1.1.1.201 -> 1.1.1.203
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_sa_getbyid: linked entry in
ipsec_sa table for hash=170 of SA:comp.6290 at 1.1.1.203 requested.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv:
SA:comp.6290 at 1.1.1.203, src=1.1.1.201 of pkt agrees with expected SA
source address policy.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv: SA:comp.6290 at 1.1.1.203
grouping from previous SA is OK.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv: natt_type=2
tdbp->ips_natt_type=0 : bad
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv: SA:comp.6290 at 1.1.1.203
does not agree with expected NAT-T policy.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_sa_put: ipsec_sa
SA:comp.6290 at 1.1.1.203, ref:1751 reference count decremented.
May 31 16:34:13 s_int at vpn0 klips_debug:ipsec_rcv: decap_once failed: -12
Following theories are floating around:
1) Pluto does not correctly add NAT-T information to the SA comp via the
netlink interface.
2) The inbound_policy_check should not perform NAT-T checks based on SA
comp information, checks for SA esp works.
3) The netlink interface in the kernel does not update the SADB for all
related SAs.
4) We don't know what we're talking about.
We would really welcome some feedback on this topic.
Thanks & cheers,
Egon
--
--------------------------------------------------------------
addr://Kasinostrasse 30, CH-5001 Aarau tel://++41 62 823 9355
http://www.terreactive.com fax://++41 62 823 9356
--------------------------------------------------------------
10 Jahre Kompetenz in IT-Sicherheit. 1996 - 2006
Wir sichern Ihren Erfolg. terreActive AG
--------------------------------------------------------------
More information about the Dev
mailing list