Single IP host and IPsec tunnel mode experience
Crist J. Clark
crist.clark at attbi.com
Sun Apr 20 18:00:34 PDT 2003
On Sun, Apr 20, 2003 at 06:26:14PM -0500, Jacques A. Vidrine wrote:
> On Sun, Apr 20, 2003 at 10:20:53AM -0700, Lars Eggert wrote:
> > On 4/20/2003 9:55 AM, Jacques A. Vidrine wrote:
> > >On Wed, Apr 16, 2003 at 07:36:21AM -0500, Jacques A. Vidrine wrote:
> > >
> > >>On Tue, Apr 15, 2003 at 10:23:35PM -0700, Crist J. Clark wrote:
> > >>
> > >>>'uname -a'?
> > >>
> > >>The endpoints were both 4.7.
> > >>
> > >>
> > >>>I can't reproduce this on a 4.8 to 4.7 tunnel. On
> > >>>192.168.64.70,
> > >>>
> > >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P out
> > >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require;
> > >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P in
> > >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require;
> > >>>
> > >>>And on 192.168.64.20, the gateway to 10.0.0.0/24,
> > >>>
> > >>> spdadd 192.168.64.70/32 10.0.0.0/24 any -P in
> > >>> ipsec esp/tunnel/192.168.64.70-192.168.64.20/require;
> > >>> spdadd 10.0.0.0/24 192.168.64.70/32 any -P out
> > >>> ipsec esp/tunnel/192.168.64.20-192.168.64.70/require;
> > >>>
> > >>>Works fine.
> > >>
> > >>Hmm, yes, that appears to be exactly what I'm trying to do. Well,
> > >>that's heartening ... it means that there is likely some anomoly in my
> > >>environment that is hosing me. Now if only I can figure what it is :-)
> > >
> > >
> > >Oddly enough ... ESP works, AH does not.
> >
> > Are you going through a NAT box? (Sorry, haven't been following this
> > thread closely.) AH includes more of the IP header when computing the
> > crypto checksum (compared to ESP), if those fields get diddled by a NAT
> > box, the receiver will drop the packets because of bad crypto. One of
> > the netstat counters on the receiver will show this.
>
> No NAT.
>
> > If you need to authenticate, maybe try using ESP authentication?
>
> Yes, I believe that's what I tested. e.g.
>
> 223.223.223.223 117.117.117.117
> esp mode=tunnel spi=40396514(0x26866e25) reqid=0(0x00000000)
> E: 3des-cbc 4dafcf14 1e11dd81 4dafcf14 1e11dd81 4dafcf14 1e11dd81
> A: hmac-sha1 4dafcf14 1e11dd81 4dafcf14 1e11dd81 4dafcf14
> seq=0x00000000 replay=4 flags=0x00000000 state=mature
> created: Mar 2 07:52:31 2003 current: Mar 2 07:59:28 2003
> diff: 20(s) hard: 30(s) soft: 24(s)
> last: hard: 0(s) soft: 0(s)
> current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
> allocated: 0 hard: 0 soft: 0
> sadb_seq=2 pid=90010 refcnt=1
>
> I actually don't need AH ... I was using AH because it is easier to see
> what is going on.
It's easy to see what's going on in ESP when you define the encryption
algorithm as the NULL algorithm. Although I admit it took me a while
to figure out that NULL encryption in the setkey(8) syntax is the
"simple" algorithm.
In fact, would anyone object to,
Index: setkey.8
===================================================================
RCS file: /export/freebsd/ncvs/src/usr.sbin/setkey/setkey.8,v
retrieving revision 1.24
diff -u -r1.24 setkey.8
--- setkey.8 1 Jan 2003 18:49:03 -0000 1.24
+++ setkey.8 21 Apr 2003 00:41:50 -0000
@@ -563,7 +563,7 @@
algorithm keylen (bits) comment
des-cbc 64 esp-old: rfc1829, esp: rfc2405
3des-cbc 192 rfc2451
-simple 0 to 2048 rfc2410
+null-enc 0 to 2048 rfc2410
blowfish-cbc 40 to 448 rfc2451
cast128-cbc 40 to 128 rfc2451
des-deriv 64 ipsec-ciph-des-derived-01 (expired)
Index: token.l
===================================================================
RCS file: /export/freebsd/ncvs/src/usr.sbin/setkey/token.l,v
retrieving revision 1.5
diff -u -r1.5 token.l
--- token.l 11 Jun 2001 12:39:28 -0000 1.5
+++ token.l 21 Apr 2003 00:39:41 -0000
@@ -176,6 +176,7 @@
{hyphen}E { PREPROC; return(F_ENC); }
des-cbc { PREPROC; yylval.num = SADB_EALG_DESCBC; return(ALG_ENC); }
3des-cbc { PREPROC; yylval.num = SADB_EALG_3DESCBC; return(ALG_ENC); }
+null-enc { PREPROC; yylval.num = SADB_EALG_NULL; return(ALG_ENC); }
simple { PREPROC; yylval.num = SADB_EALG_NULL; return(ALG_ENC); }
blowfish-cbc { PREPROC; yylval.num = SADB_X_EALG_BLOWFISHCBC; return(ALG_ENC); }
cast128-cbc { PREPROC; yylval.num = SADB_X_EALG_CAST128CBC; return(ALG_ENC); }
The KAME stuff isn't on a vendor branch, not in a contrib/, and not
listed in MAINTAINERS. I guess it's OK to make minor changes/bug fixes
locally? I did file a PR with KAME for this too.
--
Crist J. Clark | cjclark at alum.mit.edu
| cjclark at jhu.edu
http://people.freebsd.org/~cjc/ | cjc at freebsd.org
More information about the freebsd-hackers
mailing list