ipsec-tools-devel Mailing List for [PROJECT ABANDONED] IPsec Tools (Page 323)
Brought to you by:
mit_warlord,
netbsd
This list is closed, nobody may subscribe to it.
2003 |
Jan
|
Feb
|
Mar
(3) |
Apr
(6) |
May
|
Jun
(14) |
Jul
(4) |
Aug
(19) |
Sep
(27) |
Oct
(7) |
Nov
(4) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(58) |
Feb
(20) |
Mar
(70) |
Apr
(93) |
May
(102) |
Jun
(130) |
Jul
(47) |
Aug
(61) |
Sep
(149) |
Oct
(160) |
Nov
(243) |
Dec
(94) |
2005 |
Jan
(199) |
Feb
(166) |
Mar
(276) |
Apr
(422) |
May
(289) |
Jun
(222) |
Jul
(306) |
Aug
(154) |
Sep
(72) |
Oct
(163) |
Nov
(113) |
Dec
(195) |
2006 |
Jan
(174) |
Feb
(94) |
Mar
(130) |
Apr
(45) |
May
(85) |
Jun
(115) |
Jul
(120) |
Aug
(111) |
Sep
(210) |
Oct
(56) |
Nov
(72) |
Dec
(30) |
2007 |
Jan
(56) |
Feb
(49) |
Mar
(35) |
Apr
(58) |
May
(83) |
Jun
(101) |
Jul
(46) |
Aug
(58) |
Sep
(47) |
Oct
(58) |
Nov
(55) |
Dec
(54) |
2008 |
Jan
(52) |
Feb
(21) |
Mar
(20) |
Apr
(49) |
May
(20) |
Jun
(37) |
Jul
(101) |
Aug
(49) |
Sep
(75) |
Oct
(152) |
Nov
(34) |
Dec
(63) |
2009 |
Jan
(90) |
Feb
(12) |
Mar
(88) |
Apr
(49) |
May
(36) |
Jun
(36) |
Jul
(52) |
Aug
(54) |
Sep
(19) |
Oct
(45) |
Nov
(18) |
Dec
(34) |
2010 |
Jan
(12) |
Feb
(28) |
Mar
(18) |
Apr
(19) |
May
(14) |
Jun
(15) |
Jul
(24) |
Aug
(45) |
Sep
(6) |
Oct
(4) |
Nov
(21) |
Dec
(23) |
2011 |
Jan
(24) |
Feb
(45) |
Mar
(56) |
Apr
(18) |
May
(4) |
Jun
(10) |
Jul
(15) |
Aug
(38) |
Sep
(11) |
Oct
(48) |
Nov
(55) |
Dec
(29) |
2012 |
Jan
(41) |
Feb
(15) |
Mar
(24) |
Apr
(17) |
May
(12) |
Jun
(17) |
Jul
(18) |
Aug
(17) |
Sep
(17) |
Oct
(4) |
Nov
(8) |
Dec
(13) |
2013 |
Jan
(9) |
Feb
(1) |
Mar
(10) |
Apr
(18) |
May
(18) |
Jun
(14) |
Jul
(34) |
Aug
(6) |
Sep
(7) |
Oct
|
Nov
(8) |
Dec
(4) |
2014 |
Jan
(12) |
Feb
(6) |
Mar
(1) |
Apr
(12) |
May
|
Jun
(2) |
Jul
(20) |
Aug
(1) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
|
2015 |
Jan
(16) |
Feb
(2) |
Mar
(9) |
Apr
|
May
(56) |
Jun
(6) |
Jul
(7) |
Aug
(1) |
Sep
(17) |
Oct
(13) |
Nov
(23) |
Dec
(3) |
2016 |
Jan
(10) |
Feb
(8) |
Mar
(34) |
Apr
(19) |
May
(26) |
Jun
(3) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(6) |
Nov
(5) |
Dec
(2) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2019 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
From: <mr...@mr...> - 2004-03-19 17:41:37
|
Michal Ludvig <mi...@lo...> writes: > --- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 14:22:22.000000000 +0= 100 > +++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 > @@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, > err =3D -EINVAL; > goto out; > } > + xp->selector.family - xp->family; That statement does nothing, AFAICS. --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: Michal L. <mi...@lo...> - 2004-03-19 17:25:30
|
On Mon, 15 Mar 2004, Brian Buesker wrote: > I came across the following problem. If you want to have a policy that > will match any IPv4 and IPv6 address for a specific port, say 21, it is > not possible to insert a single policy to do this nor is it possible to > insert two different policies. For example, if you just do: > > spdadd ::0/0[any] ::0/0[21] tcp -P in ipsec esp/transport//require; > spdadd ::0/0[21] ::0/0[any] tcp -P out ipsec esp/transport//require; > > Then these policies are only matched for IPv6 addresses, since > xfrm_policy_lookup compares the family of the policy to the family of > the flow. > > If instead you try to insert a policy for both IPv4 and IPv6, such as: > > spdadd ::0/0[any] ::0/0[5000] tcp -P in ipsec esp/transport//require; > spdadd ::0/0[5000] ::0/0[any] tcp -P out ipsec esp/transport//require; > > spdadd 0.0.0.0/0[any] 0.0.0.0/0[21] tcp -P in ipsec esp/transport//require; > spdadd 0.0.0.0/0[21] 0.0.0.0/0[any] tcp -P out ipsec esp/transport//require; > > Then you get an error saying the policy already exists, since > xfrm_policy_insert just compares the selectors and the family for them > doesn't get set by the PF_KEY code. I think the Netlink interface does > set the family in the selector, so it would allow for both IPv4 and > IPv6 policies to be inserted. Maybe PF_KEY should do this as well, by > setting xp->selector.family = xp->family in pfkey_spdadd. Something like the attached? Not tested, but looks reasonable... Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Michal L. <mi...@lo...> - 2004-03-19 15:16:32
|
Hi all, I have just released ipsec-tools 0.3rc3. It mainly fixes some compilation problems, adds some more verbosity to the diagnostic messages, and one significant (?) change: setkey option -h (hexdump) was renamed to -H and option -h now triggers help. If no real problems appear during next week I'll probably make 0.3 final release quite soon. Known issue: - NAT-T only supports tunnel mode, no transport mode. Please test and report any bugs/problems! Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Michal L. <mi...@lo...> - 2004-03-19 14:21:09
|
On Fri, 19 Mar 2004, Heiko Hund wrote: > I thought I'd report it here anyway and ask if you can do something about it, > maybe using some wicked auto(conf|make) statement. If not and only my setup > is to blame, it might still be helpful for someone with the same problem. > > My setup: > Debian testing/unstable > linux-kernel-headers = 2.5.999-test7-bk-15 > kernel-headers = 2.4.25-1-686 > kernel-image = 2.4.25-1-686 > gcc version 3.3.3 (Debian) > libc6-dev = 2.3.2.ds1-11 Well, thanks for the report. But while it can't be reproduced on my system I'm afraid I'm unable to do anything about it... Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Heiko H. <he...@is...> - 2004-03-19 13:58:45
|
Hello developers, I got this error when compiling racoon today: gcc -g -O2 -I./../include-glibc -I../include-glibc -include ./../include-glibc/glibc-bugs.h -DINET6 -DIPV6_INRIA_VERSION -I./missing -DHAVE_CONFIG_H -I./../include-glibc -I../include-glibc -include ./../include-glibc/glibc-bugs.h -DINET6 -DIPV6_INRIA_VERSION -I./missing -Wall -Wmissing-prototypes -Wmissing-declarations -DYIPS_DEBUG -DIPSEC -I. -I. -DSYSCONFDIR=\"/usr/local/etc\" -Wno-sign-compare -DYY_NO_UNPUT -I./../libipsec -c session.c In file included from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:326, from /usr/include/sys/wait.h:30, from session.c:39: /usr/include/asm/sigcontext.h:79: error: parse error before '*' token /usr/include/asm/sigcontext.h:82: error: parse error before '}' token make: *** [session.o] Error 1 The one thing that took me a while to accept was, that it compiled without any problems this morning. After some research I discovered that an inconsistency between the glibc kernel headers (in /usr/include/) and the ones from the kernel installed (in /lib/modules/`uname -r`/build/include/) in asm/sigcontext.h:79 causes the error. /usr/include/asm/sigcontext.h:79: struct _fpstate __user * fpstate; /lib/modules/`uname -r`/build/include/asm/sigcontext.h:79: struct _fpstate * fpstate; After deleting '__user' from the concerned line it worked like a charm again. I don't know what happened on my system, so that the error suddenly occured, but it could have to do with some package updates I made during the day. So far my conclusion is, that Debian is to blame, mostly because I can't think of anybody else. =) I thought I'd report it here anyway and ask if you can do something about it, maybe using some wicked auto(conf|make) statement. If not and only my setup is to blame, it might still be helpful for someone with the same problem. My setup: Debian testing/unstable linux-kernel-headers = 2.5.999-test7-bk-15 kernel-headers = 2.4.25-1-686 kernel-image = 2.4.25-1-686 gcc version 3.3.3 (Debian) libc6-dev = 2.3.2.ds1-11 config.log attached Greetings Heiko |
From: Michal L. <mi...@lo...> - 2004-03-19 12:15:57
|
On Fri, 19 Mar 2004 ac...@bl... wrote: > Hi, > > Thanks for replying to my message for help! > > I tried your suggestion of adding in AES, but still no luck. However, > the new error message was enough to help me track down more information. > I think that 'trns_id' stands for 'transform ID' - which seems to be > defined in the code in ipsec_doi.h. > > It would seem from here that: > > transform ID 3 - 3DES > transform ID 11 - NULL > transform ID 12 - AES > > ... after adding AES in I get: > > trns_id mismatched: my:3 peer:11 > trns_id mismatched: my:12 peer:11 Please check out the current CVS version. I added the number->string conversion for these values. > racoon doesn't seem to like 'encryption_algorithm null;' even though it > is declared in algorithm.c Try 'null_enc' instead of 'null'. I have added 'null' as an alias for 'null_enc' for 0.3rc3 Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: <ac...@bl...> - 2004-03-19 11:48:18
|
Hi, Thanks for replying to my message for help! I tried your suggestion of adding in AES, but still no luck. However, = the new error message was enough to help me track down more information. = I think that 'trns_id' stands for 'transform ID' - which seems to be = defined in the code in ipsec_doi.h. It would seem from here that: transform ID 3 - 3DES transform ID 11 - NULL transform ID 12 - AES ... after adding AES in I get: trns_id mismatched: my:3 peer:11 trns_id mismatched: my:12 peer:11 which would seem to indicate (if I'm correct) that Windows is only = offering NULL as the transformation. This is backed up by the logs when = I enable debugging, where I get: peer's single bundle: (trns_id=3DNULL encklen=3D0 authtype=3Dhmac-sha) (trns_id=3DNULL encklen=3D0 authtype=3Dhmac-md5) racoon doesn't seem to like 'encryption_algorithm null;' even though it = is declared in algorithm.c Looking at the Windows IPsec Security policies, 'Client (Respond only)' = is set to use 3DES, SHA1 then 3DES, MD5, then DES, SHA1 then DES,MD5 for = esp. It turns out that the NAT-T problem was a red herring. I used 'Windows = update' in order to apply the 818043 Microsoft patch and I let it = upgrade a couple of other things at the same time (Particularly, to W2k = service pack 4). It so happened that I turned on NAT-T in Racoon at the = same time. I wonder if the 'update' to windows has 'changed' IPsec to prefer not to = use encryption?!?! Does Racoon support null encryption? I have 'Null algorithms' enabled in = the kernel config, but I get a parse error when changing '3des' to = 'null' in racoon.conf. This would at least allow me to see how NAT-T = does its stuff. Hmmm... I wonder what has changed in Windows - it would appear that the = problem is at the Windows end :-( Colin |
From: Michal L. <mi...@lo...> - 2004-03-19 10:11:31
|
On Thu, 18 Mar 2004 ac...@bl... wrote: > 2004-03-18 17:23:26: ERROR: trns_id mismatched: my:3 peer:11 > 2004-03-18 17:23:26: ERROR: trns_id mismatched: my:3 peer:11 > 2004-03-18 17:23:26: ERROR: not matched > 2004-03-18 17:23:26: ERROR: not matched > 2004-03-18 17:23:26: ERROR: no suitable policy found. > 2004-03-18 17:23:26: ERROR: failed to pre-process packet. Hmm, looks like the peer offers AES encryption but your end accepts only 3des. > { > isakmp 192.168.1.119[500]; > isakmp_natt 192.168.1.119[4500]; > } > > remote anonymous { > exchange_mode main,base; > passive on; > certificate_type x509 "server.crt" "server.key"; > peers_certfile "windowsMachine.crt"; > > my_identifier user_fqdn "co...@my...spam"; > peers_identifier user_fqdn "co...@my...spam"; > verify_cert on; > nat_traversal on; > > proposal { > encryption_algorithm 3des; Add ', aes' here... > hash_algorithm md5; > authentication_method rsasig; > dh_group 2; > } > > proposal_check obey; > generate_policy off; > > } > > sainfo anonymous { > lifetime time 28800 sec; > encryption_algorithm 3des ; ... and here. > authentication_algorithm hmac_md5; > compression_algorithm deflate ; > } > > ... and am loading the security policy database with the following: > > spdadd 192.168.1.119 0.0.0.0/0[0] any -P out ipsec esp/transport//require; > spdadd 0.0.0.0/0[0] 192.168.1.119 any -P in ipsec esp/transport//require; > > > If I disable the > isakmp_natt 192.168.1.119[4500]; > line then the connection works Hmm, strange... This only option shouldn't have any influence on the proposals... > Do I need to have an extra spd entry for the udp NAT data? I notice from > looking through the code that 'setkey' contains options such as > 'esp-udp' - I'm not sure if I need to enable anything there. I tried a > couple of combinations but didn't get the entries in the correct format > - setkey complained of missing parameters. It isn't needed. The esp-udp is only for debugging. > It appears from what I can find on Google that Win2K L2TP only supports > ipsec in transport mode, but racoon only supports NAT-T in tunnel mode. > I get a mismatch when configuring racoon to use tunnel mode which would > appear to back this up. Right, racoon doesn't yet support UDP/transport mode because it doesn't understand NAT-OA payload. > If someone could help answer my query that would be great! I'm even > wondering if perhaps what I'm trying to do won't work at all if nat-t > transport mode is not supported by racoon. Probably not. But as I'm getting these requests I'll likely do something in this direction. But not now, sorry... Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: <mr...@mr...> - 2004-03-19 09:26:50
|
Derek Atkins <de...@ih...> writes: > Can you test something? Can you turn off NAT completely on both > machines? I bet your north gw, which is both an ipsec box and nat gw, > is performing NAT at the wrong time. IIRC your south gw is not > performing NAT. I disabled NAT on the north gateway, and the TCP connections sprang to life. Now the question (at least in my mind) is whether this is a configuration error or a bug. --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: <mr...@mr...> - 2004-03-19 09:12:36
|
Derek Atkins <de...@ih...> writes: > mr...@mr... (M=E5ns Rullg=E5rd) writes: > >>> Well, I was just talking about for a short test... Not permanently. >> >> Naturally, but then there will be no network behind the gateway to >> tunnel traffic from. > > Huh? Sure there would! The tunneled network would exist behind the > gateway! You don't have to enable NAT in order to tunnel packets! Oh, no I see what you mean. I'll try that and see what happens. --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: Michal L. <mi...@lo...> - 2004-03-19 07:23:59
|
On Thu, 18 Mar 2004, James Couzens wrote: > On Wed, 2004-03-17 at 23:09, Aidas Kasparas wrote: > > > Could you please find the point where racoon segfaults and backtrace > > from that point. Without this information is imposible to help you. > > > > Another thing to check out -- could you confirm that racoon and openssl > > library are compiled for 586 or less capable CPU. > > I've just confirmed openssl 0.9.7d is compiled with -m486 and > recompiled. I'm just heading off to work, attached is the debug output > from the crash. Please disable optimization when compiling ipsec-tools: # CFLAGS=-g ./configure && make Allow creation of coredumps: # ulimit -c unlimited Run racoon and let it crash. It should end up with a file 'core' in your working directory. Then run GDB and inspect it: # gdb racoon core [...] (gdb) bt<Enter> [here it lists something ... send it our way ;-)] If possible gzip the racoon binary and the core file and send it to my address (not to the list because it will be too big message). Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Derek A. <de...@ih...> - 2004-03-19 05:23:13
|
mr...@mr... (M=E5ns Rullg=E5rd) writes: >> Well, I was just talking about for a short test... Not permanently. > > Naturally, but then there will be no network behind the gateway to > tunnel traffic from. Huh? Sure there would! The tunneled network would exist behind the gateway! You don't have to enable NAT in order to tunnel packets! -derek --=20 Derek Atkins 617-623-3745 de...@ih... www.ihtfp.com Computer and Internet Security Consultant |
From: <mr...@mr...> - 2004-03-19 02:36:32
|
Derek Atkins <de...@ih...> writes: >>> Indeed, it does. I'm surprised that UDP works but TCP does not. That >>> is indeed strange. The port-munging should be the same either way. I >>> wonder if one of the boxes is performing NAT into/out-of the ipsec >>> tunnel? >>> >>> Can you test something? Can you turn off NAT completely on both >>> machines? >> >> Not easily. These are home networks so I have only a single IP >> address at each end. > > Well, I was just talking about for a short test... Not permanently. Naturally, but then there will be no network behind the gateway to tunnel traffic from. >>> I bet your north gw, which is both an ipsec box and nat gw, is >>> performing NAT at the wrong time. >> >> Do you mean it's masquerading packets going into the tunnel? The >> firewall rule says "-A POSTROUTING -d ! 192.168.17.0/255.255.255.0 >> -o eth1 -j MASQUERADE", so it should be leaving those alone, unless >> I'm mistaken. > > That looks ok, but I'd definitely like to see what happens if you > turn off all NAT at both sides. Right now I don't have physical access to the machines, so I'd rather not change something I can't undo remotely if it screws up. > Anyways, I've sort of timed-out on my available time for free tech > support. I wish you luck. Please let the list know if you finally > track down a working solution. Thanks for the help anyway. I'll post any solution I come up with. --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: Derek A. <de...@ih...> - 2004-03-19 02:25:30
|
mr...@mr... (M=E5ns Rullg=E5rd) writes: >> I presume you mean "initiate the TCP connection from either end". >> The "tunnel" must be initiated from the south. ;) > > So it won't work even if the south NAT box forwards UDP port 500 and > ESP/AH to the right place? I guess I can find out for myself. It may work... but be careful of IP Address changes externally. >> Indeed, it does. I'm surprised that UDP works but TCP does not. That >> is indeed strange. The port-munging should be the same either way. I >> wonder if one of the boxes is performing NAT into/out-of the ipsec >> tunnel? >> >> Can you test something? Can you turn off NAT completely on both >> machines? > > Not easily. These are home networks so I have only a single IP > address at each end. Well, I was just talking about for a short test... Not permanently. >> I bet your north gw, which is both an ipsec box and nat gw, is >> performing NAT at the wrong time. > > Do you mean it's masquerading packets going into the tunnel? The > firewall rule says "-A POSTROUTING -d ! 192.168.17.0/255.255.255.0 > -o eth1 -j MASQUERADE", so it should be leaving those alone, unless > I'm mistaken. That looks ok, but I'd definitely like to see what happens if you turn off all NAT at both sides. Anyways, I've sort of timed-out on my available time for free tech support. I wish you luck. Please let the list know if you finally track down a working solution. Good Luck, > M=E5ns Rullg=E5rd > mr...@mr... -derek --=20 Derek Atkins 617-623-3745 de...@ih... www.ihtfp.com Computer and Internet Security Consultant |
From: <mr...@mr...> - 2004-03-19 02:19:17
|
Derek Atkins <de...@ih...> writes: > mr...@mr... (M=E5ns Rullg=E5rd) writes: > >> Yes, it is. The south end forwards things to the ipsec machine so it >> should be possible to initiate the tunnel from either end. > > I presume you mean "initiate the TCP connection from either end". > The "tunnel" must be initiated from the south. ;) So it won't work even if the south NAT box forwards UDP port 500 and ESP/AH to the right place? I guess I can find out for myself. >> I traced with ethereal what was happening on the inside of the >> northern net. The results are strange, at least to me >> (192.168.42.0/24 is north): >> >> 0.000000 192.168.42.2 -> 192.168.17.14 TCP 2701 > 22 [SYN] >> Seq=3D1996231113 Ack=3D0 Win=3D5840 Len=3D0 >> 0.020772 192.168.17.14 -> 192.168.42.2 TCP 50 > 2701 [SYN, ACK] >> Seq=3D1475598948 Ack=3D1996231114 Win=3D5792 Len=3D0 >> 0.020879 192.168.42.2 -> 192.168.17.14 TCP 2701 > 50 [RST] >> Seq=3D1996231114 Ack=3D0 Win=3D0 Len=3D0 >> 2.999113 192.168.42.2 -> 192.168.17.14 TCP 2701 > 22 [SYN] >> Seq=3D1996231113 Ack=3D0 Win=3D5840 Len=3D0 >> 3.020360 192.168.17.14 -> 192.168.42.2 TCP 50 > 2701 [SYN, ACK] >> Seq=3D1475598948 Ack=3D1996231114 Win=3D5792 Len=3D0 >> 3.020479 192.168.42.2 -> 192.168.17.14 TCP 2701 > 50 [RST] >> Seq=3D1996231114 Ack=3D0 Win=3D0 Len=3D0 >> >> Capturing on the south side at the same time gives this: >> >> 0.000000 192.168.42.2 -> 192.168.17.14 TCP 2713 > 22 [SYN] >> Seq=3D2430748000 Ack=3D0 Win=3D5840 Len=3D0 >> 0.000063 192.168.17.14 -> 192.168.42.2 TCP 22 > 2713 [SYN, ACK] >> Seq=3D1914139168 Ack=3D2430748001 Win=3D5792 Len=3D0 >> >> To me it looks like something is munging the tcp port numbers. > > Indeed, it does. I'm surprised that UDP works but TCP does not. That > is indeed strange. The port-munging should be the same either way. I > wonder if one of the boxes is performing NAT into/out-of the ipsec > tunnel? > > Can you test something? Can you turn off NAT completely on both > machines? Not easily. These are home networks so I have only a single IP address at each end. > I bet your north gw, which is both an ipsec box and nat gw, is > performing NAT at the wrong time. Do you mean it's masquerading packets going into the tunnel? The firewall rule says "-A POSTROUTING -d ! 192.168.17.0/255.255.255.0 -o eth1 -j MASQUERADE", so it should be leaving those alone, unless I'm mistaken. --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: Derek A. <de...@ih...> - 2004-03-18 23:13:26
|
mr...@mr... (M=E5ns Rullg=E5rd) writes: > Yes, it is. The south end forwards things to the ipsec machine so it > should be possible to initiate the tunnel from either end. I presume you mean "initiate the TCP connection from either end". The "tunnel" must be initiated from the south. ;) > I traced with ethereal what was happening on the inside of the > northern net. The results are strange, at least to me > (192.168.42.0/24 is north): > > 0.000000 192.168.42.2 -> 192.168.17.14 TCP 2701 > 22 [SYN] > Seq=3D1996231113 Ack=3D0 Win=3D5840 Len=3D0 > 0.020772 192.168.17.14 -> 192.168.42.2 TCP 50 > 2701 [SYN, ACK] > Seq=3D1475598948 Ack=3D1996231114 Win=3D5792 Len=3D0 > 0.020879 192.168.42.2 -> 192.168.17.14 TCP 2701 > 50 [RST] > Seq=3D1996231114 Ack=3D0 Win=3D0 Len=3D0 > 2.999113 192.168.42.2 -> 192.168.17.14 TCP 2701 > 22 [SYN] > Seq=3D1996231113 Ack=3D0 Win=3D5840 Len=3D0 > 3.020360 192.168.17.14 -> 192.168.42.2 TCP 50 > 2701 [SYN, ACK] > Seq=3D1475598948 Ack=3D1996231114 Win=3D5792 Len=3D0 > 3.020479 192.168.42.2 -> 192.168.17.14 TCP 2701 > 50 [RST] > Seq=3D1996231114 Ack=3D0 Win=3D0 Len=3D0 > > Capturing on the south side at the same time gives this: > > 0.000000 192.168.42.2 -> 192.168.17.14 TCP 2713 > 22 [SYN] > Seq=3D2430748000 Ack=3D0 Win=3D5840 Len=3D0 > 0.000063 192.168.17.14 -> 192.168.42.2 TCP 22 > 2713 [SYN, ACK] > Seq=3D1914139168 Ack=3D2430748001 Win=3D5792 Len=3D0 > > To me it looks like something is munging the tcp port numbers. Indeed, it does. I'm surprised that UDP works but TCP does not. That is indeed strange. The port-munging should be the same either way. I wonder if one of the boxes is performing NAT into/out-of the ipsec tunnel? Can you test something? Can you turn off NAT completely on both machines? I bet your north gw, which is both an ipsec box and nat gw, is performing NAT at the wrong time. IIRC your south gw is not performing NAT. > M=E5ns Rullg=E5rd > mr...@mr... -derek --=20 Derek Atkins 617-623-3745 de...@ih... www.ihtfp.com Computer and Internet Security Consultant |
From: <mr...@mr...> - 2004-03-18 22:34:01
|
Derek Atkins <de...@ih...> writes: > mr...@mr... (M=E5ns Rullg=E5rd) writes: > >> OK, now it's working somewhat. The only thing that doesn't work is >> TCP connections from north to south. Everything else is OK. UDP and >> ICMP work in both directions, and ssh from south to north works. Is >> this something obvious? > > Firewall rules? Disabled for debugging. > How do you know they wont work from north -> south? Connections time out. > I presume the tunnel is already up by the time you're initiating the > southbound TCP connection? Yes, it is. The south end forwards things to the ipsec machine so it should be possible to initiate the tunnel from either end. I traced with ethereal what was happening on the inside of the northern net. The results are strange, at least to me (192.168.42.0/24 is north): 0.000000 192.168.42.2 -> 192.168.17.14 TCP 2701 > 22 [SYN] Seq=3D1996231113 Ack=3D0 Win=3D5840 Len=3D0 0.020772 192.168.17.14 -> 192.168.42.2 TCP 50 > 2701 [SYN, ACK] Seq=3D1475598948 Ack=3D1996231114 Win=3D5792 Len=3D0 0.020879 192.168.42.2 -> 192.168.17.14 TCP 2701 > 50 [RST] Seq=3D1996231114 Ack=3D0 Win=3D0 Len=3D0 2.999113 192.168.42.2 -> 192.168.17.14 TCP 2701 > 22 [SYN] Seq=3D1996231113 Ack=3D0 Win=3D5840 Len=3D0 3.020360 192.168.17.14 -> 192.168.42.2 TCP 50 > 2701 [SYN, ACK] Seq=3D1475598948 Ack=3D1996231114 Win=3D5792 Len=3D0 3.020479 192.168.42.2 -> 192.168.17.14 TCP 2701 > 50 [RST] Seq=3D1996231114 Ack=3D0 Win=3D0 Len=3D0 Capturing on the south side at the same time gives this: 0.000000 192.168.42.2 -> 192.168.17.14 TCP 2713 > 22 [SYN] Seq=3D2430748000 Ack=3D0 Win=3D5840 Len=3D0 0.000063 192.168.17.14 -> 192.168.42.2 TCP 22 > 2713 [SYN, ACK] Seq=3D1914139168 Ack=3D2430748001 Win=3D5792 Len=3D0 To me it looks like something is munging the tcp port numbers. --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: Derek A. <de...@ih...> - 2004-03-18 22:18:40
|
mr...@mr... (M=E5ns Rullg=E5rd) writes: > OK, now it's working somewhat. The only thing that doesn't work is > TCP connections from north to south. Everything else is OK. UDP and > ICMP work in both directions, and ssh from south to north works. Is > this something obvious? Firewall rules? How do you know they wont work from north -> south? I presume the tunnel is already up by the time you're initiating the southbound TCP connection? -derek --=20 Derek Atkins 617-623-3745 de...@ih... www.ihtfp.com Computer and Internet Security Consultant |
From: <mr...@mr...> - 2004-03-18 22:14:10
|
Derek Atkins <de...@ih...> writes: > mr...@mr... (M=E5ns Rullg=E5rd) writes: > >> I'm still a bit fuzzy about how the south end will know that the >> external IP in the tunnel specification is equivalent in some sense to >> it's internal IP. I guess I'll just keep trying all possible >> permutations until I find the one that works. > > This is why the north side needs an anonymous configuration. The south > side's "external" address is 192.168.2.2, and it should configure itself > that way. The north side, however, must use it's REAL external address. OK, now it's working somewhat. The only thing that doesn't work is TCP connections from north to south. Everything else is OK. UDP and ICMP work in both directions, and ssh from south to north works. Is this something obvious? --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: Derek A. <de...@ih...> - 2004-03-18 21:00:54
|
mr...@mr... (M=E5ns Rullg=E5rd) writes: > I'm still a bit fuzzy about how the south end will know that the > external IP in the tunnel specification is equivalent in some sense to > it's internal IP. I guess I'll just keep trying all possible > permutations until I find the one that works. This is why the north side needs an anonymous configuration. The south side's "external" address is 192.168.2.2, and it should configure itself that way. The north side, however, must use it's REAL external address. E.g.: (int1) [ gw1 ] (ext1) --- (ext2) [nat] (int2) --- (int2.1) [ gw2 ] (int2.2) Ignore the fact that int1/ext1 are on different networks (or that int1 is a "NAT" address). It doesn't matter. gw1 should be configured with an anonymous configuration. gw2 must be configured with int2.1 and ext1 as the tunnel endpoints. > M=E5ns Rullg=E5rd > mr...@mr... -derek --=20 Derek Atkins 617-623-3745 de...@ih... www.ihtfp.com Computer and Internet Security Consultant |
From: <mr...@mr...> - 2004-03-18 20:47:37
|
Derek Atkins <de...@ih...> writes: > mr...@mr... (M=E5ns Rullg=E5rd) writes: > >> That's acceptable. The problem is that I can't even make it try. >> How should the south end of the tunnel be specified? If I use the >> externally visible address, the south machine ignores it, and if I >> specify the internal IP the north end gets confused. > > What do you mean? You need to configure the tunnel with both addresses. > You need the internal address in the policy, and the external address > in the tunnel config. > > [internal] [internal] / [external]-[external] > > I'll also note that you probably want an anonymous config on the > north side. I'm still a bit fuzzy about how the south end will know that the external IP in the tunnel specification is equivalent in some sense to it's internal IP. I guess I'll just keep trying all possible permutations until I find the one that works. --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: Derek A. <de...@ih...> - 2004-03-18 20:20:52
|
mr...@mr... (M=E5ns Rullg=E5rd) writes: > That's acceptable. The problem is that I can't even make it try. > How should the south end of the tunnel be specified? If I use the > externally visible address, the south machine ignores it, and if I > specify the internal IP the north end gets confused. What do you mean? You need to configure the tunnel with both addresses. You need the internal address in the policy, and the external address in the tunnel config. [internal] [internal] / [external]-[external] I'll also note that you probably want an anonymous config on the north side. -derek --=20 Derek Atkins 617-623-3745 de...@ih... www.ihtfp.com Computer and Internet Security Consultant |
From: <mr...@mr...> - 2004-03-18 20:12:19
|
Derek Atkins <de...@ih...> writes: >>> At least one end requires a REAL ip address.. >> >> The "north" side has a real address. > > Indeed, it does. I missed that. Appologies... > > BUT.. this means the south side MUST initiate the tunnel. The north > side cannot initiate. That's acceptable. The problem is that I can't even make it try. How should the south end of the tunnel be specified? If I use the externally visible address, the south machine ignores it, and if I specify the internal IP the north end gets confused. --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: Derek A. <de...@ih...> - 2004-03-18 19:45:23
|
mr...@mr... (M=E5ns Rullg=E5rd) writes: >>>>> 192.168.1.0/24 >>>>> | >>>>> +-------------+ >>>>> | 192.168.1.1 | >>>>> | 193.0.0.1 | >>>>> +-------------+ >>>>> | >>>>> Internet >>>> >>> Internet >>> | >>> +-------------+ >>> | 194.0.0.1 | Cheap (DLink) ADSL router without ipsec >>> | 192.168.2.1 | NAT happens here >>> +-------------+ >>> | >>> +-------------+ >>> | 192.168.2.2 | Linux 2.6 host with IPSec >>> +-------------+ >>> | >>> 192.168.2.0/24 >>> >>> I've managed to get a transport configuration working in one >>> direction. 192.168.2.2 can ping 193.0.0.1 and get replies. For some >>> reason it doesn't work in the opposite direction. Again, NAT traversal >>> in racoon.conf has no effect, except that when set to "force" the ESP >>> packets are encapsulated in UDP. >> >> At least one end requires a REAL ip address.. > > The "north" side has a real address. Indeed, it does. I missed that. Appologies... BUT.. this means the south side MUST initiate the tunnel. The north side cannot initiate. >> You cannot NAT both ends of the connection. Well, you CAN, but one >> end needs full-time port-forwarding at the NAT box so that incoming >> IKE packets get forwarded to the gateway. > > That's easily done too. > > --=20 > M=E5ns Rullg=E5rd > mr...@mr... -derek --=20 Derek Atkins 617-623-3745 de...@ih... www.ihtfp.com Computer and Internet Security Consultant |
From: <mr...@mr...> - 2004-03-18 19:37:06
|
Derek Atkins <de...@ih...> writes: > mr...@kt... (M=E5ns Rullg=E5rd) writes: > >> Michal Ludvig <mi...@lo...> writes: >> >>> On Wed, 17 Mar 2004, [iso-8859-1] M?ns Rullg?rd wrote: >>> >>>> Before you flame me, I am aware that this isn't a development related >>>> question, but I can't find a better place to ask, and I see other >>>> configuration related questions in the archive. >>> >>> It's OK. There is no "user" mailing list for ipsec-tools. >>> >>>> We are trying to set up an ipsec tunnel between two networks, both >>>> residing behind NAT. The situation is like this: >>>> >>>> 192.168.1.0/24 >>>> | >>>> +-------------+ >>>> | 192.168.1.1 | >>>> | 193.0.0.1 | >>>> +-------------+ >>>> | >>>> Internet >>> >>> Hmm, what is your problem? This is a "standard" situation - read the do= cs, >>> sample config files and mail archive for hints. >> >> Sorry, I slipped on the send button before the figure was completed, >> and the real message seems to have gotten lost somewhere. The rest of >> the figure looks like this: >> >> Internet >> | >> +-------------+ >> | 194.0.0.1 | Cheap (DLink) ADSL router without ipsec >> | 192.168.2.1 | NAT happens here >> +-------------+ >> | >> +-------------+ >> | 192.168.2.2 | Linux 2.6 host with IPSec >> +-------------+ >> | >> 192.168.2.0/24 >> >> All machines on the 192.168.2.0/24 net have 192.168.2.2 as default >> gateway. 192.168.2.2 should tunnel traffic to 192.168.1.0/24 over >> ipsec through the real gateway, 192.168.2.1. The question is how to >> specify the tunnel endpoints, since the ends have different views of >> the address of the "south" end. I have tried enabling NAT traversal >> in racoon.conf but it doesn't seem to make a difference. >> >> I've managed to get a transport configuration working in one >> direction. 192.168.2.2 can ping 193.0.0.1 and get replies. For some >> reason it doesn't work in the opposite direction. Again, NAT traversal >> in racoon.conf has no effect, except that when set to "force" the ESP >> packets are encapsulated in UDP. > > At least one end requires a REAL ip address.. The "north" side has a real address. > You cannot NAT both ends of the connection. Well, you CAN, but one > end needs full-time port-forwarding at the NAT box so that incoming > IKE packets get forwarded to the gateway. That's easily done too. --=20 M=E5ns Rullg=E5rd mr...@mr... |