Hi Pieter, I made a mistake. I should have another ACL for returning traffic. I think removing the the access-list with private IP is not necessary. Well, thats it! Not passing traffic on private IPs and traffic encrypted for Publilc IPs for GETVPN over internet. Thanks alot!
GROUP INFORMATION
Group Name : gdoi-group
Group Identity : 1
Rekeys received : 0
IPSec SA Direction : Both
Active Group Server : 192.168.16.1
Group Server list : 192.168.16.1
GM Reregisters in : 3790 secs
Rekey Received : never
Rekeys received
Cumulative : 0
After registration : 0
ACL Downloaded From KS 192.168.16.1:
access-list permit ip host 203.166.26.233 host 203.166.26.225
access-list permit ip host 203.166.26.225 host 203.166.26.233
access-list permit ip host 192.168.16.9 host 192.168.16.13
access-list permit ip host 192.168.16.13 host 192.168.16.9
GM1#clear crypto gdoi
% The Key Server and Group Member will destroy created and downloaded
policies.
% All Group Members are required to re-register.
Are you sure you want to proceed ? [yes/no]: yes
GM1#ping 203.166.26.225 so 203.166.26.233 rep 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 203.166.26.225, timeout is 2 seconds:
Packet sent with a source address of 203.166.26.233
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/2/4 ms
GM1#ping 192.168.1.13 so 192.168.16.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.13, timeout is 2 seconds:
Packet sent with a source address of 192.168.16.9
.....
Success rate is 0 percent (0/5)
local ident (addr/mask/prot/port): (203.166.26.233/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (203.166.26.225/255.255.255.255/0/0)
current_peer 0.0.0.0 port 848
PERMIT, flags={origin_is_acl,}
#pkts encaps: 20, #pkts encrypt: 20, #pkts digest: 20
#pkts decaps: 20, #pkts decrypt: 20, #pkts verify: 20
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
On Thu, Sep 10, 2009 at 3:28 AM, Pieter-Jan Nefkens <
[email protected]> wrote:
> Hi Dean,
> You should remove the second line in the access-list ( permit ip host
> 192.168.19.9 host 192.168.16.13) as I assume that those ip-addresses are the
> external side of the GETVPN. Those entries should not be included in the
> access-list that defines what traffic is to be encrypted, because that will
> not work.
>
> If you remove that line, traffic between 192.168.16.9 and 192.168.16.3 is
> not encrypted, but traffic from 203.166.26.233 to 203.166.26.225 is. Only
> internal traffic must be included in the GETVPN access-list (which is
> logical, as the GETVPN was originally intended for securing MPLS based WAN
> connections, and the external (WAN) connection is usually assigned by the
> MPLS provider and not the internal LAN which you want to secure).
>
> HTH
>
> Pieter-Jan
>
> On 9 sep 2009, at 20:04, Dean Armada wrote:
>
> Hi Pieter,
>
> Thanks for the added information. I am doing some experiment right now and
> it seems that it is not getting any traffic from either Public or Private IP
> addresses. Is it because my Group Member IDs and Key Server ID are Private
> IPs? I am able to reach ip address if I remove crypto map.
>
>
> GROUP INFORMATION
>
> Group Name : gdoi-group
> Group Identity : 1
> Rekeys received : 0
> IPSec SA Direction : Both
> Active Group Server : 192.168.16.1
> Group Server list : 192.168.16.1
>
> GM Reregisters in : 5555 secs
> Rekey Received : never
>
>
> Rekeys received
> Cumulative : 0
> After registration : 0
>
> ACL Downloaded From KS 192.168.16.1:
> access-list permit ip host 203.166.26.233 host 203.166.26.225
> access-list permit ip host 192.168.16.9 host 192.168.16.13
>
> TEK POLICY for the current KS-Policy ACEs Downloaded:
> GigabitEthernet0/1.26:
> IPsec SA:
> spi: 0x75C3FCC2(1975778498)
> transform: esp-256-aes esp-sha-hmac
> sa timing:remaining key lifetime (sec): (5795)
> Anti-Replay(Time Based) : 10 sec interval
>
>
>
> GM1(config-subif)#do ping 203.166.26.225 so 203.166.26.233
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 203.166.26.225, timeout is 2 seconds:
> Packet sent with a source address of 203.166.26.233
> .....
> Success rate is 0 percent (0/5)
> GM1(config-subif)#do ping 192.168.16.13 so 192.168.16.9
>
> Type escape sequence to abort.
> Sending 5, 100-byte ICMP Echos to 192.168.16.13, timeout is 2 seconds:
> Packet sent with a source address of 192.168.16.9
> .....
> Success rate is 0 percent (0/5)
>
>
>
> Thanks ,
>
> Dean
>
> On Wed, Sep 9, 2009 at 2:42 AM, Pieter-Jan Nefkens <
> [email protected]> wrote:
>
>> Hi dean,
>> It is only possible to use GETVPN on the Internet if all sites are using
>> publicly assigned ip-address and not using RFC 1918 (private address range)
>> addressing.
>> The reason is that GETVPN only encrypts the payload of the IP packet, and
>> not the original source and destination address.
>>
>> Private IP's are therefore not possible to be used, as those IP addresses
>> are at most ISP's, and at least at the carrier level, dropped at the edge
>> (RFC2827 ingress and egress filtering)
>>
>> So yes, you can setup a GETVPN session, but only traffic from public
>> ip-addresses are possible, no traffic is possible (not even without
>> encryption) with private ip-addresses
>>
>> Pieter-Jan
>>
>>
>> On 8 sep 2009, at 20:19, Dean Armada wrote:
>>
>> From my understanding If we use internet as a transport of GETVPN.
>>
>> - The GM will get a GDOI_REKEY/GDOI_IDLE a will able to download ACL from
>> the KS right?
>> - But there will be no traffic encryption from GM to other GMs (Private IP
>> used)
>> - traffic encryption from GM to other GMs if Public IP is used
>>
>> I might be wrong or may be lacking something. Please post any additional
>> information.
>>
>> Thanks
>>
>>
>> On Fri, Sep 4, 2009 at 4:23 AM, Tyson Scott <[email protected]> wrote:
>>>
>>>> It was designed for internal encryption. I.E. between branches of a
>>>> financial institutions, government entities, etc, or other hypersensitive
>>>> information companies. It is very well designed for this purpose.
>>>>
>>>>
>>>> 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 *Kingsley
>>>> Charles
>>>> *Sent:* Thursday, September 03, 2009 6:09 AM
>>>> *To:* [email protected]
>>>> *Subject:* [OSL | CCIE_Security] GETVPN in internet
>>>>
>>>>
>>>> Hi all
>>>>
>>>>
>>>> GETVPN is an IPSec feature which adds the IP source/destination address
>>>> from the payload which was encrypted. It is equivalent to IPSec transport
>>>> mode. Due to this feature, GETVPN can't be used on private networks like
>>>> MPLS but not on Internet.
>>>>
>>>>
>>>> Does anyone know, why was GETVPN implemented this way where it uses the
>>>> original IP source/destination address and thereby can't be used on
>>>> Internet?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> With regards
>>>>
>>>> Kings
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> ---
>> Nefkens Advies
>> Enk 26
>> 4214 DD Vuren
>> The Netherlands
>>
>> Tel: +31 183 634730
>> Fax: +31 183 690113
>> Cell: +31 654 323221
>> Email: [email protected]
>> Web: http://www.nefkensadvies.nl/
>>
>> <green.gif> Think before you print.
>>
>>
>>
>>
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
>
> ---
>
> Nefkens Advies
>
> Enk 26
>
> 4214 DD Vuren
>
> The Netherlands
>
>
> Tel: +31 183 634730
>
> Fax: +31 183 690113
>
> Cell: +31 654 323221
>
> Email: [email protected]
>
> Web: http://www.nefkensadvies.nl/
>
> Think before you print.
>
>
>
>
<<green.gif>>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
