Skip to main content

GET VPN - part one

Today I would like to implement GET VPN solution based on following scenario:

getvpn-1.jpg

As you see there are many components like two key servers, CA server, three members and one firewall. I start the configuration with only one key server and without CA server. Later on I will add them to my design.

Key Server #1:
 
!
crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0
!
crypto ipsec transform-set TS esp-3des esp-sha-hmac
 mode tunnel
!
crypto ipsec profile IPSEC-PROFILE
 set transform-set TS
!
crypto gdoi group GDOI-GROUP
 identity number 1
 server local
  rekey retransmit 10 number 2
  rekey authentication mypubkey rsa GETVPN-KEY
  rekey transport unicast
  sa ipsec 1
   profile IPSEC-PROFILE
   match address ipv4 101
   replay counter window-size 64
  address ipv4 3.3.3.2
!
ip route 0.0.0.0 0.0.0.0 3.3.3.1
!
access-list 101 permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255
!

The first group member:

!
crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0
!
crypto gdoi group GDOI-GROUP
 identity number 1
 server address ipv4 3.3.3.2
!
crypto map MAPA 10 gdoi
 set group GDOI-GROUP
!
interface FastEthernet0/0
crypto map MAPA
!
ip route 0.0.0.0 0.0.0.0 4.4.4.1

The second group member:

!
crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
crypto isakmp key cisco address 0.0.0.0
!
crypto gdoi group GDOI-GROUP
 identity number 1
 server address ipv4 3.3.3.2
!
crypto map MAPA 10 gdoi
 set group GDOI-GROUP
!
interface FastEthernet0/0
 crypto map MAPA
!
ip route 0.0.0.0 0.0.0.0 7.7.7.1

I have the ASA in the middle and I need to allow pass the traffic between these routers.

ASA:

!
interface GigabitEthernet0
 nameif keys1
 security-level 80
 ip address 3.3.3.1 255.255.255.0
!
interface GigabitEthernet2
 nameif spoke1
 security-level 50
 ip address 7.7.7.1 255.255.255.0
!
interface GigabitEthernet3
 nameif spoke2
 security-level 50
 ip address 4.4.4.1 255.255.255.0
!
route spoke1 10.33.33.33 255.255.255.255 7.7.7.2 1
route spoke2 10.44.44.44 255.255.255.255 4.4.4.2 1
!
same-security-traffic permit inter-interface

The last above command allow on the communication between two group members (both with security level 50). By default the communication from Key Server1 to group members is permitted because from higher to lower security level is allowed by default.

Without access list that allows connect GMs and KS on ASA we can see:

%ASA-2-106006: Deny inbound UDP from 4.4.4.2/848 to 3.3.3.2/848 on interface spoke2
%ASA-2-106006: Deny inbound UDP from 7.7.7.2/848 to 3.3.3.2/848 on interface spoke1

Let’s fix it:

access-list SPOKE2 extended permit udp host 4.4.4.2 host 3.3.3.2 eq 848
access-list SPOKE1 extended permit udp host 7.7.7.2 host 3.3.3.2 eq 848

access-group SPOKE2 in interface spoke2
access-group SPOKE1 in interface spoke1

and when I reset gdoi on one of the spokes:

R3#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
R3#
*Dec 14 19:02:25.067: %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.
R3#
*Dec 14 19:02:25.075: %CRYPTO-5-GM_REGSTER: Start registration to KS 3.3.3.2 for group GDOI-GROUP using address 7.7.7.2
*Dec 14 19:02:25.583: %GDOI-5-GM_REKEY_TRANS_2_UNI: Group GDOI-GROUP transitioned to Unicast Rekey.
*Dec 14 19:02:25.587: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated
*Dec 14 19:02:25.587: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
*Dec 14 19:02:25.719: %GDOI-5-GM_REGS_COMPL: Registration to KS 3.3.3.2 complete for group GDOI-GROUP using address 7.7.7.2
*Dec 14 19:02:25.727: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 3.3.3.2 for group GDOI-GROUP & gm identity  7.7.7.2
R3#

on the ASA I see:

%ASA-6-302015: Built inbound UDP connection 97 for spoke1:7.7.7.2/848 (7.7.7.2/848) to keys1:3.3.3.2/848 (3.3.3.2/848)

Let’s check the status on r3:

