Re: PIX, roadwarrior and site-to-site (openswan) - Cisco Community

1231

Views

0

Helpful

7

Replies

Hi! I have a problem: I've a pix on a site and a linux machine on another site with openswan software.

You can see the scenario very well in the picture supportotesi.altervista.org/final.gif

I need to have both roadwarrior (cisco vpn client) and site-to-site connection (openswan).

My pix conf is in the attachment

My ipsec.conf is:

version 2.0

config setup

interfaces="ipsec0=ppp0"

klipsdebug=none

#plutodebug=none

#plutoload=%search

#plutostart=%search

uniqueids=yes

nat_traversal=yes

conn %default

keyingtries=0

disablearrivalcheck=no

authby=secret

conn pix

#type = tunnel

left=yyy.yyy.yyy.yyy

leftsubnet=192.168.0.0/24

leftprotoport=17/0

#leftnexthop=%defaultroute

right=xxx.xxx.xxx.xxx

rightsubnet=10.0.0.0/24

rightid=172.17.32.13

rightprotoport=17/0

authby=secret

#esp=3des-md5-hmac

#keyexchange = ike

pfs=no

auto=add

The roadwarriors are connecting well to the vpn, openswan too but the

192.168.0.x's doesn't ping 10.0.0.x's

Here's the result:

root@darkstar:~# /etc/rc.d/ipsec --restart

ipsec_setup: Stopping Openswan IPsec...

ipsec_setup: Starting Openswan IPsec 2.4.0...

root@darkstar:~# ipsec auto --up pix

104 "pix" #1: STATE_MAIN_I1: initiate

003 "pix" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]

method set to=108

003 "pix" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]

meth=106, but already using method 108

106 "pix" #1: STATE_MAIN_I2: sent MI2, expecting MR2

003 "pix" #1: received Vendor ID payload [XAUTH]

003 "pix" #1: received Vendor ID payload [Dead Peer Detection]

003 "pix" #1: received Vendor ID payload [Cisco-Unity]

003 "pix" #1: ignoring unknown Vendor ID payload

[8a346f4049c4d1e08a7700ecf40aebb1]

003 "pix" #1: NAT-Traversal: Result using

draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed

108 "pix" #1: STATE_MAIN_I3: sent MI3, expecting MR3

004 "pix" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5

group=modp1024}

117 "pix" #2: STATE_QUICK_I1: initiate

003 "pix" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME

004 "pix" #2: STATE_QUICK_I2: sent QI2, IPsec SA established

{ESP=>0x991beb28 <0xc1300ad7 xfrm=3DES_0-HMAC_MD5 NATD=xxx.xxx.xxx.xxx:4500 DPD=none}

As you can see the SA is established but the pc doesn't see each other.

I've tried with windows xp. There's a tool over the net (smart vpn client)

that is a sort of site-to-site but without pcs behind the pc who use this

tool. I mean... connect to pix not as a roadwarrior but as a site-to-site.

But you cannot have a subnet behind (sorry for my bad explanation) and it

works! So I think my access-list are good.

Can anyone help me??

Sorry for the length of my post...

4 KB

7 Replies 7

i believe the remote vpn access is working fine, and i don't see any error with the pix config. i guess the issue is either on the linux or the actual pc.

on the pix, do "debug icmp trace" and then kick off pinging from a pc at pix site to a pc at linux site. also on the pix do "sh crypto ips sa" to verify wether the packet has been encrypted/decrypted as expected.

e.g.

pix# sh cry ips sa

interface: outside

Crypto map tag: myvpn, local addr. xxxxxx

local ident (addr/mask/prot/port): (xxx.xxx.xxx.xxx/255.255.255.255/0/0)

remote ident (addr/mask/prot/port): (xxx.xxx.xxx.xxx/255.255.255.0/0/0)

current_peer: xxxxxx:4500

dynamic allocated peer ip: 0.0.0.0

PERMIT, flags={origin_is_acl,transport_parent,}

#pkts encaps: 177889, #pkts encrypt: 177889, #pkts digest 177889

#pkts decaps: 179936, #pkts decrypt: 179936, #pkts verify 179936

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 1, #recv errors 0

with the sample output above, you can see 177889 packets have been encrypted and 179936 packets have been decrypted.

assuming you don't see any packet being encrypted, then the issue is with the pix; whereas if you don't see any packet being decrypted, then the issue is with the linux (or the pc at linux site).

another thing you may want to verify is the software firewall installed on the pc, including the windows sp2 firewall.

Thanks Jackko.

I've made this test: ping from a pc behind pix to a pc behind linux

pixfirewall(config)# debug icmp trace

51: Outbound ICMP echo request (len 56 id 4010 seq 7) 10.0.0.2 > 10.0.0.2 > 192.168.0.33

52: Outbound ICMP echo request (len 56 id 4010 seq 8) 10.0.0.2 > 10.0.0.2 > 192.168.0.33

53: Outbound ICMP echo request (len 56 id 4010 seq 9)

but:

pixfirewall(config)# sh cry ips sa

local ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/17/0)

remote ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/17/0)

current_peer: yyy.yyy.yyy.yyy:4500

PERMIT, flags={transport_parent,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

so zero packets encaps, decaps, encrypt, decrypt...

Is the problem on the pix??

Viceversa test:

icmp doesn't see the packets incoming

sh ipsec sa doesn't enc, dec anything

What do you think??

Thanks again

do "sh cry isa sa" verifying the state whether it's "qm_idle" or "mm_no_state".

i suspect that the vpn was not established correctly, and that's why both # of encrypted and decrypted are zero.

I think it is created:

pixfirewall# sh cry isa sa

Total : 1

Embryonic : 0

dst src state pending created

172.17.32.13 yyy.yyy.yyy.yyy QM_IDLE 0 1

Notice that 172.17.32.13 is the private ip of the pix natted to xxx.xxx.xxx.xxx (as you can see in my scheme).... Maybe is here the prob? Maybe not 'cause I've enable nat traversal... I don't know...

Thanks

i was assuming 172.17.32.13 is just an ip you created for discussion purposes.

you mentioned this ip assigned on the pix outside interface is natted to xxx.xxx.xxx.xxx, so does it mean there is another device in front of the pix connecting to the internet, such as a router (the router also perform nat/pat).

another suggestion is to upgrade the pix os, since v6.3.1 has serious bug related to nat/vpn. (you may choose v6.3.4 or v6.3.5.)

I've put only public ips with xxx and yyy

The others are real.

So the problem can be connected to the OS...

Do you think the router that make the nat for the whole net can be the problem too? I mean... maybe some ports are closed... Remeber that with the client everything works fine...

However do you think that my configuration is right? This question is very important...

Thanks a lot Jackko!

verify the router inbound acl, if there is any.

in particular, you need to permit:

udp 500

udp 4500

ip 50 (i.e. esp)