Resources
    Minimalistic GET VPN Exam ...
    22 November 09

    Minimalistic GET VPN Example

    Posted byPetr Lapukhov
    facebooktwitterlinkedin
    news-featured

    Some time ago I mentioned that it is possible to configure a functional GET VPN scenario using just two routers. Normally, GET VPN requires a dedicated Key Server, which does not participate is user traffic encryption and only distributes keying information and encryption policies. All other routers – group members – register to the Key Server. A router could not register to itself when configured as a key server and group member simultaneously. However, there is a Key Server redundancy feature known as KOOP Key Servers that allows for two servers to synchronize the keying information and the group member to register to the redundant key servers.

    Relying upon this feature, we may take two routers and configure them both in a KOOP key server pair. At the same time, every router is configured as a Group Member registering to another router. Since the keying information is being kept in sync, both routers will be able to properly exchange encrypted GET VPN traffic. Now, for the practical implementation we chose two directly connected routers: R4 and R5. GET VPN is supposed to encrypt traffic sent off respective VLAN4 and VLAN5 interfaces of these routers destined to the multicast groups in range 232.0.0.0/8. The IP addresses for VLAN4 and VLAN5 subnets are 173.X.4.0/24 and 173.X.5.0/24. Here is how we configure R4 for Key Server functionality. Notice the redundancy configuration using R5 as the peer.

    KS-R4:
    crypto isakmp keepalive 10 periodic
    !
    crypto isakmp policy 50
    encr 3des
    hash md5
    group 2
    authentication pre-share

    crypto isakmp key CISCO address 150.1.5.5

    crypto ipsec transform-set GETVPN_TS esp-3des esp-md5-hmac

    crypto ipsec profile GETVPN_PROFILE
    set transform-set GETVPN_TS
    !
    crypto key generate rsa general-keys label GETVPN_KEYS modulus 1024 exportable
    !
    no access-list 100
    access-list 100 permit ip 173.1.4.0 0.0.0.255 232.0.0.0 0.255.255.255
    access-list 100 permit ip 173.1.5.0 0.0.0.255 232.0.0.0 0.255.255.255
    !
    crypto gdoi group GETVPN_GROUP
    identity number 1234
    server local
    rekey authentication mypubkey rsa GETVPN_KEYS
    rekey transport unicast
    sa ipsec 1
    profile GETVPN_PROFILE
    match address ipv4 100
    replay time window-size 5
    address ipv4 150.1.4.4
    redundancy
    local priority 100
    peer address ipv4 150.1.5.5

    Now an important thing. GET VPN uses RSA signatures to authenticate GET VPN keying information. Because of that, both R4 and R5 should use the same private/public keys for signing. To accomplish this, export the keys from the first KS and import them in the second. For example, considering R4 was configured as the first KS, you may use the commands below to export/import RSA keys using IOS CLI (don’t forget the blank line between the public and private keys when importing).

    Export Keys at R4:
    crypto key export rsa GETVPN_KEYS pem terminal 3des CISCO1234

    Import Keys at R5:
    crypto key import rsa GETVPN_KEYS pem exportable terminal CISCO1234

    After you have imported the RSA keys in R5, configure R5 for the Key server functionality. Notice that the imported key pair is used for GET VPN keying information signing.

    KS-R5:
    crypto isakmp keepalive 10 periodic
    !
    crypto isakmp policy 10
    encr 3des
    hash md5
    group 2
    authentication pre-share

    crypto isakmp key CISCO address 150.1.4.4

    crypto ipsec transform-set GETVPN_TS esp-3des esp-md5-hmac

    crypto ipsec profile GETVPN_PROFILE
    set transform-set GETVPN_TS
    !
    access-list 100 permit ip 173.1.4.0 0.0.0.255 232.0.0.0 0.255.255.255
    access-list 100 permit ip 173.1.5.0 0.0.0.255 232.0.0.0 0.255.255.255
    !
    crypto gdoi group GETVPN_GROUP
    identity number 1234
    server local
    rekey authentication mypubkey rsa GETVPN_KEYS
    rekey transport unicast
    sa ipsec 1
    profile GETVPN_PROFILE
    match address ipv4 100
    replay time window-size 5
    address ipv4 150.1.5.5
    redundancy
    local priority 50
    peer address ipv4 150.1.4.4

    This completes the KOOP Key Server configuration part. The next part, which is relatively simple, is configuring both routers as group members. As a group member, R4 should register to R5 and vice versa. Notice that there could be a separate ISAKMP policy used for GM/KS communications, but we just re-use the same settings.

    GM-R4:
    crypto isakmp policy 50
    encr 3des
    hash md5
    authentication pre-share
    group 2
    !
    crypto gdoi group GETVPN_GROUP_GM
    identity number 1234
    server address ipv4 150.1.5.5

    crypto map GETVPN_MAP local-address Loopback0
    crypto map GETVPN_MAP 10 gdoi
    set group GETVPN_GROUP_GM
    !
    interface Serial0/1/0
    crypto map GETVPN_MAP

    GM-R5:
    crypto isakmp policy 50
    encr 3des
    hash md5
    authentication pre-share
    group 2
    !
    crypto gdoi group GETVPN_GROUP_GM
    identity number 1234
    server address ipv4 150.1.4.4

    crypto map GETVPN_MAP local-address Loopback0
    crypto map GETVPN_MAP 10 gdoi
    set group GETVPN_GROUP_GM
    !
    interface Serial0/1/0
    crypto map GETVPN_MAP

    Both GM crypto-maps use Loopback0 as the source interface, but this only affects the ISAMP phase, as GET VPN by design simply copies the original header. The last two steps complete the two-node GET VPN configuration. Now for verification. – start by checking for KOOP KS:

    Rack1R4#show crypto gdoi ks 
    Total group members registered to this box: 1

    Key Server Information For Group GETVPN_GROUP:
    Group Name : GETVPN_GROUP
    Group Identity : 1234
    Group Members : 1
    IPSec SA Direction : Both
    ACL Configured:
    access-list 100
    Redundancy : Configured
    Local Address : 150.1.4.4
    Local Priority : 100
    Local KS Status : Alive
    Local KS Role : Primary

    Rack1R5#show crypto gdoi ks
    Total group members registered to this box: 2

    Key Server Information For Group GETVPN_GROUP:
    Group Name : GETVPN_GROUP
    Group Identity : 1234
    Group Members : 2
    IPSec SA Direction : Both
    ACL Configured:
    access-list 100
    Redundancy : Configured
    Local Address : 150.1.5.5
    Local Priority : 50
    Local KS Status : Alive
    Local KS Role : Secondary

    Check the data-plane status (IPSec SAs):

    Rack1R4#show crypto gdoi ipsec sa 
    

    SA created for group GETVPN_GROUP:

    SA created for group GETVPN_GROUP_GM:
    Serial0/1/0:
    protocol = ip
    local ident = 173.1.4.0/24, port = 0
    remote ident = 232.0.0.0/8, port = 0
    direction: Both, replay(method/window): Time/5 sec
    protocol = ip
    local ident = 173.1.5.0/24, port = 0
    remote ident = 232.0.0.0/8, port = 0
    direction: Both, replay(method/window): Time/5 sec

    Rack1R5#show crypto gdoi ipsec sa

    SA created for group GETVPN_GROUP:

    SA created for group GETVPN_GROUP_GM:
    Serial0/1/0:
    protocol = ip
    local ident = 173.1.4.0/24, port = 0
    remote ident = 232.0.0.0/8, port = 0
    direction: Both, replay(method/window): Time/5 sec
    protocol = ip
    local ident = 173.1.5.0/24, port = 0
    remote ident = 232.0.0.0/8, port = 0
    direction: Both, replay(method/window): Time/5 sec

    Now initiate some multicast traffic and ensure it is getting encrypted: The test below assumes R4 has joined the respective multicast group:

    Rack1R5#ping 232.1.1.1 source fastEthernet 0/1 repeat 100
    

    Type escape sequence to abort.
    Sending 100, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
    Packet sent with a source address of 173.1.5.5

    Reply to request 0 from 173.1.45.4, 40 ms
    Reply to request 1 from 173.1.45.4, 36 ms

    Rack1R4#show crypto ipsec sa

    interface: Serial0/1/0

    protected vrf: (none)
    local ident (addr/mask/prot/port): (173.1.5.0/255.255.255.0/0/0)
    remote ident (addr/mask/prot/port): (232.0.0.0/255.0.0.0/0/0)
    current_peer 0.0.0.0 port 848
    PERMIT, flags={origin_is_acl,}
    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
    #pkts decaps: 107, #pkts decrypt: 107, #pkts verify: 107
    #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

    local crypto endpt.: 150.1.4.4, remote crypto endpt.: 0.0.0.0
    path mtu 1500, ip mtu 1500, ip mtu idb Serial0/0/0
    current outbound spi: 0xF66A6278(4134167160)
    PFS (Y/N): N, DH group: none

    inbound esp sas:
    spi: 0xF66A6278(4134167160)
    transform: esp-3des esp-md5-hmac ,
    in use settings ={Tunnel, }
    conn id: 2011, flow_id: FPGA:11, sibling_flags 80000040, crypto map: GETVPN_MAP
    sa timing: remaining key lifetime (sec): (2387)
    IV size: 8 bytes
    replay detection support: Y replay window size: 5
    Status: ACTIVE

    inbound ah sas:

    inbound pcp sas:

    outbound esp sas:
    spi: 0xF66A6278(4134167160)
    transform: esp-3des esp-md5-hmac ,
    in use settings ={Tunnel, }
    conn id: 2012, flow_id: FPGA:12, sibling_flags 80000040, crypto map: GETVPN_MAP
    sa timing: remaining key lifetime (sec): (2387)
    IV size: 8 bytes
    replay detection support: Y replay window size: 5
    Status: ACTIVE

    outbound ah sas:

    outbound pcp sas:

    This final test ensures that our two-node configuration is working. Finally, this type of configuration is just a curious example, which probably has little application in real life, where you probably want a dedicated GET VPN Server. However, from the CCIE Security Lab standpoint it is important to understand the interaction between GET VPN components and know the little tricks that could be used.

    © 2024 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
    instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo