[GRLUG] IPSec & CentOS

[Adam Tauno Williams]

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