Skip to main content

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

FortiGate and GRE tunnel

Recently I worked on one project where a client requested to re-route web traffic to the GRE tunnel to perform traffic inspection. I would like to share with you what is required if you configure it on FortiGate. We need a new GRE interface and policy base routing (PBR) to change the route for specific source IPs. Of course you need firewall policies to permit the traffic. Let's start with GRE interface. Unfortunately you can't configure it using the GUI, only CLI is the option: config system gre-tunnel edit "gre1" set interface "port1" set local-gw 55.55.55.55 set remote-gw 44.44.44.44 next end When the end peer is Cisco router, you need to set the IP for the GRE interface: config system interface edit gre1 set ip 192.168.10.10 255.255.255.255 set remote-ip192.168.10.20 end In next step we need to fix routing. We need the alternate path via GRE but to keep the route in the active routing table you need to set the same AD (adminis...
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 ...
1 comment
Read more