Skip to main content

GET VPN - part four (multicast)

For an enterprise solution some of my current setting can be ineffective. For example re-keying method via an unicast. GET VPN allows on a multicast re-keying method. Let’s try to configure it.






On KSs we need to add:
 
!
access-list 1 permit 239.192.1.190 0.0.0.0
!
ip multicast-routing
ip pim ssm range 1
!
interface fa0/0
ip pim sparse-mode
!
ip access-list extended GETVPN-MCAST
permit ip any host 239.192.1.190
!
crypto gdoi group GDOI-GROUP
server local
no rekey transport unicast
rekey address ipv4 GETVPN-MCAST
rekey retransmit 10 number 3

Once I applied the configuration I can see:

*Dec 15 01:03:10.979: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 6.6.6.2 on interface FastEthernet0/0
*Dec 15 01:03:11.355: %SYS-5-CONFIG_I: Configured from console by console
*Dec 15 01:03:11.355: %GDOI-5-POLICY_CHANGE: GDOI group GDOI-GROUP policy has changed. Use 'crypto gdoi ks rekey' to send a rekey, or the changes will be send in the next scheduled rekey

Now I apply following changes on GMs:

!
access-list 1 permit 239.192.1.190 0.0.0.0
!
ip multicast-routing
ip igmp ssm-map enable
ip pim ssm range 1
!
interface FastEthernet0/0
ip pim sparse-mode
ip igmp join-group 239.192.1.190 source 3.3.3.2
ip igmp join-group 239.192.1.190 source 6.6.6.2
!

As you see below some changes are required on the ASA:

%ASA-7-710006: PIM request discarded from 3.3.3.2 to keys1:224.0.0.13
%ASA-7-710006: PIM request discarded from 6.6.6.2 to keys2:224.0.0.13
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.1.40
%ASA-7-710006: PIM request discarded from 7.7.7.2 to spoke1:224.0.0.13
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:239.192.1.190
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.1.40
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:239.192.1.190
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.1.40
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.1.40
%ASA-7-710006: PIM request discarded from 3.3.3.2 to keys1:224.0.0.13
%ASA-7-710006: PIM request discarded from 6.6.6.2 to keys2:224.0.0.13
%ASA-7-710006: PIM request discarded from 7.7.7.2 to spoke1:224.0.0.13
%ASA-7-710006: IGMP request discarded from 6.6.6.2 to keys2:224.0.0.1
%ASA-7-710006: IGMP request discarded from 6.6.6.2 to keys2:224.0.1.40
%ASA-7-710006: PIM request discarded from 3.3.3.2 to keys1:224.0.0.13
%ASA-7-710006: PIM request discarded from 6.6.6.2 to keys2:224.0.0.13
%ASA-7-710006: PIM request discarded from 7.7.7.2 to spoke1:224.0.0.13
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:239.192.1.190
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.1.40
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.1.40
%ASA-7-710006: PIM request discarded from 3.3.3.2 to keys1:224.0.0.13
%ASA-7-710006: PIM request discarded from 6.6.6.2 to keys2:224.0.0.13
%ASA-7-710006: PIM request discarded from 7.7.7.2 to spoke1:224.0.0.13
%ASA-7-710006: IGMP request discarded from 6.6.6.2 to keys2:224.0.0.1
%ASA-7-710006: IGMP request discarded from 6.6.6.2 to keys2:224.0.1.40
%ASA-7-710006: PIM request discarded from 3.3.3.2 to keys1:224.0.0.13
%ASA-7-710006: PIM request discarded from 6.6.6.2 to keys2:224.0.0.13
%ASA-7-710006: PIM request discarded from 7.7.7.2 to spoke1:224.0.0.13
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:239.192.1.190
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.1.40
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.1.40
%ASA-7-710006: PIM request discarded from 3.3.3.2 to keys1:224.0.0.13
%ASA-7-710006: PIM request discarded from 6.6.6.2 to keys2:224.0.0.13
%ASA-7-710006: PIM request discarded from 7.7.7.2 to spoke1:224.0.0.13
%ASA-7-710006: IGMP request discarded from 6.6.6.2 to keys2:224.0.0.1
%ASA-7-710006: IGMP request discarded from 6.6.6.2 to keys2:224.0.1.40
%ASA-7-710006: PIM request discarded from 3.3.3.2 to keys1:224.0.0.13
%ASA-7-710006: PIM request discarded from 6.6.6.2 to keys2:224.0.0.13
%ASA-7-710006: PIM request discarded from 7.7.7.2 to spoke1:224.0.0.13
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.1.40
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:239.192.1.190
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 5.5.5.2 to spoke3:224.0.1.40
%ASA-7-710006: PIM request discarded from 5.5.5.2 to spoke3:224.0.0.13
%ASA-7-710006: IGMP request discarded from 5.5.5.2 to spoke3:224.0.0.1
%ASA-7-710006: IGMP request discarded from 5.5.5.2 to spoke3:239.192.1.190
%ASA-7-710006: IGMP request discarded from 5.5.5.2 to spoke3:224.0.1.40
%ASA-7-710006: IGMP request discarded from 5.5.5.2 to spoke3:239.192.1.190
%ASA-7-710006: IGMP request discarded from 5.5.5.2 to spoke3:224.0.1.40
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.1.40
%ASA-7-710006: PIM request discarded from 3.3.3.2 to keys1:224.0.0.13
%ASA-7-710006: PIM request discarded from 6.6.6.2 to keys2:224.0.0.13
%ASA-7-710006: PIM request discarded from 7.7.7.2 to spoke1:224.0.0.13
%ASA-7-710006: IGMP request discarded from 4.4.4.2 to spoke2:224.0.1.40
%ASA-7-710006: PIM request discarded from 4.4.4.2 to spoke2:224.0.0.13
%ASA-7-710006: IGMP request discarded from 4.4.4.2 to spoke2:224.0.0.1
%ASA-7-710006: IGMP request discarded from 4.4.4.2 to spoke2:239.192.1.190
%ASA-7-710006: IGMP request discarded from 4.4.4.2 to spoke2:224.0.1.40
%ASA-7-710006: IGMP request discarded from 4.4.4.2 to spoke2:239.192.1.190
%ASA-7-710006: IGMP request discarded from 4.4.4.2 to spoke2:224.0.1.40
%ASA-7-710006: IGMP request discarded from 6.6.6.2 to keys2:224.0.0.1
%ASA-6-302010: 1 in use, 3 most used
%ASA-7-710006: PIM request discarded from 5.5.5.2 to spoke3:224.0.0.13
%ASA-7-710006: IGMP request discarded from 6.6.6.2 to keys2:224.0.1.40
%ASA-7-710006: PIM request discarded from 3.3.3.2 to keys1:224.0.0.13
%ASA-7-710006: PIM request discarded from 6.6.6.2 to keys2:224.0.0.13
%ASA-7-710006: PIM request discarded from 7.7.7.2 to spoke1:224.0.0.13
%ASA-7-710006: PIM request discarded from 4.4.4.2 to spoke2:224.0.0.13
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:239.192.1.190
%ASA-7-710006: IGMP request discarded from 7.7.7.2 to spoke1:224.0.1.40
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.0.1
%ASA-7-710006: IGMP request discarded from 3.3.3.2 to keys1:224.0.1.40
%ASA-7-710006: PIM request discarded from 5.5.5.2 to spoke3:224.0.0.13
%ASA-7-710006: IGMP request discarded from 5.5.5.2 to spoke3:224.0.0.1

I missed to enable multicast routing on the ASA:

asa1(config)# multicast-routing

And it solved all problems:

