Re: Support for IPSec NAT-T in transoprt mode
24.04.2012 23:10, Andreas Longwitz ?:
There is one limitation I would like to get over. From man 8 setkey:
System that do not perform the port check cannot support multiple
endpoints behind the same NAT. I think this is a FreeBSD kernel restriction:
For the first incoming L2TP packet the IPSEC part of the kernel does not
save the source port in the corresponding SA (maybe a field like
natt_l2tp_port). So the kernel does for outgoing L2TP packets not know
the correct SA, if two ore more SA's with the same IP exists.
I would like to know if the patch mentioned in this thread adresses this
problem.
Thank you very much for your attention.
I've been testing those patches (actually, without your part) and YES
it's a big problem with clients (Android, Windows Mobile) behind the
same NAT. I cannot find the solution yet, but I'm very interested in it.
So, my Androids is some sort of stupid bricks, they do not send NAT-OA
payloads at phase 2, and ipsec-tools fills the SPD with IPs taken from
IDs. But this is not the correct way. IDs contain LAN (which is behind
the NAT) addresses, and FreeBSD cannot route packets to the IPSec crypto
part.
I've made some quick patching of IPSec tools to get my devices working,
but I don't know if they accomodate to the RFCs and ISAKMP. The main
idea is to take NAT-OAi and NAT-OAr addresses not from IDs when we are
using NAT-T, but from real source and destination addresses of the
server and client NATs.
Here is my ipsec-tools patch (i've call it patch-zz-local-2.diff and
place at /usr/ports/security/ipsec-tools/files with two other patches
from kern /146190)
*** src/racoon/pfkey.c 2012-04-13 02:02:02.0 +0300
--- src/racoon/pfkey.c 2012-04-19 12:47:57.0 +0300
***
*** 1195,1200
--- 1195,1202
#ifdef SADB_X_EXT_NAT_T_FRAG
sa_args.l_natt_frag = iph2-ph1-rmconf-esp_frag;
#endif
+ plog(LLV_DEBUG2, LOCATION, NULL, sa_args.l_natt_oa =
%s\n, saddr2str(sa_args.l_natt_oa));
+ plog(LLV_DEBUG2, LOCATION, NULL, sa_args.l_natt_oa_dst =
%s\n, saddr2str(sa_args.l_natt_oa_dst));
}
#endif
***
*** 1483,1488
--- 1485,1492
#ifdef SADB_X_EXT_NAT_T_FRAG
sa_args.l_natt_frag = iph2-ph1-rmconf-esp_frag;
#endif
+ plog(LLV_DEBUG2, LOCATION, NULL, sa_args.l_natt_oa =
%s\n, saddr2str(sa_args.l_natt_oa));
+ plog(LLV_DEBUG2, LOCATION, NULL, sa_args.l_natt_oa_dst =
%s\n, saddr2str(sa_args.l_natt_oa_dst));
}
#endif
/* more info to fill in */
*** src/racoon/isakmp_quick.c 2011-03-14 19:18:13.0 +0200
--- src/racoon/isakmp_quick.c 2012-04-19 17:23:16.0 +0300
***
*** 562,567
--- 562,569
if (daddr == NULL)
goto end;
+ plog(LLV_DEBUG2, LOCATION, NULL, daddr = %s, natoa_src = %s,
natoa_dst = %s\n, saddr2str(daddr), saddr2str(iph2-natoa_src),
saddr2str(iph2-natoa_dst));
+
if (iph2-natoa_src == NULL)
iph2-natoa_src = daddr;
else if (iph2-natoa_dst == NULL)
***
*** 1262,1267
--- 1264,1271
if (daddr == NULL)
goto end;
+ plog(LLV_DEBUG2, LOCATION, NULL, daddr = %s, natoa_src = %s,
natoa_dst = %s\n, saddr2str(daddr), saddr2str(iph2-natoa_src),
saddr2str(iph2-natoa_dst));
+
if (iph2-natoa_dst == NULL)
iph2-natoa_dst = daddr;
else if (iph2-natoa_src == NULL)
***
*** 1309,1314
--- 1313,1345
plogdump(LLV_DEBUG, iph2-id-v, iph2-id-l);
}
+ #ifdef ENABLE_NATT
+ if (iph2-ph1-natt_flags NAT_DETECTED)
+ {
+ struct sockaddr_storage addr;
+ u_int8_t prefix;
+ u_int16_t ul_proto;
+
+ if (iph2-natoa_src == NULL)
+ if (!ipsecdoi_id2sockaddr(iph2-id,
+ (struct sockaddr *)addr,
+ prefix,ul_proto))
+ {
+ iph2-natoa_src = dupsaddr((struct sockaddr
*)addr);
+ plog(LLV_DEBUG2, LOCATION, NULL, natoa_src set from
IDcr2: natoa_src = %s\n, saddr2str(iph2-natoa_src));
+ }
+
+ if (iph2-natoa_dst == NULL)
+ if (!ipsecdoi_id2sockaddr(iph2-id_p,
+ (struct sockaddr *)addr,
+ prefix,ul_proto))
+ {
+ iph2-natoa_dst = dupsaddr((struct sockaddr
*)addr);
+ plog(LLV_DEBUG2, LOCATION, NULL, natoa_dst set from
IDci2: natoa_dst
Re: Support for IPSec NAT-T in transoprt mode
On 2. May 2012, at 18:50 , Zmiter wrote: 24.04.2012 23:10, Andreas Longwitz ?: There is one limitation I would like to get over. From man 8 setkey: System that do not perform the port check cannot support multiple endpoints behind the same NAT. I think this is a FreeBSD kernel restriction: For the first incoming L2TP packet the IPSEC part of the kernel does not save the source port in the corresponding SA (maybe a field like natt_l2tp_port). So the kernel does for outgoing L2TP packets not know the correct SA, if two ore more SA's with the same IP exists. I would like to know if the patch mentioned in this thread adresses this problem. Thank you very much for your attention. I've been testing those patches (actually, without your part) and YES it's a big problem with clients (Android, Windows Mobile) behind the same NAT. I cannot find the solution yet, but I'm very interested in it. So, my Androids is some sort of stupid bricks, they do not send NAT-OA payloads at phase 2, and ipsec-tools fills the SPD with IPs taken from IDs. But this is not the correct way. IDs contain LAN (which is behind the NAT) addresses, and FreeBSD cannot route packets to the IPSec crypto part. I've made some quick patching of IPSec tools to get my devices working, but I don't know if they accomodate to the RFCs and ISAKMP. The main idea is to take NAT-OAi and NAT-OAr addresses not from IDs when we are using NAT-T, but from real source and destination addresses of the server and client NATs. Here is my ipsec-tools patch (i've call it patch-zz-local-2.diff and place at /usr/ports/security/ipsec-tools/files with two other patches from kern /146190) ... It differs from that in kern/146190 in one simple thing. I have problems with the original patch from kern/146190. When there was no NAT-OAi or NAT-OAr values in the kernel space, checksums was calculated at 0, but they were not ignored despite of the sysctl net.inet.esp.esp_ignore_natt_cksum value. The improvement allows to ignore every checksum in esp packets when net.inet.esp.esp_ignore_natt_cksum=1. Just replying to the last one -- you all need to make sure that this will work with a double-NAT (both i and r sitting behind a NAT) and not just i behind a NAT and r sitting there with a globally routable IP. The changes suddenly become a lot more complex. Just my 5cts. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for IPSec NAT-T in transoprt mode
I run FreeBSD 8.2, ipsec-tools-0.8.0_2 and mpd-5.5.
To get NATed VPN clients working through L2TP/IPSec I use the patches
given in kern/146190 for the files esp_var.h, ipsec.c, ipsec_input.c
(only the Ignore checksum part) and xform_esp.c. Further the following
patch:
--- key.c.1st 2011-09-29 10:39:44.0 +0200
+++ key.c 2012-04-24 21:40:55.0 +0200
@@ -1312,11 +1312,14 @@
continue;
if (key_cmpspidx_exactly(spidx, sp-spidx)) {
SP_ADDREF(sp);
- break;
+ SPTREE_UNLOCK();
+ goto found;
}
}
SPTREE_UNLOCK();
+ return NULL;
+ found:
return sp;
}
@@ -2967,11 +2970,15 @@
LIST_FOREACH(sah, V_sahtree, chain) {
if (sah-state == SADB_SASTATE_DEAD)
continue;
- if (key_cmpsaidx(sah-saidx, saidx, CMP_REQID))
- break;
+ if (key_cmpsaidx(sah-saidx, saidx, CMP_REQID)) {
+ SAHTREE_UNLOCK();
+ goto found;
+ }
}
SAHTREE_UNLOCK();
+ return NULL;
+ found:
return sah;
}
@@ -4064,10 +4071,12 @@
/*
* If NAT-T is enabled, check ports for tunnel mode.
* Do not check ports if they are set to zero in the SPD.
-* Also do not do it for transport mode, as there is no
+* Also do not do it for native transport mode, as there
is no
* port information available in the SP.
*/
- if (saidx1-mode == IPSEC_MODE_TUNNEL
+ if ((saidx1-mode == IPSEC_MODE_TUNNEL ||
+ (saidx1-mode == IPSEC_MODE_TRANSPORT
+ saidx1-proto == IPPROTO_ESP))
saidx1-src.sa.sa_family == AF_INET
saidx1-dst.sa.sa_family == AF_INET
Then a NATed FreeBSD or Android client works fine with L2TP/IPSec (PSK
or certificate), also every iPhone with L2TP/IPSec (PSK). I don't know
if we can handle the server side of Cisco IPSEC used by Apple for
certificates on the iphone. Hints are very welcome.
There is one limitation I would like to get over. From man 8 setkey:
System that do not perform the port check cannot support multiple
endpoints behind the same NAT. I think this is a FreeBSD kernel restriction:
For the first incoming L2TP packet the IPSEC part of the kernel does not
save the source port in the corresponding SA (maybe a field like
natt_l2tp_port). So the kernel does for outgoing L2TP packets not know
the correct SA, if two ore more SA's with the same IP exists.
I would like to know if the patch mentioned in this thread adresses this
problem.
--
Dr. Andreas Longwitz
Data Service GmbH
Beethovenstr. 2A
23617 Stockelsdorf
Amtsgericht Lübeck, HRB 318 BS
Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for IPSec NAT-T in transoprt mode
Hi. On Sun, Apr 15, 2012 at 04:40:03PM +0300, Zmiter wrote: 14.04.2012 19:59, Bjoern A. Zeeb ??: On 13. Apr 2012, at 04:28 , Zmiter wrote: Hello. Does FreeBSD 8.[0-4] support IPSec NAT-T in transport mode? Or it's still in broken state? It's not broken; it was never implemented. No FreeBSD tree shipped does support transport mode at this time. There are patches but you also need to fix ipsec-tools or your ike daemon. If you do the latter I can commit the former. /bz Where could I get that patches? I'd like to test them and to see what could I do with them. You can get kernel patches in kern/146190, but as said in the pr and by Bjoern, it needs some work on userland (IKE daemon). And, if it's really so difficult to implement transport mode in kernel some way, I didn't review/try the patch, but kernel part seems to be done. describe it (I think, all the work for third parties will be implemented through pfkey interface), and wait some time (or may be help a little) until it'll be implemented in ipsec-tools. It's not the egg and chicken problem, may be the kernel must be the first. Or may be I'm not in theme so deep? Is it really some sort or big and principal incompatibilities with ipsec-tools? That's why I took the pr a while ago: to have a look at both parts (kernel and ipsec-tools) and try/commit that once patches exists for both. Afaik, no one already worked on the userland part for ipsec-tools (contact me if I'm wrong !). Yvan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for IPSec NAT-T in transoprt mode
16.04.2012 12:59, VANHULLEBUS Yvan написал: I didn't review/try the patch, but kernel part seems to be done. Upon my testing it's not so good as it seems. I found some trouble with it. 1. sysctl net.inet.esp.esp_ignore_natt_cksum works not as expected. If there is troubles with function key_compute_natt_cksum, bad (not recalculated) checksums are not ignored and packets are droped, increasing bad udp checksums counter. 2. received by L2TP daemon decrypted packets seemed to it as packets originated from NAT address, but not from LAN behind the NAT. So, L2TP daemon answers them back to NAT, and ofcourse they not satisfy the SPD policy and not being encrypted through IPSec, as a result they are never arrive to the NATed host. May be I'm doing something wrong, but my little research shows me described results. I'll be appressiating any help with that. 16.04.2012 Zmiter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for IPSec NAT-T in transoprt mode
14.04.2012 19:59, Bjoern A. Zeeb написал: On 13. Apr 2012, at 04:28 , Zmiter wrote: Hello. Does FreeBSD 8.[0-4] support IPSec NAT-T in transport mode? Or it's still in broken state? It's not broken; it was never implemented. No FreeBSD tree shipped does support transport mode at this time. There are patches but you also need to fix ipsec-tools or your ike daemon. If you do the latter I can commit the former. /bz Where could I get that patches? I'd like to test them and to see what could I do with them. And, if it's really so difficult to implement transport mode in kernel some way, describe it (I think, all the work for third parties will be implemented through pfkey interface), and wait some time (or may be help a little) until it'll be implemented in ipsec-tools. It's not the egg and chicken problem, may be the kernel must be the first. Or may be I'm not in theme so deep? Is it really some sort or big and principal incompatibilities with ipsec-tools? Thank a lot 15.04.2012 Zmiter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for IPSec NAT-T in transoprt mode
15.04.2012 16:47, Patrick M. Hausen написал: Racoon for IKE, standard IPSEC as shipped with RELENG_6. Was is removed afterwards? The problem in traversing NAT. IPSec+L2TP works great WITHOUT NAT. NAT-T feature was implemented in 8.0 (There was some patches fo 7.0 as I remember). But it lacks of IPSec transport mode. 15.04.2012 Zmiter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for IPSec NAT-T in transoprt mode
Hi, all, Am 14.04.2012 um 18:59 schrieb Bjoern A. Zeeb: No FreeBSD tree shipped does support transport mode at this time. I remember that I ran a Soekris device with RELENG_6 NanoBSD to drive my VPN connection via transport mode. Racoon for IKE, standard IPSEC as shipped with RELENG_6. Was is removed afterwards? Regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Support for IPSec NAT-T in transoprt mode
On 13. Apr 2012, at 04:28 , Zmiter wrote: Hello. Does FreeBSD 8.[0-4] support IPSec NAT-T in transport mode? Or it's still in broken state? It's not broken; it was never implemented. No FreeBSD tree shipped does support transport mode at this time. There are patches but you also need to fix ipsec-tools or your ike daemon. If you do the latter I can commit the former. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Support for IPSec NAT-T in transoprt mode
Hello. Does FreeBSD 8.[0-4] support IPSec NAT-T in transport mode? Or it's still in broken state? I need to connect NATed VPN clients through L2TP/IPSec and seeing nothing in mpd5 logs, but growing counters of bad checksums in udp packets. After some research I found an opened kern/146190 with some sort of solving the problem through disabling checksum validation, but it still not work. Every incoming UDP encapsulated ESP packet toggles two counters: udp no checksums (because of 0 value in every incoming packet udp checksum) and udp bad checksums (hmmm..., I thought it shouldn't be happen with a magic patch). So, can anyone tell me is it possible to connect my NATed VPN clients through L2TP/IPSec or it's impossible nowadays? Thanks a lot. Zmiter 12.04.2012 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
