Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Jul 2002 11:34:47 -0500
From:      "Matthew Grooms" <mgrooms@seton.org>
To:        <freebsd-questions@FreeBSD.ORG>, <freebsd-security@FreeBSD.ORG>
Subject:   Re: vpn1/fw1 NG to ipsec/racoon troubles, help please ...
Message-ID:  <sd452863.077@aus-gwia.aus.dcnhs.org>

next in thread | raw e-mail | index | archive | help
Dru,

     I did some checking this morning with tcpdump ( as you suggested )
and here is the info. When the ipsec session is initiated from the
inside of my home network ( freebsd->vpn1 ), nothing happens. I assume
since the vpn1 box does not even find this traffic interesting. Here is
the log output from the respective endpoints.

FreeBSD side ...

tcpdump: listening on ed0
11:47:42.628327 66.90.146.202 > 65.118.63.252: 10.22.200.1.500 >
10.21.2.253.500: isakmp: phase 1 I ident: [|sa] (ipip)
11:48:02.818812 66.90.146.202 > 65.118.63.252: 10.22.200.1.500 >
10.21.2.253.500: isakmp: phase 1 I ident: [|sa] (ipip)
11:48:22.109505 66.90.146.202 > 65.118.63.252: 10.22.200.1.500 >
10.21.2.253.500: isakmp: phase 1 I ident: [|sa] (ipip)
11:48:42.119398 66.90.146.202 > 65.118.63.252: 10.22.200.1.500 >
10.21.2.253.500: isakmp: phase 1 I ident: [|sa] (ipip)
11:49:02.130134 66.90.146.202 > 65.118.63.252: 10.22.200.1.500 >
10.21.2.253.500: isakmp: phase 1 I ident: [|sa] (ipip)
11:49:22.150308 66.90.146.202 > 65.118.63.252: 10.22.200.1.500 >
10.21.2.253.500: isakmp: phase 1 I ident: [|sa] (ipip)
^C
340 packets received by filter
0 packets dropped by kernel

Linux / VPN1 side ...

tcpdump: listening on eth0
11:23:35.854538 66.90.146.202 > 65.118.63.252: 10.22.200.1.isakmp >
10.21.2.253.isakmp: isakmp: phase 1 I ident: [|sa] (ipip)
11:23:35.855482 65.118.63.252 > 66.90.146.202: icmp: 65.118.63.252
protocol 4 unreachable [tos 0xc0]
11:23:56.020501 66.90.146.202 > 65.118.63.252: 10.22.200.1.isakmp >
10.21.2.253.isakmp: isakmp: phase 1 I ident: [|sa] (ipip)
11:23:56.020576 65.118.63.252 > 66.90.146.202: icmp: 65.118.63.252
protocol 4 unreachable [tos 0xc0]
11:24:15.307853 66.90.146.202 > 65.118.63.252: 10.22.200.1.isakmp >
10.21.2.253.isakmp: isakmp: phase 1 I ident: [|sa] (ipip)
11:24:15.307931 65.118.63.252 > 66.90.146.202: icmp: 65.118.63.252
protocol 4 unreachable [tos 0xc0]
11:24:35.361459 66.90.146.202 > 65.118.63.252: 10.22.200.1.isakmp >
10.21.2.253.isakmp: isakmp: phase 1 I ident: [|sa] (ipip)
11:24:35.361542 65.118.63.252 > 66.90.146.202: icmp: 65.118.63.252
protocol 4 unreachable [tos 0xc0]
11:24:55.376960 66.90.146.202 > 65.118.63.252: 10.22.200.1.isakmp >
10.21.2.253.isakmp: isakmp: phase 1 I ident: [|sa] (ipip)
11:24:55.377046 65.118.63.252 > 66.90.146.202: icmp: 65.118.63.252
protocol 4 unreachable [tos 0xc0]
11:25:15.357907 66.90.146.202 > 65.118.63.252: 10.22.200.1.isakmp >
10.21.2.253.isakmp: isakmp: phase 1 I ident: [|sa] (ipip)
11:25:15.357962 65.118.63.252 > 66.90.146.202: icmp: 65.118.63.252
protocol 4 unreachable [tos 0xc0]

1073807371 packets received by filter
1 packets dropped by kernel

The really interesting part for me is when the ipsec session is
initiated by the vpn1 side. Racoon accepts the traffic and responds.
Here is the log output from the respective sides for this scenario.

FreeBSD side ...

