Pix VPN: one network passes ok, other doesn't!

Discussion in 'Cisco' started by paul blitz, Oct 19, 2004.

  1. paul blitz

    paul blitz Guest

    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/28248)
    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/28248)
    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
    paul blitz, Oct 19, 2004
    #1
    1. Advertising

  2. 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/products_security_advisory09186a008021ba2f.shtml

    --
    Cottleston, Cottleston, Cottleston pie.
    A bird can't whistle and neither can I. -- Pooh
    Walter Roberson, Oct 19, 2004
    #2
    1. Advertising

  3. paul blitz

    paul blitz Guest


    > 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
    paul blitz, Oct 20, 2004
    #3
  4. 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
    Walter Roberson, Oct 20, 2004
    #4
  5. paul blitz

    paul blitz Guest

    > :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
    paul blitz, Oct 22, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mephesto
    Replies:
    0
    Views:
    1,158
    Mephesto
    Jun 24, 2005
  2. Arjan
    Replies:
    0
    Views:
    881
    Arjan
    Nov 2, 2005
  3. George Kerby

    Henri Cartier-Bresson Dies at 95-Another Great One Passes

    George Kerby, Aug 4, 2004, in forum: Digital Photography
    Replies:
    10
    Views:
    702
    Roland Karlsson
    Aug 7, 2004
  4. rambur
    Replies:
    5
    Views:
    569
    rambur
    Apr 25, 2007
  5. George A.
    Replies:
    5
    Views:
    8,626
    Mikhael47
    May 7, 2007
Loading...

Share This Page