Menu
▾
▴
Re: [Ipsec-tools-devel] isakmp to isakmp-natt traffic return bug
|
From: Jaco K. <ja...@ul...> - 2011-06-06 22:33:09
|
Hi,
All sorted. ipsec-tools 0.8.0 sorts out the issues I had, together with
the patch below and another to ignore illegal FQDN IDs as sent by
Windows XP when doing ISAKMP over NAT-T and all is finally working!
Kind Regards,
Jaco
On 06/06/11 22:12, Jaco Kroon wrote:
> Hi All,
>
> I've spotted some behavior which seems to be wrong, so I'm going to try
> and explain what I am seeing, hopefully someone can point out what's
> going wrong and where (and hopefully provide me with either a workaround
> or a fix).
>
> Firstly, I'm using two different clients, one Windows XP box (L2TP/IPSec
> client) and one Gentoo Linux client (racoon on the client). My server
> is also Gentoo Linux, both Linux's has ipsec-tools , and the server has
> the following patch additionally installed (looking for road-warrior
> like functionality, so the patch is basically to enable the server to
> re-use the same pre-shared key for the whole internet - yea, I know I
> should be setting up an PKI but the client is looking for a global
> pre-shared key, we've advised the risks, but a client is always right,
> even when they're wrong).
>
> --- ipsec-tools-0.7.3.o/src/racoon/oakley.c 2009-08-13
> 11:18:45.000000000 +0200
> +++ ipsec-tools-0.7.3/src/racoon/oakley.c 2011-06-06
> 09:36:11.000000000 +0200
> @@ -2498,8 +2498,21 @@
> plog(LLV_ERROR, LOCATION, iph1->remote,
> "couldn't find the pskey for %s.\n",
> saddrwop2str(iph1->remote));
> + }
> + }
> + if (iph1->authstr == NULL) {
> + /*
> + * If we could not locate a psk above try and locate
> + * the default psk, ie, "*".
> + */
> + iph1->authstr = privsep_getpsk("*", 1);
> + if (iph1->authstr == NULL) {
> + plog(LLV_ERROR, LOCATION, iph1->remote,
> + "couldn't find the the default
> pskey either.\n");
> goto end;
> }
> + plog(LLV_NOTIFY, LOCATION, iph1->remote,
> + "Using default PSK.\n");
> }
> plog(LLV_DEBUG, LOCATION, NULL, "the psk found.\n");
> /* should be secret PSK */
>
> This just allows me to put a "* psk" line in psk.txt. This part works.
>
> Pertinent config options on the server (please ask if I miss something):
>
> path pre_shared_key "/etc/racoon/psk.txt";
>
> remote anonymous {
> exchange_mode main;
> doi ipsec_doi;
> situation identity_only;
>
> nat_traversal on;
> initial_contact off;
> passive on;
> proposal_check obey;
>
> ... here goes the proposal (this passes) ...
> }
>
> In my first test case Ive got:
>
> client -> NAT GW -> inet <- Server
>
> On the NAT GW running tcpdump shows this:
>
> 18:29:02.939323 IP 172.24.5.10.500 > 46.134.75.12.500: [|isakmp]
> 18:29:02.939363 IP 46.241.240.125.500 > 46.134.75.12.500: [|isakmp]
> 18:29:03.385950 IP 46.134.75.12.500 > 46.241.240.125.500: [|isakmp]
> 18:29:03.385966 IP 46.134.75.12.500 > 172.24.5.10.500: [|isakmp]
> 18:29:04.609208 IP 172.24.5.10.500 > 46.134.75.12.500: [|isakmp]
> 18:29:04.609222 IP 46.241.240.125.500 > 46.134.75.12.500: [|isakmp]
> 18:29:05.060864 IP 46.134.75.12.500 > 46.241.240.125.500: [|isakmp]
> 18:29:05.060903 IP 46.134.75.12.500 > 172.24.5.10.500: [|isakmp]
> 18:29:06.169912 IP 172.24.5.10.4500 > 46.134.75.12.4500: NONESP-encap:
> [|isakmp]
> 18:29:06.169937 IP 46.241.240.125.4500 > 46.134.75.12.4500:
> NONESP-encap: [|isakmp]
> 18:29:14.635666 IP 46.134.75.12.500 > 46.241.240.125.4500: [|isakmp]
> 18:29:16.319506 IP 172.24.5.10.4500 > 46.134.75.12.4500: NONESP-encap:
> [|isakmp]
> 18:29:16.319522 IP 46.241.240.125.4500 > 46.134.75.12.4500:
> NONESP-encap: [|isakmp]
> 18:29:18.253730 IP 172.24.5.10.4500 > 46.134.75.12.4500:
> isakmp-nat-keep-alive
> 18:29:18.253743 IP 46.241.240.125.4500 > 46.134.75.12.4500:
> isakmp-nat-keep-alive
> 18:29:22.764709 IP 46.134.75.12.500 > 46.241.240.125.4500: [|isakmp]
> 18:29:24.771837 IP 46.134.75.12.500 > 46.241.240.125.4500: [|isakmp]
> 18:29:25.142336 IP 172.24.5.10.4500 > 46.134.75.12.4500: NONESP-encap:
> [|isakmp]
>
> 172.24.5.10 is the client.
> 46.134.75.12 is the server.
> 46.241.240.125 is the external IP of the NAT GW.
>
> As can be seen the NAT seems to work absolutely fine (all packets shows
> twice - tcpdump -i any, one packet with the external GW IP and the other
> with the internal IP), except the second and third last packets, which
> only shows on the external side.
>
> Looking at the above my assumption is that port 500 -> 500 opens a
> mapping in the connection tracking table on the GW, thus the traffic
> goes just fine in both directions. Then the 4500 -> 4500 packet does
> exactly the same and this is where the problem then comes in, the server
> still responds FROM port 500 to port 4500, seeing that the GW has no
> mapping for this incoming pair it has no choice but to drop the packet,
> preventing the security negotiation from completing.
>
> What I did to confirm that this was indeed the case is I installed the
> exact same server config a box on my LAN, and set nat_traversal to force.
>
> This resulted in a similar sequence of packets, with the exception that
> since there is no NAT the traffic from port 500 -> 4500 reached it's
> destination, and resulted in the traffic to complete correctly.
>
> I'm not all that familiar with the code so don't know where to go
> looking for this problem. Or even whether 0.8.0 has perhaps fixed this
> already (didn't see anything obvious in the ChangeLog). Kernels on my
> server and client is 2.6.37.2 in both cases. My setup for setkey on the
> server:
>
> spdadd 0.0.0.0/0[1701] 0.0.0.0/0 udp -P out ipsec
> esp/transport//require;
>
> spdadd 0.0.0.0/0 0.0.0.0/0[1701] udp -P in ipsec
> esp/transport//require;
>
> For the client it's an exact reverse with the in and out keywords just
> swapped around.
>
> The above behavior was observed and confirmed using Linux as the NAT GW,
> but the client has reported the same error occuring on Windows behind at
> least two other unknown NAT gateways.
>
> As it stands the only "fix" I can see is a really ugly iptables based
> hack to rewrite the source port to port 4500 on all packets outbound to
> socket pairs that has originally been inbound to port 4500. And
> honestly, that really feels like a massive kludge and I would not even
> know where to start with pulling off a hack like that anyway.
>
> Kind Regards,
> Jaco
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Ipsec-tools-devel mailing list
> Ips...@li...
> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
|