tcpdump: listening on ed0
11:53:29.269204 65.118.63.252.500 > 66.90.146.202.500: isakmp: phase 1 I
agg: [|sa] (DF)
11:53:29.381550 66.90.146.202.500 > 65.118.63.252.500: isakmp: phase 1 R
agg: [|sa]
11:53:29.462243 65.118.63.252.500 > 66.90.146.202.500: isakmp: phase 1 I
agg:
    (hash: len=16) (DF)
11:53:29.575229 65.118.63.252.500 > 66.90.146.202.500: isakmp: phase 1 I
agg:
    (hash: len=16) (DF)
11:53:29.670112 65.118.63.252.500 > 66.90.146.202.500: isakmp: phase 1 I
agg:
    (hash: len=16) (DF)
11:53:30.001215 65.118.63.252.500 > 66.90.146.202.500: isakmp: phase
2/others I oakley-quick[E]: [|hash] (DF)
11:53:32.001928 65.118.63.252.500 > 66.90.146.202.500: isakmp: phase
2/others I oakley-quick[E]: [|hash] (DF)
11:53:34.002585 65.118.63.252.500 > 66.90.146.202.500: isakmp: phase
2/others I oakley-quick[E]: [|hash] (DF)
^C
60 packets received by filter
0 packets dropped by kernel

Linux / VPN1 side ...

tcpdump: listening on eth0
11:29:22.374083 65.118.63.252.isakmp > 66.90.146.202.isakmp: isakmp:
phase 1 I agg: [|sa] (DF)
11:29:22.551798 66.90.146.202.isakmp > 65.118.63.252.isakmp: isakmp:
phase 1 R agg: [|sa]
11:29:22.569977 65.118.63.252.isakmp > 66.90.146.202.isakmp: isakmp:
phase 1 I agg:
    (hash: len=16) (DF)
11:29:22.677674 65.118.63.252.isakmp > 66.90.146.202.isakmp: isakmp:
phase 1 I agg:
    (hash: len=16) (DF)
11:29:22.777666 65.118.63.252.isakmp > 66.90.146.202.isakmp: isakmp:
phase 1 I agg:
    (hash: len=16) (DF)
11:29:23.106051 65.118.63.252.isakmp > 66.90.146.202.isakmp: isakmp:
phase 2/others I oakley-quick[E]: [|hash] (DF)
11:29:25.107675 65.118.63.252.isakmp > 66.90.146.202.isakmp: isakmp:
phase 2/others I oakley-quick[E]: [|hash] (DF)
11:29:27.107672 65.118.63.252.isakmp > 66.90.146.202.isakmp: isakmp:
phase 2/others I oakley-quick[E]: [|hash] (DF)

Here is my racoon.conf file ...

# $KAME: racoon.conf.in,v 1.18 2001/08/16 06:33:40 itojun Exp $

path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;
path certificate "/usr/local/etc/cert" ;
log debug2;

# "padding" defines some parameter of padding.  You should not touch
these.
padding
{
        maximum_length 20;      # maximum padding length.
        randomize off;          # enable randomize length.
        strict_check off;       # enable strict check.
        exclusive_tail off;     # extract last one octet.
}

# if no listen directive is specified, racoon will listen to all
# available interface addresses.
listen
{
        #isakmp ::1 [7000];
        #admin [7002];          # administrative's port by kmpstat.
        #strict_address;        # required all addresses must be bound.
}

# Specification of default various timer.
timer
{
        # These value can be changed per remote node.
        counter 5;              # maximum trying count to send.
        interval 20 sec;        # maximum interval to resend.
        persend 1;              # the number of packets per a send.

        # timer for waiting to complete each phase.
        phase1 30 sec;
        phase2 15 sec;
}

remote anonymous
{
        exchange_mode main,aggressive;
        nonce_size 16;
        lifetime time 10 min;   # sec,min,hour
        initial_contact on;
        support_mip6 on;
        proposal_check obey;    # obey, strict or claim

        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}

sainfo anonymous
{
        pfs_group 1;
        lifetime time 36000 sec;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5,hmac_sha1;
        compression_algorithm deflate;
}

Any ideas, insight ? This is driving me insane! :(

Matthew

>>> Dru <dlavigne6@cogeco.ca> 07/27/02 07:36 AM >>>

Have you tried a "tcpdump port 500" during Phase 1 negotiations? This
will
show the proposal exchange so you can see which parts aren't matching
up.
If that doesn't do it, send that output along with your racoon.conf
file.

Dru



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?sd452863.077>