[GRLUG] IPSec & CentOS

[Godwin]

Adam,

Do you have pfs=yes on openswan (does it look like my sample) and are
you initiating from there or is it the responder?  Googling "openswan
cisco pfs" I found a guy with similar problem.  He said changing the
Cisco to use DH group 2 solved it.  What are you using?

This is the dumb approach, but often times when initially configuring
a connection, I bounce openswan and dominoes mysteriously fall in
place.  ;-)

G-

http://lists.openswan.org/pipermail/users/2007-September/013176.html

On Fri, Jan 30, 2009 at 3:11 PM, Adam Tauno Williams
<awilliam at whitemice.org> wrote:
> On Fri, 2009-01-30 at 14:33 -0500, Godwin wrote:
>> Ah.  Just for comparison, these are the meaningful settings I have
>> connecting openswan to a cisco pix.  Disclaimer: I don't manage the
>> cisco side.
>
> :) Apparently nobody does.  There is *very* little information
> concerning an IOS setup, and much of it contradictory.
>
>> Once the SA is established with:  ipsec auto --up swan-to-cisco
>> you can check it with:  ipsec eroute  (if you have klips and  the
>> ipsec0 interface)
>
> I don't see an ipsec0 interface.  This will be created when phase 2
> completes? Or does it need to be created initially.
>
> updgate#show crypto isakmp sa
> dst             src             state          conn-id slot
> 216.120.174.238 216.120.174.237 QM_IDLE              1    0
>
> So phase 1 seems to complete.
>
> First problem seems to be in phase 2:
>
> [root at vpn log]# ipsec auto --up UsedPartsDepot
> 104 "UsedPartsDepot" #1: STATE_MAIN_I1: initiate
> 106 "UsedPartsDepot" #1: STATE_MAIN_I2: sent MI2, expecting MR2
> 003 "UsedPartsDepot" #1: received Vendor ID payload [Cisco-Unity]
> 003 "UsedPartsDepot" #1: received Vendor ID payload [Dead Peer
> Detection]
> 003 "UsedPartsDepot" #1: ignoring unknown Vendor ID payload
> [106b596919cac1753642b7ba8d9afc8c]
> 003 "UsedPartsDepot" #1: received Vendor ID payload [XAUTH]
> 108 "UsedPartsDepot" #1: STATE_MAIN_I3: sent MI3, expecting MR3
> 004 "UsedPartsDepot" #1: STATE_MAIN_I4: ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5
> group=modp1024}
> 117 "UsedPartsDepot" #2: STATE_QUICK_I1: initiate
> 010 "UsedPartsDepot" #2: STATE_QUICK_I1: retransmission; will wait 20s
> for response
> 010 "UsedPartsDepot" #2: STATE_QUICK_I1: retransmission; will wait 40s
> for response
> 031 "UsedPartsDepot" #2: max number of retransmissions (2) reached
> STATE_QUICK_I1.  No acceptable response to our first Quick Mode message:
> perhaps peer likes no proposal
> 000 "UsedPartsDepot" #2: starting keying attempt 2 of at most 3, but
> releasing whack
>
> .. on the Cisco side...
>
> 06:12:24: ISAKMP (0:1): atts are acceptable.
> 06:12:24: ISAKMP (0:1): IPSec policy invalidated proposal
> 06:12:24: ISAKMP (0:1): phase 2 SA policy not acceptable! (local LOCALIP
> remote REMOTEIP)
> 06:12:24: ISAKMP: set new node -1802271793 to QM_IDLE
>
>>   Is your SA staying up?  I remember the other side's admin having
>> trouble with that.  The kernel should establish a route automatically
>> on the CentOS side...
>> What does your "ifconfig -a" and "route -n" look like?
>
> [root at vpn log]# ifconfig -a
> eth0      Link encap:Ethernet  HWaddr 00:50:56:A8:58:16
>          inet addr:X.X.X.X   Mask:255.255.255.224
>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>          RX packets:89060 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:91118 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:13340132 (12.7 MiB)  TX bytes:14527014 (13.8 MiB)
>          Interrupt:177 Base address:0x1400
>
> eth1      Link encap:Ethernet  HWaddr 00:50:56:A8:7D:21
>          inet addr:192.168.1.72  Mask:255.255.255.0
>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>          RX packets:785094 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:767027 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:127061481 (121.1 MiB)  TX bytes:329838257 (314.5 MiB)
>          Interrupt:185 Base address:0x1480
>
> lo        Link encap:Local Loopback
>          inet addr:127.0.0.1  Mask:255.0.0.0
>          inet6 addr: ::1/128 Scope:Host
>          UP LOOPBACK RUNNING  MTU:16436  Metric:1
>          RX packets:27 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>          RX bytes:10900 (10.6 KiB)  TX bytes:10900 (10.6 KiB)
>
> [root at vpn log]# ip route
> X.X.X.224/27 dev eth0  proto kernel  scope link  src X.X.X.X
> 192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.72
> 169.254.0.0/16 dev eth1  scope link
> default via X.X.X.225 dev eth0
>
> _______________________________________________
> grlug mailing list
> grlug at grlug.org
> http://shinobu.grlug.org/cgi-bin/mailman/listinfo/grlug



-- 

Ubber::Geek
http://grlug.org/