From: MMoniz (ccie2002@tampabay.rr.com)
Date: Sat Sep 06 2003 - 18:55:35 GMT-3
Well I have tried something similar. Never was the routing traffic itself
encrypted, in fact never matched on the acl for the crypto map.
I don't think it is possible to actually encrypt the routing traffic with
IPSEC. Even when it was uni-cast traffic defined by neighbor statements.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Roberts, Larry
Sent: Saturday, September 06, 2003 5:42 PM
To: Ccielab Mailing List (ccielab@groupstudy.com)
Subject: CCIE Practical Studies:Security Case Study
OK,
Just curious if anyone else has looked at Case Study 20-1? They claim that
the configuration is Dynamic routing information over an IPSec VPN.
I have reviewed it a BUNCH and I don't think that this is what they are
doing at all. If you review, you will see that the private networks
12.12.12.12/32
13.13.13.13/32
14.14.14.14/32
Are all learned over the GRE Tunnels.
Your CryptoACL's are only encrypting data to/from those networks, so your
EIGRP data is just in GRE over the tunnel, while your Data between this
network is IPSec protected over the GRE tunnels.
( is it worth mentioning that the mask of the ACL's don't match the mask of
the Interface?)
What is worse is that your Multicast/broadcast traffic between these
networks still isn't going to cross the link.
Perhaps it would be better labeled as "concurrent GRE/IPSec tunnels with
IPSec protection of Data Flows" which is what they are really doing...
Thanks
Larry
This archive was generated by hypermail 2.1.4 : Wed Oct 01 2003 - 07:24:24 GMT-3