«

The main site has a Pix (2 lans: main & dmz). The main lan has multiple
networks, routed by a router. All that works fine: all networks can NAT out
to the internet, and can get to / from the DMZ without NAT

We already has a VPN to another site (to a Cisco router of some sort) which
is all working fine.

We are trying to create a second VPN to another site: the remote unit is a
Draytek 2900. To keep things simple, I'm starting by trying to allow the
remote site to access TWO of the networks on the "main" lan.

Remote: 10.31.0.0/24
Main: 195.12.17.0/24 and 10.44.0.0/16

The Pix is on the 195.12.17.0 network, running 6.1(2)

Various bits below... maybe one of you guys can shed some light on the
problems:


The new DMS partly works: I can access from the remote 10.31.0.0 network
through to the 195.12.17.0 network, but I seem unable to access tho the
10.44.0.0 network.

On the pix, I have added the following:

#
# Pix setup to link to Dutch Draytek
#

# 1) setup so that dutch addresses don't NAT

access-list NoNATlist permit ip 195.12.17.0 255.255.255.0 10.31.0.0
255.255.255.0
access-list NoNATlist permit ip 10.44.0.0 255.255.0.0 10.31.0.0
255.255.255.0

# 2) define what goes down the VPN

access-list NLWHVPN permit ip 195.12.17.0 255.255.255.0 10.31.0.0
255.255.255.0
access-list NLWHVPN permit ip 10.44.0.0 255.255.0.0 10.31.0.0 255.255.255.0

# 3) define who can see what

conduit permit tcp 195.12.17.0 255.255.255.0 10.31.0.0 255.255.255.0
conduit permit udp 195.12.17.0 255.255.255.0 10.31.0.0 255.255.255.0
conduit permit tcp 10.44.0.0 255.255.0.0 10.31.0.0 255.255.255.0
conduit permit udp 10.44.0.0 255.255.0.0 10.31.0.0 255.255.255.0

# 4) this lot sets up the VPN tunnel

crypto map kerridgecrytpomap 31 ipsec-isakmp
crypto map kerridgecrytpomap 31 match address NLWHVPN
crypto map kerridgecrytpomap 31 set peer 194.x.x.x
crypto map kerridgecrytpomap 31 set transform-set kerridgetransportset

# 5) this sets the authentication "password" & properties

isakmp key xxxxxxx address 194.x.x.x netmask 255.255.255.255 no-xauth
no-config-mode
isakmp policy 31 authentication pre-share
isakmp policy 31 encryption des
isakmp policy 31 hash md5
isakmp policy 31 group 1
isakmp policy 31 lifetime 86400

(...... the "kerridgecrytpomap" is the one already in use)

On the Draytek, I've set both of the main addresses (you set the "primary"
plus a list of others.... so I've tried the 2 networks both ways around...
no difference)

