«

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 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
>

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.

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