pix-pix meshed vpn setup options

Discussion in 'Cisco' started by Bill F, Dec 2, 2004.

  1. Bill F

    Bill F Guest

    I seem to remember reading a cisco doc that contained a dynamic meshed
    configuration, however, I can't seem to find such a doc at this time. I
    am familiar with dmvpn which I know is an IOS feature and therefore
    isn't relevant. Is there an alternative to configuring a crypto map and
    isakmp entry?


    .....Walter? ;)

    Thanks
    Bill F, Dec 2, 2004
    #1
    1. Advertising

  2. Bill F

    Bill F Guest

    I meant to write..
    Is there an alternative to configuring a crypto map and
    isakmp entry for each peer?

    Bill F wrote:
    > I seem to remember reading a cisco doc that contained a dynamic meshed
    > configuration, however, I can't seem to find such a doc at this time. I
    > am familiar with dmvpn which I know is an IOS feature and therefore
    > isn't relevant. Is there an alternative to configuring a crypto map and
    > isakmp entry?
    >
    >
    > ....Walter? ;)
    >
    > Thanks
    >
    Bill F, Dec 2, 2004
    #2
    1. Advertising

  3. Bill F

    Erik Freitag Guest

    On Thu, 02 Dec 2004 23:28:43 +0000, Bill F wrote:

    > I meant to write..
    > Is there an alternative to configuring a crypto map and
    > isakmp entry for each peer?
    >
    > Bill F wrote:
    >> I seem to remember reading a cisco doc that contained a dynamic meshed
    >> configuration, however, I can't seem to find such a doc at this time. I
    >> am familiar with dmvpn which I know is an IOS feature and therefore
    >> isn't relevant. Is there an alternative to configuring a crypto map and
    >> isakmp entry?
    >>
    >>
    >> ....Walter? ;)
    >>
    >> Thanks
    >>


    I think you're talking about dynamic crypto maps. There's an example in
    the PIX configuration guide, but I've never tried them. It appears to be
    more of a hub-and-spoke configuration (with dynamic map at the hub) than a
    mesh.

    If you really have enough endpoints that setting up the mesh is a problem,
    maybe your carrier has MPLS and that would be a better idea. This is an
    opinion, not a fact.
    Erik Freitag, Dec 2, 2004
    #3
  4. In article <YULrd.27757$>,
    Bill F <> wrote:
    :I seem to remember reading a cisco doc that contained a dynamic meshed
    :configuration, however, I can't seem to find such a doc at this time. I
    :am familiar with dmvpn which I know is an IOS feature and therefore
    :isn't relevant. Is there an alternative to configuring a crypto map and
    :isakmp entry?


    I had a look ad the dmvpn documentation, and started to write something
    up about EzVPN, AAA, and downloadable ACLs, but I realized that they
    are not going to help.

    In order for a PIX to be able to initiate a tunnel to another PIX,
    the other PIX has to either be listed in a crypto map 'set peer'
    statement, or the other PIX has to be listed in a 'vpnclient server'
    statement. Neither of those are adjustable on the fly except by loading
    in new configuration (e.g., via tftp.) There's no way to trigger
    a configuration load via SNMP on a PIX, so you end up with the
    equivilent of using 'expect' and ssh to connect to the PIX, authenticate,
    and sending the new configuration information.


    If the important point is that the spokes have to be able to communicate
    with each other, and you don't really care whether the traffic goes
    directly there or not, then there is a trick I have running that you
    may perhaps be able to hack for your own purposes.


    The usual problem with a hub and spoke configuration using a PIX
    is that the PIX will not allow traffic to go back out the same interface
    it just came in, so you can't just use a central PIX as a relay hub.
    This restriction only applies, though, if it is the -same- packet
    [aside from VPN encapsulation] that would go out the same interface
    as it came in. This leads to two related architectures in which a central PIX
    can be used as a relay hub:

    1) Split the public IP space of the outside interface of the PIX, and
    either create a second logical interface on the outside of the hub PIX
    to handle that address range [requires a router with 802.1Q support,
    and requires a PIX 515, 515E, 520, 525, or 535], or use an additional
    physical interface for the hived-off address range [requires a router,
    switch, or hub with multiple interfaces, and a PIX 510, 515, 515E, 520,
    525, or 535]. Each spoke has a 'set peer' to the original IP address
    of the PIX outside hub, but has a 'set peer' to the IP address of
    the additional logical or physical interface on a crypto map entry that
    matches all of the potential internal IP ranges of the other spokes.

    Thus, when a spoke wants to talk to the hub PIX directly, it tunnels
    to the main interface, but when it wants to talk to another spoke,
    it tunnels to the new interface. When a packet for a distant spoke was
    transmitted to the secondary interface, the normal route statements on
    the PIX would then pass the packet on to the main interface; as it would
    be a different exit interface than entrance interface, the PIX will let
    it go through.

    Now here's an important step: as the packet comes from the secondary
    interface and heads out the main interface to a spoke, the PIX must
    NAT the source IP into an IP that is handled by the main interface
    of the PIX, so that the reply will go back to the main interface
    of the PIX: if you don't do this, then the reply would try to go
    through the secondary VPN tunnel and the PIX adaptive security would
    reject the packet because it doesn't have an entry to permit the
    traffic on that interface. When the reply packet gets back to the
    hub PIX, the hub PIX main interface will de-nat the [now destination] IP.
    This leads to the other half of the important step: the IP it
    gets back must be one that is routed through the appropriate
    spoke-to-secondary interface, so the source IP of the original packet
    has to have been NAT'd by the sending system into a range that is
    private to the spoke and hub, by using reverse NAT.

    You'll have to excuse me here a bit: I haven't implimented this
    architecture and I would need to sit down with some paper and double-check
    the details of what system does which NAT. I suspect I may have one
    of the fine details wrong.


    2) Now this architecture I -have- implimented: Instead of the above
    situation with an additional interface on the hub PIX, instead add
    a second PIX "inside" the LAN of the hub PIX. For the regular spoke
    to hub traffic, the spoke PIX tunnels to the outside of the main PIX.
    When, though, the spoke wants to talk to another spoke, or to any
    other system that the spoke would not normally be able to reach
    [e.g., because the owners of the IP address range won't allow
    reverse DNS into a domain whose name is being authenticated against],
    then the spoke sends through the secondary VPN tunnel to the peer
    PIX which is "inside" the hub LAN. The main hub PIX would be configured to
    allow this IPSec traffic through to the inner LAN PIX.

    The inner PIX then strips off the IPSec encapsulation as the incoming
    spoke packet hits one of its interfaces. The PIX then NAT's the source
    IP to be that of an IP that is being routed to the inner PIX, and sends
    the packet on it's way out the other interface. The easiest way to
    handle this is to have the IPSec tunnel terminate on the 'inside'
    interface of the inner PIX and for the traffic to pass out through the
    outside interface of the inner PIX.

    The traffic heading out of the outside interface of the inner PIX is
    NOT IPSec at this stage; however, because of normal default routings,
    the traffic will make its way to the inside of the outer hub PIX, where
    its destination will be recognized and tunneled to the appropriate
    spoke [or just allowed to go out onto the Internet -- except now it is
    going out with a source IP address which belongs to the hub instead of
    to the spoke, which can make crucial differences for some
    authentication schemes.] When the remote system (remote PIX spoke or
    remote system on the Internet) replies, the IP will lead the packet
    back through the outer PIX where [if necessarily] it will have the
    IPSec layer stripped off of it. The outer PIX will then send the
    packet inwards to the inner PIX [either by proxy arp or because
    you routed appropriately], where the destination IP will be de-natted
    back to the original source IP given by the original spoke, and the
    routes and VPN tunnels set up on the inner PIX will then encapsulate
    the packet and send it back to the original spoke.

    To get the routing to work properly for the reverse trip, the IP
    de-nat'd to must be one that is private between the original spoke and
    the inner PIX.


    Example:

    spoke 1:

    names
    name HubPixIP 201.83.11.94
    name HubUaxPixIP 201.83.11.96
    name HubNet 192.168.0.0
    name ThisSpokeNet 192.168.1.0
    name ThisSpokeMapNet 192.168.129.0
    name Spoke2Net 192.168.2.0
    name Spoke3Net 192.168.3.0

    access-list static2spokes permit ip ThisSpokeNet 255.255.255.0 Spoke2Net 255.255.255.0
    access-list static2spokes permit ip ThisSpokeNet 255.255.255.0 Spoke3Net 255.255.255.0

    access-list nonat permit ip ThisSpokeNet 255.255.255.0 HubNet 255.255.255.0

    access-list vpn2hub permit ip ThisSpokeNet 255.255.255.0 HubNet 255.255.255.0

    ; note: in vpn2spokes, ThisSpokeNet might need to be ThisSpokeMapNet
    ; instead. I remember running into an oddity one time when I was
    ; experimenting with NAT through a VPN.

    access-list vpn2spokes permit ip ThisSpokeNet 255.255.255.0 Spoke2Net 255.255.255.0
    access-list vpn2spokes permit ip ThisSpokeNet 255.255.255.0 Spoke3Net 255.255.255.0

    nat (inside) 0 access-list nonat
    static (inside, outside) ThisSpokeMapNet access-list static2spokes

    crypto ipsec transform-set vc-ea256s esp-aes-256 esp-sha-hmac
    crypto map vpn-map 10 ipsec-isakmp
    crypto map vpn-map 10 match address vpn2hub
    crypto map vpn-map 10 set peer HubPixIP
    crypto map vpn-map 10 set transform-set vc-ea256s
    crypto map vpn-map 20 ipsec-isakmp
    crypto map vpn-map 10 match address vpn2spokes
    crypto map vpn-map 10 set peer HubUaxPixIP
    crypto map vpn-map 10 set transform-set vc-ea256s

    --
    I've been working on a kernel
    All the livelong night.
    I've been working on a kernel
    And it still won't work quite right. -- J. Benson & J. Doll
    Walter Roberson, Dec 3, 2004
    #4
    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. Gary
    Replies:
    2
    Views:
    534
    Rik Bain
    Oct 20, 2003
  2. Richard

    PIX to PIX to PIX meshed VPN

    Richard, Nov 13, 2003, in forum: Cisco
    Replies:
    1
    Views:
    587
    Richard
    Nov 15, 2003
  3. GVB
    Replies:
    1
    Views:
    2,761
    Martin Bilgrav
    Feb 6, 2004
  4. bturner
    Replies:
    0
    Views:
    484
    bturner
    Sep 22, 2006
  5. linguafr

    OSPF in fully meshed environment

    linguafr, Mar 8, 2007, in forum: Cisco
    Replies:
    9
    Views:
    461
    stephen
    Mar 13, 2007
Loading...

Share This Page