Thanks Tyson for the clarification.
I got another question about GET VPN: how is routing implemented?
Relating to this example: http://www.wr-mem.com/?p=307
How does R2 know that loopback1 (192.168.12.1) is reachable via R1? I
don't get it at the moment.
Regards
Simon
Am 29.08.2009 um 16:21 schrieb Tyson Scott:
Just as a last clarification you should never use an “ANY” statement
in the ACL’s on the key server just the same as basic site to site
unless your GET VPN network is the only thing outside that
interface, I.E. an intercompany network and you have your internet
traffic going out another direction.
The ACL should only be defined to encrypt the specific traffic you
want to encrypt. Otherwise the site will no longer have any
communication capabilities outside the GET VPN Network.
What the documentation is speaking of when it says to use a deny
first is when there are certain subnets within a network range you
don’t want to encrypt.
So for instance if you had 10.1.0.0/16 and you want to encrypt all
traffic in this network except for 10.1.24.0/24
deny ip 10.1.0.0 0.0.255.255 10.1.24.0 0.0.0.255
deny ip 10.1.24.0 0.0.0.255 10.1.0.0 0.0.255.255
permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255
Regards,
Tyson Scott - CCIE #13513 R&S and Security
Technical Instructor - IPexpert, Inc.
Telephone: +1.810.326.1444
Cell: +1.248.504.7309
Fax: +1.810.454.0130
Mailto: [email protected]
Join our free online support and peer group communities:
http://www.IPexpert.com/communities
IPexpert - The Global Leader in Self-Study, Classroom-Based, Video
On Demand and Audio Certification Training Tools for the Cisco CCIE
R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice
Lab and CCIE Storage Lab Certifications.
From: [email protected] [mailto:[email protected]
] On Behalf Of Simon Baumann
Sent: Saturday, August 29, 2009 7:35 AM
To: Kingsley Charles
Cc: [email protected]
Subject: Re: [OSL | CCIE_Security] Clarification about GET VPN.
Hi Kings,
now I got it, thanks!
Regards
Simon
Am 29.08.2009 um 13:32 schrieb Kingsley Charles:
Hi Simon
Yes, it's just like site to site VPN but IPSec phase 2 SAs alone are
pushed from the Getvpn server to the members.
Welcome...
With regards
Kings
On Sat, Aug 29, 2009 at 4:55 PM, Simon Baumann <[email protected]
> wrote:
Anfang der weitergeleiteten E-Mail:
Von: Simon Baumann <[email protected]>
Datum: 29. August 2009 13:25:28 MESZ
An: Kingsley Charles <[email protected]>
Betreff: Re: [OSL | CCIE_Security] Clarification about GET VPN.
Hi Kings,
thanks! So it's like the "classic" ipsec L2L ACL using to match the
interresting traffic?
Regards
Simon
Am 29.08.2009 um 12:59 schrieb Kingsley Charles:
Hi Simon
The following ACL is enough to be configured on the GETVPN server.
permit ip host 22.22.22.1 any
permit ip host 77.77.77.1 any
permit ip host 88.88.88.1 any
But the above ACL will encrypt all the traffic from 22.22.22.1,
77.77.771 abd 88.88.88.1.
Given below is the specific ACL.
permit ip host 22.22.22.1 77.77.77.1
permit ip host 22.22.22.1 88.88.88.1
permit ip host 88.88.88.1 22.22.22.1
permit ip host 77.77.77.1 22.22.22.1
permit ip host 88.88.88.1 77.77.77.1
permit ip host 77.77.77.1 88.88.88.1
You need to start with deny statements, when you don't want specific
traffic to be encrypted. For example, the creteria is to encrypt
10.20.30.0 subnet
but you don't neet to encrypt any ssh session and traffic from
10.20.30.4
deny tcp 10.20.30.0 any eq ssh
deny udp 10.20.30.0 any eq ssh
deny ip 10.20.30.4 any
permit ip 10.20.30.0 any
You also have an option to associate an ACL in the Group member
crypto map to deny traffic.
With regards
Kings
On Sat, Aug 29, 2009 at 4:01 PM, Simon Baumann <[email protected]
> wrote:
Hi Segun,
ok, thanks. I don't want to encrypt all raffic, only the traffic to
the loopbacks.
Regards
Simon
Am 29.08.2009 um 12:23 schrieb 'Segun Daini:
Hi Simon,
The getvpn acl need to match intresting traffic-since there's a
default deny after ur acl you really dont need to put the 3 deny
statements you have there.
You would need to put a deny before permit if there are specific IPs
within your permit network that shld not be encrypted. And in ur
example, the traffic u denied does not match any of the permitted
traffic, therefore i do not think its necesary.
Regards.
From: Simon Baumann <[email protected]>
To: [email protected]
Sent: Saturday, August 29, 2009 2:09:15 PM
Subject: [OSL | CCIE_Security] Clarification about GET VPN.
Hi,
I'm setting up an GET VPN environmet at a security ProtcorLabs pod. My
scenario looks like this:
Used devices: cat2, r1, r7, r8
cat2:
vlan 2, int vlan2: ip addr 2.2.2.254
vlan 7, int vlan 7: ip addr 7.7.7.254
vlan 8, int vlan 8: ip addr 8.8.8.254
Server: r1
Clients: r7 and r8
r1: fa0/1: ip addr 2.2.2.1, lo0: 22.22.22.1. Default route to fa0/1.
r7: fa0/0: ip addr 7.7.7.1, lo0 77.77.77.1. Default route to fa 0/0.
r8: fa0/0: ip addr 8.8.8.1, lo0 88.88.88.1. Default route to fa 0/0.
I want to protect traffic between the loopbacks of my router. But I'm
not sure how I have to configure my ACL to only
match this traffic.
The Cisco documentation states: "Ensure that your ACL starts with a
deny statement if all traffic does not need to be encrypted."
So in my case, this would be the following ACL?
ip access-list extended GET_VPN
deny ip host 2.2.2.1 any
deny ip host 8.8.8.1 any
deny ip host 7.7.7.1 any
permit ip host 22.22.22.1 any
permit ip host 77.77.77.1 any
permit ip host 88.88.88.1 any
TIA.
Have a nice weekend
Simon
_______________________________________________
For more information regarding industry leading CCIE Lab training,
please visit www.ipexpert.com
_______________________________________________
For more information regarding industry leading CCIE Lab training,
please visit www.ipexpert.com
_______________________________________________
For more information regarding industry leading CCIE Lab training,
please visit www.ipexpert.com
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit
www.ipexpert.com