asa1(config)# multicast-routing
%ASA-7-609001: Built local-host identity:5.5.5.1
%ASA-7-609001: Built local-host spoke3:224.0.0.13
%ASA-7-609001: Built local-host identity:7.7.7.1
%ASA-7-609001: Built local-host spoke1:224.0.0.13
%ASA-7-609001: Built local-host identity:3.3.3.1
%ASA-7-609001: Built local-host keys1:224.0.0.13
%ASA-7-609001: Built local-host identity:8.8.8.1
%ASA-7-609001: Built local-host caserver:224.0.0.13
%ASA-7-609001: Built local-host identity:4.4.4.1
%ASA-7-609001: Built local-host spoke2:224.0.0.13
%ASA-7-609001: Built local-host identity:6.6.6.1
%ASA-7-609001: Built local-host keys2:224.0.0.13
asa1(config)# %ASA-7-609001: Built local-host keys2:224.0.0.1
%ASA-7-609001: Built local-host spoke2:224.0.0.1
%ASA-7-609001: Built local-host caserver:224.0.0.1
%ASA-7-609001: Built local-host keys1:224.0.0.1
%ASA-7-609001: Built local-host spoke1:224.0.0.1
%ASA-7-609001: Built local-host spoke3:224.0.0.1
%ASA-5-111008: User 'enable_15' executed the 'multicast-routing' command.
%ASA-5-111010: User 'enable_15', running 'CLI' from IP 0.0.0.0, executed 'multicast-routing'
%ASA-7-609001: Built local-host identity:224.0.0.13
%ASA-7-609001: Built local-host spoke1:7.7.7.2
%ASA-7-609001: Built local-host spoke3:5.5.5.2
%ASA-7-609001: Built local-host spoke2:4.4.4.2
%ASA-7-609001: Built local-host identity:239.192.1.190
%ASA-7-609001: Built local-host identity:224.0.1.40

Let’s check now if GMs can re-key:

R5#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
R5#
*Dec 15 01:41:45.774: %GDOI-4-GM_RE_REGISTER: The IPSec SA created for group GDOI-GROUP may have expired/been cleared, or didn't go through. Re-register to KS.
R5#
*Dec 15 01:41:45.794: %CRYPTO-5-GM_REGSTER: Start registration to KS 3.3.3.2 for group GDOI-GROUP using address 5.5.5.2
*Dec 15 01:41:45.986: %IGMP-3-NO_DNS_SERVER: No DNS server is configured.
DNS-based SSM mapping should be disabled if no DNS server is configured.
R5#
*Dec 15 01:41:46.598: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated
*Dec 15 01:41:46.602: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
R5#

 
 
R5#sh crypto gdoi
GROUP INFORMATION

    Group Name               : GDOI-GROUP
    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             : 5.5.5.2          vrf: None
       Version               : 1.0.4
       Registration status   : Registering
       Registering to        : 3.3.3.2
       Re-registers in       : 33 sec
       Succeeded registration: 0
       Attempted registration: 1
       Last rekey from       : 0.0.0.0
       Last rekey seq num    : 0
       Multicast rekey rcvd  : 0
       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 0
       After latest register : 0
       Rekey Received        : never

 ACL Downloaded From KS 3.3.3.2:

KEK POLICY:
    Rekey Transport Type     : Multicast
    Lifetime (secs)          : 79559
    Encrypt Algorithm        : 3DES
    Key Size                 : 192
    Sig Hash Algorithm       : HMAC_AUTH_SHA
    Sig Key Length (bits)    : 1024

TEK POLICY for the current KS-Policy ACEs Downloaded:

R5#

As you see above the ‘Rekey Transport Type’ is 'Multicast’.



Let’s check the KS:



R2#sh crypto gdoi
GROUP INFORMATION

    Group Name               : GDOI-GROUP (Multicast)
    Group Identity           : 1
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Group Members            : 3
    IPSec SA Direction       : Both
    Redundancy               : Configured
        Local Address        : 6.6.6.2
        Local Priority       : 20
        Local KS Status      : Alive
        Local KS Role        : Primary
        Local KS Version     : 1.0.4
    Group Rekey Lifetime     : 86400 secs
    Group Rekey
        Remaining Lifetime   : 79479 secs
    Rekey Retransmit Period  : 10 secs
    Rekey Retransmit Attempts: 3
    Group Retransmit
        Remaining Lifetime   : 0 secs

      IPSec SA Number        : 1
      IPSec SA Rekey Lifetime: 3600 secs
      Profile Name           : IPSEC-PROFILE
      Replay method          : Count Based
      Replay Window Size     : 64
      SA Rekey
         Remaining Lifetime  : 3105 secs
      ACL Configured         : access-list 101

     Group Server list       : Local



