From owner-freebsd-questions@FreeBSD.ORG Fri Aug 26 17:42:28 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 E7028106566C for ; Fri, 26 Aug 2011 17:42:28 +0000 (UTC) (envelope-from jhall@socket.net) Received: from mf1.socket.net (mf1g.socket.net [216.106.88.71]) by mx1.freebsd.org (Postfix) with ESMTP id AECE88FC22 for ; Fri, 26 Aug 2011 17:42:28 +0000 (UTC) Received: from localhost (unknown [216.106.88.17]) by mf1.socket.net (Postfix) with SMTP id 9A55545941; Fri, 26 Aug 2011 12:42:27 -0500 (CDT) To: mike@sentex.net From: jhall@socket.net X-Apparently-from: jhall@mail.socket.net X-Remote-Host: 174.34.27.163 User-Agent: Socket WebMail References: <20110823232242.B78A5106566B@hub.freebsd.org> <4E545899.6090800@sentex.net> <20110825155205.A0D131065670@hub.freebsd.org> <4E5696D0.3000205@sentex.net> Date: Fri, 26 Aug 2011 12:42:27 -0500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20110826174228.E7028106566C@hub.freebsd.org> Cc: freebsd-questions@freebsd.org Subject: Re: Re: Racoon to Cisco ASA 5505 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jhall@socket.net List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 17:42:29 -0000 I am seeing a couple of things that are concerning me. First, I am not seeing any traffic over the gif interface, except return traffic. For example if I ping from one of my sites (e.g. 10.129.30.0/24), I do not see any traffic on the gif interface. Second, I am seeing the following error message, "Header checksum: 0X0000 [incorrect, should be 0x8d84 (maybe caused by "IP Checksum Offload?)]. I spoke to our vendor this morning, an they are seeing encrypted packets flowing to them. However, I am not able to ping their devices until they initiate the traffic. This is when I am not seeing any traffic on the gif interface. Following are the policies I have defined for the 10.129.30 network. All policies are a copy of these with the correct networks added. 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/use; 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/use; spdadd 184.106.120.244/32 10.129.30.0/24 any -P in ipsec esp/tunnel/184.106.120.244-1.1.1.1/use; spdadd 10.129.30.0/24 184.106.120.244/32 any -P out ipsec esp/tunnel/184.106.120.244-1.1.1.1/use; Thank you for all your help. If you would like the results of the capture posted, please let me know and I will post them as well. Jay ---------------------------------------------------- >From : Mike Tancsa To : jhall@socket.net Subject : Re: Racoon to Cisco ASA 5505 Date : Thu, 25 Aug 2011 14:39:12 -0400 > 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/