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:
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:
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.