The following may help (although I don't really understand it!):

----------------------------------------------------------------------------
-------------
# show crypto ipsec sa


interface: outside
Crypto map tag: kerridgecrytpomap, local addr. 194.216.203.253

local ident (addr/mask/prot/port): (10.44.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.31.0.0/255.255.255.0/0/0)
current_peer: 194.216.203.240
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
#pkts decaps: 104, #pkts decrypt: 104, #pkts verify 104
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress
failed: 0
#send errors 0, #recv errors 104

local crypto endpt.: 194.216.203.253, remote crypto endpt.:
194.216.203.240
path mtu 1500, ipsec overhead 56, media mtu 1500
current outbound spi: 0

inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:

local ident (addr/mask/prot/port): (195.12.17.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.31.0.0/255.255.255.0/0/0)
current_peer: 194.216.203.240
PERMIT, flags={origin_is_acl,}
#pkts encaps: 2639, #pkts encrypt: 2639, #pkts digest 2639
#pkts decaps: 3789, #pkts decrypt: 3789, #pkts verify 3789
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress
failed: 0
#send errors 10, #recv errors 206

local crypto endpt.: 194.216.203.253, remote crypto endpt.:
194.216.203.240
path mtu 1500, ipsec overhead 56, media mtu 1500
current outbound spi: b76fdfc6

inbound esp sas:
spi: 0x33342693(859055763)
transform: esp-des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2, crypto map: kerridgecrytpomap
sa timing: remaining key lifetime (k/sec): (4606907/2824
IV size: 8 bytes
replay detection support: Y


inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xb76fdfc6(3077562310)
transform: esp-des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 1, crypto map: kerridgecrytpomap
sa timing: remaining key lifetime (k/sec): (4607893/2824
IV size: 8 bytes
replay detection support: Y

outbound ah sas:
outbound pcp sas:

----------------------------------------------------------------------------
-------------
(I deleted a load of blank lines in there to tidy it up a bit)

Also, the response to:

# clear crypto ipsec sa

is:

pix.centia.net(config)# IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 0xf0a83625(4037555749) for SA
from 194.216.203.240 to 194.216.203.253 for prot 3
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 194.216.203.253, src= 194.216.203.240,
dest_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
src_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
IPSEC(validate_transform_proposal): peer address 194.216.203.253 not found
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 194.216.203.253, src= 194.216.203.240,
dest_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
src_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
IPSEC(key_engine): got a queue event...
IPSEC(initialize_sas): ,
(key eng. msg.) dest= 194.216.203.253, src= 194.216.203.240,
dest_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
src_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 28800s and 4608000kb,
spi= 0xf0a83625(4037555749), conn_id= 1, keysize= 0, flags= 0x4
IPSEC(initialize_sas): ,
(key eng. msg.) src= 194.216.203.253, dest= 194.216.203.240,
src_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
dest_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 28800s and 4608000kb,
spi= 0xb76fdfc7(3077562311), conn_id= 2, keysize= 0, flags= 0x4
IPSEC(key_engine): got a queue event...
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
IPSEC(key_engine): got a queue event...
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
IPSEC(key_engine_delete_sas): delete all SAs shared with 194.201.4.155
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 194.216.203.253, src= 194.216.203.240,
dest_proxy= 10.44.0.0/255.255.0.0/0/0 (type=4),
src_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 0x418049e(68682910) for SA
from 194.216.203.240 to 194.216.203.253 for prot 3
IPSEC(key_engine): got a queue event...
IPSEC(initialize_sas): ,
(key eng. msg.) dest= 194.216.203.253, src= 194.216.203.240,
dest_proxy= 10.44.0.0/255.255.0.0/0/0 (type=4),
src_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 3600s and 0kb,
spi= 0x418049e(68682910), conn_id= 2, keysize= 0, flags= 0x4
IPSEC(initialize_sas): ,
(key eng. msg.) src= 194.216.203.253, dest= 194.216.203.240,
src_proxy= 10.44.0.0/255.255.0.0/0/0 (type=4),
dest_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 3600s and 0kb,
spi= 0xb76fdfc8(3077562312), conn_id= 1, keysize= 0, flags= 0x4
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 194.216.203.253, src= 194.201.4.155,
dest_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
src_proxy= 172.31.0.0/255.255.0.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
IPSEC(key_engine): got a queue event...
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
IPSEC(key_engine_delete_sas): delete all SAs shared with 194.201.4.155
IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 0x251324fa(622011642) for SA
from 194.201.4.155 to 194.216.203.253 for prot 3
IPSEC(key_engine): got a queue event...
IPSEC(initialize_sas): ,
(key eng. msg.) dest= 194.216.203.253, src= 194.201.4.155,
dest_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
src_proxy= 172.31.0.0/255.255.0.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 28800s and 0kb,
spi= 0x251324fa(622011642), conn_id= 6, keysize= 0, flags= 0x4
IPSEC(initialize_sas): ,
(key eng. msg.) src= 194.216.203.253, dest= 194.201.4.155,
src_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
dest_proxy= 172.31.0.0/255.255.0.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 28800s and 0kb,
spi= 0x200fa91f(537897247), conn_id= 5, keysize= 0, flags= 0x4
IPSEC(key_engine): request timer fired: count = 1,
(identity) local= 194.216.203.253, remote= 194.216.203.240,
local_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4)
IPSEC(key_engine): got a queue event...
IPSEC(spi_response): getting spi 0xd47c0c36(3564899382) for SA
from 194.216.203.240 to 194.216.203.253 for prot 3
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 194.216.203.253, src= 194.216.203.240,
dest_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
src_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
IPSEC(validate_transform_proposal): peer address 194.216.203.253 not found
IPSEC(validate_proposal_request): proposal part #1,
(key eng. msg.) dest= 194.216.203.253, src= 194.216.203.240,
dest_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
src_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 0s and 0kb,
spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
IPSEC(key_engine): got a queue event...
IPSEC(initialize_sas): ,
(key eng. msg.) dest= 194.216.203.253, src= 194.216.203.240,
dest_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
src_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 28800s and 4608000kb,
spi= 0xd47c0c36(3564899382), conn_id= 4, keysize= 0, flags= 0x4
IPSEC(initialize_sas): ,
(key eng. msg.) src= 194.216.203.253, dest= 194.216.203.240,
src_proxy= 195.12.17.0/255.255.255.0/0/0 (type=4),
dest_proxy= 10.31.0.0/255.255.255.0/0/0 (type=4),
protocol= ESP, transform= esp-des esp-md5-hmac ,
lifedur= 28800s and 4608000kb,
spi= 0xb76fdfc9(3077562313), conn_id= 3, keysize= 0, flags= 0x4
IPSEC(key_engine): got a queue event...
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP


Any ideas greatly appreciated!!!!!


Paul Blitz
Centia Ltd
England

In article <4174e937$0$780$> ,
paul blitz <> wrote:
:The Pix is on the 195.12.17.0 network, running 6.1(2)


:conduit permit tcp 195.12.17.0 255.255.255.0 10.31.0.0 255.255.255.0
:conduit permit udp 195.12.17.0 255.255.255.0 10.31.0.0 255.255.255.0
:conduit permit tcp 10.44.0.0 255.255.0.0 10.31.0.0 255.255.255.0
:conduit permit udp 10.44.0.0 255.255.0.0 10.31.0.0 255.255.255.0

:# 4) this lot sets up the VPN tunnel

Don't try to mix conduit with IPsec VPNs, or conduits with
access-lists. conduit has been deprecated since PIX 5.2.1, and is not
guaranteed to work with IPsec. PIX 7.0 will not support conduit at
all, so you might as well convert entirely to access-list /
access-group .

You should also upgrade to at least PIX 6.1(5)104 . Even
if you do not have a support contract, that is a free upgrade
from your present 6.1(2), as there are security problems in
your existing version. For more information on the problems and
how to obtain a free upgrade, please read

http://www.cisco.com/en/US/products/...8021ba2f.shtml

--
Cottleston, Cottleston, Cottleston pie.
A bird can't whistle and neither can I. -- Pooh

> Don't try to mix conduit with IPsec VPNs, or conduits with
> access-lists. conduit has been deprecated since PIX 5.2.1, and is not
> guaranteed to work with IPsec.

It certainly works with the existing VPN, so if it's not bust, I'm not gonna
fix it!!!

> PIX 7.0 will not support conduit at
> all, so you might as well convert entirely to access-list /
> access-group .

I would LOVE to convert all of the conduits to use access lists, but the
implications to the business are horrendous!
Similarly, we are not planning to upgrade the box (mainly coz I have no idea
how to!)

Again, on both counts, its not bust, so I'm not gonna try and fix it!!!!


We do actually have a "Plan B"... we have a "spare" pix that we inherited,
and it is running 6.2(1) plus PDM, and I've started playing with PDM... but
that's "future".....



Paul

In article <41762244$0$20461$> ,
paul blitz <> wrote:

:> Don't try to mix conduit with IPsec VPNs, or conduits with
:> access-lists. conduit has been deprecated since PIX 5.2.1, and is not
:> guaranteed to work with IPsec.

:It certainly works with the existing VPN, so if it's not bust, I'm not gonna
:fix it!!!

Sorry, I don't debug configurations with conduit statements in them.


:I would LOVE to convert all of the conduits to use access lists, but the
:implications to the business are horrendous!

Cisco has a program to read configurations that contain conduits
and put out the equivilent configuration with access-lists.
So you use that program and get a new configuration that you then
add the VPN for the new Drytek endpoint on to. That's *one* box
to change now, not the entire business.

If you are trying to say that you can't afford any downtime
on the PIX that you are trying to add the new VPN tunnel to,
and especially since your experience with PIX is not enough to
know basic things such as how to upgrade the PIX software, then
you would also be saying that you shouldn't be trying to put the
tunnel on that box. You don't experiment with business-critical
systems: you experiment with test equipment, such as a ~$350 PIX 501.

--
"Mathematics? I speak it like a native." -- Spike Milligan

> :I would LOVE to convert all of the conduits to use access lists, but the
> :implications to the business are horrendous!
>
> Cisco has a program to read configurations that contain conduits
> and put out the equivilent configuration with access-lists.

That sounds interesting... any ideas what I need to be looking for (eg
Cisco's description)


> If you are trying to say that you can't afford any downtime
> on the PIX that you are trying to add the new VPN tunnel to

No, what I was saying was that the potential downtime of changing from
conduits to access lists could be unacceptable... it only needs one to be
done wrongly, and you could spend ages trying to find the problem.

> and especially since your experience with PIX is not enough to
> know basic things such as how to upgrade the PIX software

I guess that comes down ton unfamiliarity.... I've just never had to do it


> then
> you would also be saying that you shouldn't be trying to put the
> tunnel on that box.

Luckily, there is already a tunnel on the box to elsewhere, which I have
used as the basis for the new tunnel. Sadly, we live in a real world, and
things often have to be done when you don't FULLY understand what you are
doing (ask ANY windows "expert" if they REALLY know what they are doing.
Same probably applies to Cisco engineers too!)

> You don't experiment with business-critical
> systems: you experiment with test equipment, such as a ~$350 PIX 501.

In the ideal world I would agree. Luckily we're not THAT big that we can't
afford the odd 5 mins of unavoidable downtime.

In the end, we gave up trying to use the Cisco, and have a (partial)
solution using RRAS.


paul