GET VPN - part seven (NAT)
Today I would like to test how GET VPN cooperates with NAT. I need to say but officially NAT for GET VPN is not supported by Cisco. You can encrypt traffic on a GM, just before encryption/decryption. Anyway I would like to test my below two case scenarios:
1) GM behind NAT
2)KS behind NAT
3) NAT on GM (supported)
I will work on the same design:
1) GM behind NAT
Now I add a NAT statement on the ASA for GM1 (R3):
object network R3-MNG-BN
host 7.7.7.2
object network R3-MNG-AN
host 77.77.77.2
nat (spoke1-mng,any) source static R3-MNG-BN R3-MNG-AN
On the ASA I need to add one acl entry:
access-list SPOKE1-MNG extended permit udp host 7.7.7.2 host 6.6.6.2 eq 4500
access-list SPOKE1-MNG extended permit udp host 7.7.7.2 host 3.3.3.2 eq 4500
and then we can see:
%ASA-6-302015: Built inbound UDP connection 62 for spoke1-mng:7.7.7.2/4500 (77.77.77.2/4500) to keys2:6.6.6.2/4500 (6.6.6.2/4500)
Let’s check the status of R3:
R3#sh crypto gdoi
GROUP INFORMATION
Group Name : GDOI-GROUP-GREEN
Group Identity : 1
Crypto Path : ipv4
Key Management Path : ipv4
Rekeys received : 0
IPSec SA Direction : Both
Group Server list : 3.3.3.2
6.6.6.2
Group member : 7.7.7.2 vrf: MNG
Version : 1.0.4
Registration status : Registered
Registered with : 6.6.6.2
Re-registers in : 191 sec
Succeeded registration: 1
Attempted registration: 6
Last rekey from : 0.0.0.0
...
Looks good, status is ‘registered’.
Now KS’ should see the R3 with IP of 77.77.77.2:
R2#sh crypto gdoi ks members
Group Member Information :
Number of rekeys sent for group GDOI-GROUP-RED : 0
Group Member ID : 77.77.77.2 GM Version: 1.0.4
Group ID : 2
Group Name : GDOI-GROUP-RED
Key Server ID : 6.6.6.2
Rekeys sent : 0
Rekeys retries : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0
Group Member ID : 4.4.4.2 GM Version: 1.0.4
Group ID : 2
Group Name : GDOI-GROUP-RED
Key Server ID : 3.3.3.2
Rekeys sent : 0
Rekeys retries : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0
Group Member ID : 5.5.5.2 GM Version: 1.0.4
Group ID : 2
Group Name : GDOI-GROUP-RED
Key Server ID : 3.3.3.2
Rekeys sent : 0
Rekeys retries : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0
Number of rekeys sent for group GDOI-GROUP-GREEN : 0
Group Member ID : 5.5.5.2 GM Version: 1.0.4
Group ID : 1
Group Name : GDOI-GROUP-GREEN
Key Server ID : 6.6.6.2
Rekeys sent : 0
Rekeys retries : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0
Group Member ID : 77.77.77.2 GM Version: 1.0.4
Group ID : 1
Group Name : GDOI-GROUP-GREEN
Key Server ID : 6.6.6.2
Rekeys sent : 0
Rekeys retries : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0
Group Member ID : 4.4.4.2 GM Version: 1.0.4
Group ID : 1
Group Name : GDOI-GROUP-GREEN
Key Server ID : 3.3.3.2
Rekeys sent : 0
Rekeys retries : 0
Rekey Acks Rcvd : 0
Rekey Acks missed : 0
Sent seq num : 0 0 0 0
Rcvd seq num : 0 0 0 0
R2#
Let’s test the connectivity:
R3#ping vrf RED 20.55.55.55 source 20.33.33.33
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.55.55.55, timeout is 2 seconds:
Packet sent with a source address of 20.33.33.33
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 96/102/108 ms
R3#
R3#ping vrf RED 20.44.44.44 source 20.33.33.33
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.44.44.44, timeout is 2 seconds:
Packet sent with a source address of 20.33.33.33
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/95/100 ms
R3#
Everything works fine. I check the status of ESP sessions on ASA:
asa2(config)# sh conn | i ESP
ESP spoke2-red 20.44.44.44 spoke1-red20.33.33.33, idle 0:00:16, bytes 620
ESP spoke2-red 20.44.44.44 spoke1-red20.33.33.33, idle 0:00:16, bytes 620
asa2(config)#
There is no problem to have one or more GMs behid NAT. I need to only permit UDP/4500. Problems start during re-keying. I don’t know why (I only guess that it happens because GET VPN preserve IP header and addressing:
the original IP address is still 6.6.6.2 and only IP in a new IP header is 16.16.16.12, the other reason can be synchronization process between KS’, they exchanges GMs list) but even there is no line in the GM1 configuration I see it tries to contact with KS2 using a real IP:
2)KS behind NAT
In my second case one KS (r2) is behind NAT. I have to remove first all above changes before I start.
a) NAT - on the ASA I need to add the NAT statement. The second KS will be available with IP: 16.16.16.12:
object network R2-BN
host 6.6.6.2
object network R2-AN
host 16.16.16.12
nat (keys1,spoke1-mng) source static R2-BN R-AN
b) GM configuration - I need to add the new KS:
!
crypto gdoi group GDOI-GROUP-GREEN
identity number 1
server address ipv4 3.3.3.2
server address ipv4 16.16.16.12
client registration interface FastEthernet0/0.1
!
crypto gdoi group GDOI-GROUP-RED
identity number 2
server address ipv4 3.3.3.2
server address ipv4 16.16.16.12
client registration interface FastEthernet0/0.1
!
c) ACL - I see deny messages and I have to add the connection to the ACL
%ASA-4-106023: Deny udp src spoke1-mng:7.7.7.2/4500 dst keys2:6.6.6.2/4500 by access-group "SPOKE1-MNG" [0x0]
access-list SPOKE1-MNG extended permit udp host 7.7.7.2 host 6.6.6.2 eq 4500
asa2(config)# sh conn | i 4500
UDP spoke1-mng 7.7.7.2:4500 keys2 6.6.6.2:4500, idle 0:01:35, bytes 2496, flags -
asa2(config)#
I check now if the GM1 is registered:
R3#sh crypto gdoi
GROUP INFORMATION
Group Name : GDOI-GROUP-GREEN
Group Identity : 1
Crypto Path : ipv4
Key Management Path : ipv4
Rekeys received : 2
IPSec SA Direction : Both
Group Server list : 16.16.16.12
Group member : 7.7.7.2 vrf: MNG
Version : 1.0.4
Registration status : Registered
Registered with : 16.16.16.12
Re-registers in : 139 sec
Succeeded registration: 1
Attempted registration: 2
Last rekey from : 6.6.6.2
Last rekey seq num : 0
Unicast rekey received: 2
Rekey ACKs sent : 2
Rekey Rcvd(hh:mm:ss) : 00:00:34
allowable rekey cipher: any
allowable rekey hash : any
allowable transformtag: any ESP
...
Looks good. The one thing, as in the first scenario, ‘last rekey from’ is 6.6.6.2.
On ASA I see also some attempts despite fact there is no config line with the IP (6.6.6.2).
%ASA-4-106023: Deny udp src spoke1-mng:7.7.7.2/848 dst keys2:6.6.6.2/848 by access-group "SPOKE1-MNG" [0x0, 0x0]
%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for udp src spoke1-mng:7.7.7.2/848 dst keys2:6.6.6.2/848 denied due to NAT reverse path failure
Conclusions - sometimes non-supported solutions are common even in production networks, but for these two cases I wouldn’t take any risk.
3) NAT on GM
I implement NAT for LAN1 (vrf GREEN, subnet 10.33.33.0/24) on the GM1. I need to update the policy on KS’ (access-list 101 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255). Let’s test it by changing the real IP from 10.33.33.33 to 100.33.33.33 and I keep the same settings on KS’.
Before I start I do one test to be sure the GET VPN work fine:
R5#ping vrf GREEN 10.33.33.33 source 10.55.55.55
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.33.33, timeout is 2 seconds:
Packet sent with a source address of 10.55.55.55
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/93/112 ms
R5#
On ASA I can see:
%ASA-7-609001: Built local-host spoke3-green:10.55.55.55
%ASA-7-609001: Built local-host spoke1-green:10.33.33.33
a) new IP
R3#sh run int loo0
Building configuration...
Current configuration : 91 bytes
!
interface Loopback0
ip vrf forwarding GREEN
ip address 100.33.33.33 255.255.255.0
end
R3#
b) routing
asa2(config)# route spoke1-green 100.33.33.0 255.255.255.0 17.17.17.2
and test:
asa2(config)# ping 100.33.33.33
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.33.33.33, timeout is 2 seconds:
?!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 30/32/40 ms
asa2(config)#
and one more test to be sure we don’t receive icmp reply from 10.33.33.33:
asa2(config)# ping 10.33.33.33
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.33.33, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)
asa2(config)#
c) NAT
R3(config)#ip nat inside source static 100.33.33.33 10.33.33.33 vrf GREEN
R3(config)#interface FastEthernet0/0.2
R3(config-subif)#ip nat outside
R3(config-subif)#
R3(config-subif)#int loo0
R3(config-if)#ip nat inside
R3(config-if)#end
R3#
Let’s do the same test from ASA:
asa2(config)# ping 10.33.33.33
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.33.33, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 30/32/40 ms
asa2(config)#
On the GM1 we see the translation:
R3#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 10.33.33.33:5313 100.33.33.33:5313 17.17.17.1:5313 17.17.17.1:5313
--- 10.33.33.33 100.33.33.33 --- ---
R3#
I test it once again from R5:
R5#ping vrf GREEN 10.33.33.33 source 10.55.55.55
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.33.33.33, timeout is 2 seconds:
Packet sent with a source address of 10.55.55.55
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/105/132 ms
R5#
on the R3 we can see:
R3#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 10.33.33.33:7 100.33.33.33:7 10.55.55.55:7 10.55.55.55:7
icmp 10.33.33.33:8 100.33.33.33:8 10.55.55.55:8 10.55.55.55:8
icmp 10.33.33.33:9 100.33.33.33:9 10.55.55.55:9 10.55.55.55:9
icmp 10.33.33.33:10 100.33.33.33:10 10.55.55.55:10 10.55.55.55:10
icmp 10.33.33.33:11 100.33.33.33:11 10.55.55.55:11 10.55.55.55:11
icmp 10.33.33.33:12 100.33.33.33:12 10.55.55.55:12 10.55.55.55:12
--- 10.33.33.33 100.33.33.33 --- ---
R3#
I think we can consider above tests as a prove the NAT work fine.