Sunday, December 21, 2014

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:


getvpn-1-IPheader.jpg


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:


getvpn-1-ws.jpg



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.

No comments:

Post a Comment