R2#

I renew now all keys on GMs:

R2#crypto gdoi ks rekey replace-now

% There has not been a GDOI policy change for group GDOI-GROUP, a rekey is not needed

Are you sure you want to proceed ? [yes/no]: yes
R2#
*Dec 15 01:45:01.838: %GDOI-5-KS_SEND_MCAST_REKEY: Sending Multicast Rekey with policy-replace now for group GDOI-GROUP from address 6.6.6.2 to  with seq # 30
R2#

and check one of the GMs:

R5#sh crypto gdoi
GROUP INFORMATION

    Group Name               : GDOI-GROUP
    Group Identity           : 1
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Rekeys received          : 7
    IPSec SA Direction       : Both

     Group Server list       : 3.3.3.2
                               6.6.6.2

    Group member             : 5.5.5.2          vrf: None
       Version               : 1.0.4
       Registration status   : Registered
       Registered with       : 3.3.3.2
       Re-registers in       : 87 sec
       Succeeded registration: 1
       Attempted registration: 1
       Last rekey from       : 6.6.6.2
       Last rekey seq num    : 0
       Multicast rekey rcvd  : 7
       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 7
       After latest register : 7
       Rekey Rcvd(hh:mm:ss)  : 00:00:51

 ACL Downloaded From KS 6.6.6.2:
   access-list   permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255

KEK POLICY:
    Rekey Transport Type     : Multicast
    Lifetime (secs)          : 247
    Encrypt Algorithm        : 3DES
    Key Size                 : 192
    Sig Hash Algorithm       : HMAC_AUTH_SHA
    Sig Key Length (bits)    : 1024

TEK POLICY for the current KS-Policy ACEs Downloaded:
  FastEthernet0/0:
    IPsec SA:
        spi: 0x9F4270AB(2671931563)
        transform: esp-3des esp-sha-hmac
        sa timing:remaining key lifetime (sec): (3268)
        Anti-Replay : Disabled

    IPsec SA:
        spi: 0x918330E8(2441294056)
        transform: esp-3des esp-sha-hmac
        sa timing:remaining key lifetime (sec): (1640)
        Anti-Replay : Disabled


R5#

Above output shows correct re-keying method and it already received 7 multicast re-keys.

Useful link: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_igmp/configuration/15-mt/imc-igmp-15-mt-book/imc_customizing_igmp.html#GUID-E32E0CB2-10AD-429C-96E7-ED011A69F9BB
Labels:

Comments

Post a Comment

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an
8 comments
Read more

MAC Authentication Bypass

One of the method to control your network is using MAB feature. It is helpful in case you have devices without dot1x functionality. Today I will try to implement basic configuration and analyze log messages. There is only one switch SW1 and one device attached to port Fa1/0/2.   ! aaa new - model aaa authentication dot1x default group radius ! ! int Fas1 / 0 / 2 authentication host - mode single - host authentication port - control auto mab ! I haven’t configured ACS yet but let’s see what error message I receive:   SW1 ( config - if ) # mab - ev ( Fa1 / 0 / 2 ): Received MAB context create from AuthMgr mab - ev ( Fa1 / 0 / 2 ): Created MAB client context 0x1100000F mab : initial state mab_initialize has enter mab - ev ( Fa1 / 0 / 2 ): Sending create new context event to EAP from MAB for 0x1100000F ( 0000.0000 . 0000 ) mab - sm ( Fa1 / 0 / 2 ): Received event 'MAB_START' on handle 0x1100000F mab : during state mab_initia
Post a Comment
Read more

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze the packet flo
1 comment
Read more