Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Aug 2011 14:39:12 -0400
From:      Mike Tancsa <mike@sentex.net>
To:        jhall@socket.net
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Racoon to Cisco ASA 5505
Message-ID:  <4E5696D0.3000205@sentex.net>
In-Reply-To: <20110825155205.A0D131065670@hub.freebsd.org>
References:  <20110823232242.B78A5106566B@hub.freebsd.org>	<4E545899.6090800@sentex.net> <20110825155205.A0D131065670@hub.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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/



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