R3#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
7.7.7.2         3.3.3.2         GDOI_REKEY        1012 ACTIVE
3.3.3.2         7.7.7.2         GDOI_IDLE         1011 ACTIVE

IPv6 Crypto ISAKMP SA

R3#

R3#sh crypto session  detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 0.0.0.0 port 848 fvrf: (none) ivrf: (none)
      Phase1_id: 3.3.3.2
      Desc: (none)
  IKEv1 SA: local 7.7.7.2/848 remote 3.3.3.2/848 Active
          Capabilities:(none) connid:1012 lifetime:0
  IKEv1 SA: local 7.7.7.2/848 remote 3.3.3.2/848 Active
          Capabilities:(none) connid:1011 lifetime:23:57:07
  IPSEC FLOW: permit ip 10.0.0.0/255.0.0.0 10.0.0.0/255.0.0.0
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) KB Vol Rekey Disabled/3428
        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) KB Vol Rekey Disabled/3428

R3#

R3#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

    Group member             : 7.7.7.2          vrf: None
       Version               : 1.0.4
       Registration status   : Registered
       Registered with       : 3.3.3.2
       Re-registers in       : 3270 sec
       Succeeded registration: 1
       Attempted registration: 1
       Last rekey from       : 0.0.0.0
       Last rekey seq num    : 0
       Unicast rekey received: 0
       Rekey ACKs sent       : 0
       Rekey Received        : never
       allowable rekey cipher: any
       allowable rekey hash  : any
       allowable transformtag: any ESP

    Rekeys cumulative
       Total received        : 0
       After latest register : 0
       Rekey Acks sents      : 0

 ACL Downloaded From KS 3.3.3.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     : Unicast
    Lifetime (secs)          : 86219
    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: 0xB3E251B2(3017953714)
        transform: esp-3des esp-sha-hmac
        sa timing:remaining key lifetime (sec): (3420)
        Anti-Replay : Disabled


R3#

On the KS we see:

R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
3.3.3.2         7.7.7.2         GDOI_IDLE         1009 ACTIVE
3.3.3.2         4.4.4.2         GDOI_IDLE         1010 ACTIVE

IPv6 Crypto ISAKMP SA

R1#

R1#sh crypto gdoi
GROUP INFORMATION

    Group Name               : GDOI-GROUP (Unicast)
    Group Identity           : 1
    Crypto Path              : ipv4
    Key Management Path      : ipv4
    Group Members            : 2
    IPSec SA Direction       : Both
    Group Rekey Lifetime     : 86400 secs
    Group Rekey
        Remaining Lifetime   : 86122 secs
    Rekey Retransmit Period  : 10 secs
    Rekey Retransmit Attempts: 2
    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  : 3323 secs
      ACL Configured         : access-list 101

     Group Server list       : Local

R1#

I try to ping LAN2 from LAN1:

R3#ping 10.44.44.44 source loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.44.44.44, timeout is 2 seconds:
Packet sent with a source address of 10.33.33.33
.....
Success rate is 0 percent (0/5)
R3#

Let’s check the firewall syslog:

%ASA-4-106023: Deny protocol 50 src spoke1:10.33.33.33 dst spoke2:10.44.44.44 by access-group "SPOKE1" [0x0, 0x0]

I need to add esp protocol to the SPOKE1 access list:

asa1(config)# access-list SPOKE1 extended permit esp host 10.33.33.33 host 10.44.44.44

I try once again:
 
R3#ping 10.44.44.44 source loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.44.44.44, timeout is 2 seconds:
Packet sent with a source address of 10.33.33.33
.....
Success rate is 0 percent (0/5)
R3#

and now on the ASA I see:

%ASA-4-106023: Deny protocol 50 src spoke2:10.44.44.44 dst spoke1:10.33.33.33 by access-group "SPOKE2" [0x0, 0x0]

Let’s add following acl entry:

asa1(config)# access-list SPOKE2 extended permit esp host 10.44.44.44 host 10.33.33.33

and last one chance:

R3#ping 10.44.44.44 source loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.44.44.44, timeout is 2 seconds:
Packet sent with a source address of 10.33.33.33
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/101/112 ms
R3#

check now if the ping was sent over the encrypted tunnel:

