From: Fabrice Bobes (study@6colabs.com)
Date: Fri May 02 2003 - 20:30:20 GMT-3
Denis,
Quick answers:
1) support for multicast is not incuded in IPSec and a turn-around is to
add another layer of encapsulation to preserve the multicast address.
A GRE tunnel becomes handy if the two ends of your vpn run OSPF or EIGRP
for example.
IPsec is for IP and a GRE tunnel becomes handy again to transfer non-IP
protocols.
2) I believe it makes more sense to use the physical remote address
since it's generally also the tunnel destination address. If you want to
use the IP address of the tunnel interface, you must specify this
interface as the local-address (crypto map "blabla" local-address
"tunnelIPaddress").
If you don't do this, one end of the vpn may identify itself using the
IP address of the physical interface (ex e0/0) while the other end will
be using the IP address of its Tunnel interface.
3) yes absolutely
4) Not sure what you want to achieve here. If traffic goes via e1, it
will be unencrypted and it will be dropped when received on the other
end where the traffic is expected to be encrypted.
Did I add more confusion?
Thanks,
Fabrice
http://www.6colabs.com
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Denis Theodossiou
Sent: Friday, May 02, 2003 12:53 PM
To: ccielab@groupstudy.com
Subject: IPsec : To tunnel or not to tunnel ?
Hi,
I've been trying to understand IPsec and I am now confused. Let me first
tell you what I understand :
Crypto maps are applied on an interface and based on an ACL, outbound
traffic matching this ACL is "diverted" from the interface to an IPsec
"tunnel" beween the router and the IPsec peer. This traffic then gets
encrypted etc. based on the transform sets applied to the crypto map and
the IPsec negotiation.This means that the IPsec traffic gets
encapsulated in packets having IP source address the IP address of the
interface where the traffic was picked up from and IP destination
address the "IPsec peer" address. Just like if it was a GRE tunnel. At
the destination, the traffic must arrive on an interface having another
crypto map applied, with a mirror ACL, and then it gets decrypted,
deencapsulated and sent to continue its peaceful IP path to its real
destination.
On a couple of sample labs I did, the solution created first a normal
GRE tunnel (interface tunnelX), and then applied the crypto map on that
interface. This confuses me a bit :
(1) Since the IPsec is in fact a tunnel, why would you want to create
another tunnel and have the traffic be tunnelled twice ?
(2) Is the IPsec peer the same IP address as the tunnel destination IP
address ? Some configs had the remote Tunnel interface IPs as IPsec
peers and some the tunnel destination IP (ie. The remote "physical"
address). What is the difference between the two configs ?
(3) Just so that I understand it correctly, must the "crypto isakmp key
address" be the same as the "set peer" address inside the crypto map
when using pre-shared IKE keys ?
(4) Is it possible to send the IPsec traffic out another interface than
the one it was "picked up" from ? Ie. Apply the crypto map on Eth0 to
catch traffic that would normally go out Eth0, but send this encrypted
traffic out Eth1 ?
Thank you for your thoughts,
Denis
This archive was generated by hypermail 2.1.4 : Mon Jun 02 2003 - 15:13:36 GMT-3