Sunday, November 23, 2014

Remote Access VPN (IPsec) - IOS - isakmp/ipsec profiles

The last requirement from my previous post is controlling what kind of traffic a VPN user can send over the tunnel. On Cisco ASA you can easily add vpn-filter to the group policy:

Asa1(config)# group-policy MyGroup attributes
Asa1(config-group-policy)# vpn-filter acl_vpn

but here with IOS we don’t have such possibility. The first solution is a radius server and configuration of downloadable ACLs per user. If you don’t have any external server you can change the config a bit and start using VTIs (Virtual Tunnel Interface) along with isakmp and ipsec profiles. Let’s start.
First, I have to add the isakmp profile and match all the setting I configured previously under the crypto map:
 
!
crypto isakmp profile ISAKMP-PRF
 match identity group CG
 client authentication list USERS
 isakmp authorization list AUTH-LIST
 client configuration address respond
 client configuration group CG
 virtual-template 1
!

Next I have to add the ipsec profile:
 
!
crypto ipsec profile IPSEC-PRF
 set isakmp-profile ISAKMP-PRF
 set transform-set TS
 set reverse-route tag 1
!

And the last step is adding the virtual interface with the ipsec profile:
 
!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PRF
!

Let’s try know but first remember to remove the crypto map from fa0/0.
Ok, the tunnel is up. Let’s check how look like isakmp sa:
 
R14#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.0.0.2        192.168.202.152 QM_IDLE           1002 ACTIVE

IPv6 Crypto ISAKMP SA

R14#
R14#
R14#sh crypto isakmp sa d
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF  Status Encr Hash   Auth DH Lifetime Cap.

1002  10.0.0.2        192.168.202.152        ACTIVE aes  sha         2  23:57:46 CX
       Engine-id:Conn-id =  SW:2

IPv6 Crypto ISAKMP SA

R14#

When we check interfaces we can see two more, virtual-template and virtual-access ones:
 
R14#sh ip int b
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/0        10.0.0.2        YES manual up                    up
FastEthernet0/1        unassigned      YES unset  administratively down down
FastEthernet1/0        unassigned      YES unset  administratively down down
FastEthernet1/1        unassigned      YES unset  administratively down down
Loopback0              unassigned      YES unset  up                    up
Loopback7              7.7.7.7         YES manual up                    up
Loopback8              8.8.8.8         YES manual up                    up
Loopback9              9.9.9.9         YES manual up                    up
Loopback10             192.168.1.1     YES manual up                    up
Virtual-Access1        unassigned      NO  unset  up                    up
Virtual-Template1      unassigned      NO  unset  up                    down
R14#

The Virtual-Access1 is created when the tunnel is initiated.
I check now crypto session and you can notice the interface where the tunnel is terminated is not fa0/0 but Virtual-Access1:
 
R14#sh crypto session d
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: Virtual-Access1
Username: cisco
Profile: ISAKMP-PRF
Group: CG
Assigned address: 4.4.4.5
Uptime: 00:06:47
Session status: UP-ACTIVE
Peer: 192.168.202.152 port 51413 fvrf: (none) ivrf: (none)
      Phase1_id: CG
      Desc: (none)
  IKEv1 SA: local 10.0.0.2/500 remote 192.168.202.152/51413 Active
          Capabilities:CX connid:1002 lifetime:23:51:48
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 4.4.4.5
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 4370776/3192
        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 4370776/3192

R14#

This is the place where we can add the access list to control traffic inside the tunnel.
Requirements: Vpn users should be able to ping both hosts but telnet to only 7.7.7.7
 
access-list 105 permit icmp 4.4.4.0 0.0.0.255 host 8.8.8.8 log
access-list 105 permit icmp 4.4.4.0 0.0.0.255 host 7.7.7.7 log
access-list 105 permit tcp 4.4.4.0 0.0.0.255 host 7.7.7.7 eq telnet log
access-list 105 deny   ip any any log

and then I attach the acl to the virtual template interface. You can’t change any settings when the tunnel is up:
 
R14(config)#interface Virtual-Template1 type tunnel
% Virtual-template config is locked, active vaccess present
R14(config)#

!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 ip access-group 105 in
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PRF
!

Let’s test it now:

ra-ipsec2-1.jpg

There is a problem, as you see the traffic is encrypted but not decrypted. I see the new acl 105 works fine:
 
R14#
*Nov 23 23:00:54.947: %SEC-6-IPACCESSLOGDP: list 105 permitted icmp 4.4.4.23 -> 7.7.7.7 (8/0), 1 packet
R14#
*Nov 23 23:01:24.835: %SEC-6-IPACCESSLOGDP: list 105 permitted icmp 4.4.4.23 -> 8.8.8.8 (8/0), 1 packet
R14#

And counters look fine too:
 
R14#sh access-lists 105
Extended IP access list 105
    10 permit icmp 4.4.4.0 0.0.0.255 host 8.8.8.8 log (4 matches)
    20 permit icmp 4.4.4.0 0.0.0.255 host 7.7.7.7 log (4 matches)
    30 permit tcp 4.4.4.0 0.0.0.255 host 7.7.7.7 eq telnet log
    40 deny ip any any log (3 matches)
R14#

Let’s investigate…

1) Routing from vpn server to vpn user:
 
R14#sh ip route 4.4.4.23
Routing entry for 4.4.4.23/32
  Known via "static", distance 1, metric 0 (connected)
  Tag 1
  Routing Descriptor Blocks:
  * directly connected, via Virtual-Access1
      Route metric is 0, traffic share count is 1
      Route tag 1
R14#

After a while I discovered one problem here. If the next hop is Virtual-Access1 interface we need IP address there to allow routing to route packets. Because the Loo0 is related with this template I add the IP address on this one:
 
R14#sh run int Virtual-Template1
Building configuration...

Current configuration : 178 bytes
!
interface Virtual-Template1 type tunnel
 no ip address
 ip unnumbered Loopback0
 ip access-group 105 in
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PRF
end

R14#

R14#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R14(config)#int loo0
R14(config-if)#ip add
R14(config-if)#ip address 3.3.3.3 255.255.255.0
R14(config-if)#
 
And test it once again:

ra-ipsec2-2.jpg

Ok, everything works fine. I do one test more for telnet access:

*Nov 23 23:12:13.679: %SEC-6-IPACCESSLOGP: list 105 permitted tcp 4.4.4.24(49327) -> 7.7.7.7(23), 1 packet
*Nov 23 23:12:23.155: %SEC-6-IPACCESSLOGP: list 105 denied tcp 4.4.4.24(49328) -> 8.8.8.8(23), 1 packet

You see telnet access to 7.7.7.7 is allowed and to 8.8.8.8 is denied.
As you see the profiles are more flexible and you can implement them easily. You can add another isakmp and ipsec profiles if you need different policy.

No comments:

Post a Comment