From owner-freebsd-questions Mon Jul 29 9:35:20 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC2B737B400; Mon, 29 Jul 2002 09:35:04 -0700 (PDT) Received: from mail.seton.org (ftp.seton.org [207.193.126.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23AE643E3B; Mon, 29 Jul 2002 09:35:04 -0700 (PDT) (envelope-from mgrooms@seton.org) Received: from aus-gwia.aus.dcnhs.org (aus-gwia.aus.dcnhs.org [10.20.10.211]) by mail.seton.org (Postfix) with ESMTP id A87E6D0086; Mon, 29 Jul 2002 11:35:00 -0500 (CDT) Received: from AUS_SETON-MTA by aus-gwia.aus.dcnhs.org with Novell_GroupWise; Mon, 29 Jul 2002 11:34:59 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Mon, 29 Jul 2002 11:34:47 -0500 From: "Matthew Grooms" To: , Subject: Re: vpn1/fw1 NG to ipsec/racoon troubles, help please ... Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 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