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.
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.5Now 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 CISCO1234After 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.4This 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_MAPBoth 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 : SecondaryCheck 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 secNow 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.
0 comments:
Post a Comment