R3#sh crypto session  detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 0.0.0.0 port 848 fvrf: (none) ivrf: (none)
      Phase1_id: 3.3.3.2
      Desc: (none)
  IKEv1 SA: local 7.7.7.2/848 remote 3.3.3.2/848 Active
          Capabilities:(none) connid:1012 lifetime:0
  IKEv1 SA: local 7.7.7.2/848 remote 3.3.3.2/848 Active
          Capabilities:(none) connid:1011 lifetime:23:42:24
  IPSEC FLOW: permit ip 10.0.0.0/255.0.0.0 10.0.0.0/255.0.0.0
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 5 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2545
        Outbound: #pkts enc'ed 15 drop 0 life (KB/Sec) KB Vol Rekey Disabled/2545

R3#

As you see the tunnels are up and we can send traffic between LANs. In next step I add R5 as a spoke3. I copy the same settings from spoke2.

Once I finish I should see:

R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
3.3.3.2         7.7.7.2         GDOI_IDLE         1009 ACTIVE
3.3.3.2         4.4.4.2         GDOI_IDLE         1010 ACTIVE
3.3.3.2         5.5.5.2         GDOI_IDLE         1011 ACTIVE

IPv6 Crypto ISAKMP SA

R1#

On the new spoke we see:

R5#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
3.3.3.2         5.5.5.2         GDOI_IDLE         1001 ACTIVE
5.5.5.2         3.3.3.2         GDOI_REKEY        1002 ACTIVE

IPv6 Crypto ISAKMP SA

R5#

Let’s try to ping LAN1 and LAN2:

R5#ping 10.44.44.44 source loo0
*Dec 14 19:34:56.883: %SYS-5-CONFIG_I: Configured from console by console
R5#ping 10.44.44.44 source loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.44.44.44, timeout is 2 seconds:
Packet sent with a source address of 10.55.55.55
.....
Success rate is 0 percent (0/5)
R5#ping 10.33.33.33 source loo0
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 0 percent (0/5)
R5#

I need to add the new LAN to existing ACLs:

%ASA-4-106023: Deny protocol 50 src spoke2:10.44.44.44 dst spoke3:10.55.55.55 by access-group "SPOKE2" [0x0, 0x0]

%ASA-4-106023: Deny protocol 50 src spoke1:10.33.33.33 dst spoke3:10.55.55.55 by access-group "SPOKE1" [0x0, 0x0]

This is the final version:

asa1(config)# sh run access-list
access-list SPOKE2 extended permit udp host 4.4.4.2 host 3.3.3.2 eq 848
access-list SPOKE2 extended permit esp host 10.44.44.44 host 10.33.33.33
access-list SPOKE2 extended permit esp host 10.44.44.44 host 10.55.55.55
access-list SPOKE1 extended permit udp host 7.7.7.2 host 3.3.3.2 eq 848
access-list SPOKE1 extended permit esp host 10.33.33.33 host 10.44.44.44
access-list SPOKE1 extended permit esp host 10.33.33.33 host 10.55.55.55
access-list SPOKE3 extended permit udp host 5.5.5.2 host 3.3.3.2 eq 848
access-list SPOKE3 extended permit esp host 10.55.55.55 host 10.33.33.33
access-list SPOKE3 extended permit esp host 10.55.55.55 host 10.44.44.44

Now it looks much better:

R5#ping 10.33.33.33 source loo0
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/99/120 ms

R5#ping 10.44.44.44 source loo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.44.44.44, 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 = 88/104/116 ms
R5#

R5#sh crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 0.0.0.0 port 848 fvrf: (none) ivrf: (none)
      Phase1_id: 3.3.3.2
      Desc: (none)
  IKEv1 SA: local 5.5.5.2/848 remote 3.3.3.2/848 Active
          Capabilities:(none) connid:1001 lifetime:23:31:20
  IKEv1 SA: local 5.5.5.2/848 remote 3.3.3.2/848 Active
          Capabilities:(none) connid:1002 lifetime:0
  IPSEC FLOW: permit ip 10.0.0.0/255.0.0.0 10.0.0.0/255.0.0.0
        Active SAs: 4, origin: crypto map
        Inbound:  #pkts dec'ed 10 drop 0 life (KB/Sec) KB Vol Rekey Disabled/149
        Outbound: #pkts enc'ed 20 drop 0 life (KB/Sec) KB Vol Rekey Disabled/149

R5#
 
Ok, now everything works fine. In my next post I will add the second KS as a redundancy feature and next I change an authentication method from pre-shared key to a certificate.
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