From owner-freebsd-questions@FreeBSD.ORG Thu Aug 25 18:39:18 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF43C1065675 for ; Thu, 25 Aug 2011 18:39:18 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 728848FC16 for ; Thu, 25 Aug 2011 18:39:18 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p7PIdGGc062713; Thu, 25 Aug 2011 14:39:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E5696D0.3000205@sentex.net> Date: Thu, 25 Aug 2011 14:39:12 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: jhall@socket.net References: <20110823232242.B78A5106566B@hub.freebsd.org> <4E545899.6090800@sentex.net> <20110825155205.A0D131065670@hub.freebsd.org> In-Reply-To: <20110825155205.A0D131065670@hub.freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-questions@freebsd.org Subject: Re: Racoon to Cisco ASA 5505 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 18:39:18 -0000 On 8/25/2011 11:52 AM, jhall@socket.net wrote: >> I find wireshark helpful in these cases as it nicely decodes what >> options are being set. Your racoon conf is set to obey. Its possible >> they are proposing something different to you that you accept, where as >> what you are proposing might not be acceptable > > My vendor came back to me today and stated they found a configuration > error on their end. Their most recent message states the traffic I am > sending to them through the IPSec tunnel is not encrypted. What does your actual policy look like ? Is this the only ipsec config on your box ? If so, lets say your public IP is 1.1.1.1 and their ip is 184.106.120.244 try adding this to /etc/ipsec.conf spdadd 10.129.30.0/24 192.168.100.0/22 any -P out ipsec esp/tunnel/1.1.1.1-184.106.120.244/unique; spdadd 192.168.100.0/22 10.129.30.0/24 any -P in ipsec esp/tunnel/184.106.120.244-1.1.1.1/unique; do a setkey -F setkey -FP setkey -f /etc/ipsec.conf This is saying that you will create an ipsec policy between 2 networks. Your side behind 1.1.1.1 and their side behind 184.106.120.244. The policy states that packets with a source address of 10.129.30.0/24 destined to 192.168.100.0/22 will be encapsulated in an ipsec tunnel. Similarly, everything going the other direction - 192.168.100.0/22 going to 10.129.30.0/24... And *only* those packets. If you have a packet with a source address of 10.0.0.1 destined to 192.168.100.0/22, it will not be passed through the tunnel. > > Following is what they sent me from the ASA. > > Crypto map tag: rackmap, seq num: 201, local addr: 184.106.120.244 > > access-list 201 extended permit ip 192.168.100.0 255.255.252.0 > 10.129.30.0 255.255.255.0 > local ident (addr/mask/prot/port): (192.168.100.0/255.255.252.0/0/0) > remote ident (addr/mask/prot/port): (10.129.30.0/255.255.255.0/0/0) > current_peer: Jefferson_City You then need to make sure your key exchange settings agree. Ask them for that portion of the ASA's config. You are proposing exchange_mode main,base,aggressive; You are known to them by IP (my_identifier address) You should probably add peers_identifier address; and then make sure in your psk.txt file you have something like 184.106.120.244 the-secret-psk-you-agreed-on Also, make sure their side is expecting 3des and hmac is sha1 or md5 as you posted in your original config. On your public wan interface, do a tcpdump of the remote IP. e.g. if its em0, do tcpdump -ni em0 -s0 -w /tmp/186.pcap host 184.106.120.244 startup racoon with the debug flag and from your network, try and ping an IP in their private network from your private network e.g. ping -S 10.129.30.1 192.168.100.1 When testing ipsec, get in the habbit of ALWAYS specifying the source IP so that you know the packet you are generating falls within the policy you have specified. If things dont work, look at the racoon logs for clues as well as look at the pcap afterwards with -vvvv tcpdump -vvvv -nr /tmp/186.pcap port 500 if it worked and you get a ping response, look at the full traffic to make sure its ESP and that the contents are indeed encrypted. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/