Saturday, November 22, 2014

Remote Access VPN (IPsec) - IOS

Today I would like to implement remote access VPN (IPsec) on the cisco router. I check all features you can enable/disable.

ra-ipsec1.jpg

As for any IPsec VPN we need to add ISAKMP (phase1 ):
 
!
crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
!

In next step I add pool with IP addresses that will be allocated for users:
 
!
ip local pool POOL 4.4.4.4 4.4.4.40
!
crypto isakmp client configuration address-pool local POOL
!

Now I add client configuration group:
 
!
crypto isakmp client configuration group CG
 key cisco
 pool POOL
!

I can now add this group to aaa configuration:
 
!
aaa new-model
!
aaa authorization network AUTH-LIST local
!

I have to specify where is the user database (local/ACS/etc):
 
aaa authentication login USERS local

username cisco password 0 cisco

The ISAKMP part is completed and now I can IPsec transform set:
 
crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac

and then crypto map:
 
crypto dynamic-map DMAP 1
 set transform-set TS
 reverse-route
!

crypto map MAP 1 ipsec-isakmp dynamic DMAP
!

And then I can map client authentication and isakmp authorization lists to my crypto map:
 
crypto map MAP client authentication list USERS
crypto map MAP isakmp authorization list AUTH-LIST

crypto map MAP client configuration address respond

The last step is applying the map on the interface:
 
!
interface FastEthernet0/0
  crypto map MAP
!

I need to know add three loopback interfaces to simulate different LANs:
 
!
interface Loopback7
 ip address 7.7.7.7 255.255.255.0
!
interface Loopback8
 ip address 8.8.8.8 255.255.255.0
!
interface Loopback9
 ip address 9.9.9.9 255.255.255.0
!
 
Let’s test it. Client settings:

ra-ipsec2.jpg

Ok, the tunnel is up:

ra-ipsec3.jpg
 


R14#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA dst src state conn-id status 10.0.0.2 192.168.202.147 QM_IDLE 1002 ACTIVE IPv6 Crypto ISAKMP SA R14#

Looking on the routing details you can notice that all traffic (0.0.0.0) is going be secured:

ra-ipsec4.jpg
 
 
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: FastEthernet0/0
Username: cisco
Group: CG
Assigned address: 4.4.4.4
Uptime: 00:23:05
Session status: UP-ACTIVE
Peer: 192.168.202.147 port 49685 fvrf: (none) ivrf: (none)
      Phase1_id: CG
      Desc: (none)
  IKEv1 SA: local 10.0.0.2/500 remote 192.168.202.147/49685 Active
          Capabilities:CX connid:1002 lifetime:23:36:44
  IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 4.4.4.4
        Active SAs: 2, origin: dynamic crypto map
        Inbound:  #pkts dec'ed 182 drop 0 life (KB/Sec) 4203360/2214
        Outbound: #pkts enc'ed 149 drop 0 life (KB/Sec) 4203375/2214

R14#
 
I check if I can access all three loopbacks:

ra-ipsec5.jpg

And I see packets incremented when I ping these IPs.
Now I would like to change the scenario a bit by excluding loopback9 (9.9.9.9) from encryption but still be able to ping it.
To accomplish it we need to add an access list and specify which IPs should be encrypted:

R14(config)#access-list 101 permit ip host 7.7.7.7 4.4.4.0 0.0.0.255
R14(config)#access-list 101 permit ip host 8.8.8.8 4.4.4.0 0.0.0.255
 
* do not try here any l4 (will be ignored) access list or deny statement because everything from this acl will be added, permit and deny too (!)
And then the acl needs to be added to the isakmp client configuration:
 
crypto isakmp client configuration group CG
acl 101

I reconnected once again and we can notice that now only specified IPs/subnets are secured and the rest is not (split-tunneling):


Let’s test it:

ra-ipsec7.jpg

As you see pings to 7.7.7.7 and 8.8.8.8 go over the tunnel (packet encrypted/decrypted increased).
Now let’s test 9.9.9.9 that should be sent via the tunnel:

ra-ipsec8.jpg

As you see I can ping this IP and I see only more ‘bypassed’ packet. Encrypted/decrypted are still 8.
Now I would like to improve the security and add ACL to protect these two IPs and deny any traffic from the Internet:
  • Hosts accessible only via the VPN: 7.7.7.7, 8.8.8.8
  • Host accessible from Internet and it shouldn’t never go through the VPN: 9.9.9.9
 
!
ip access-list extended OUTSIDE
 permit icmp any host 9.9.9.9 log
 permit udp any any eq isakmp log
 permit esp any any log
 deny   ip any any log
!
interface FastEthernet0/0
 ip access-group OUTSIDE in
!

Let’s test it:

ra-ipsec9.jpg

As you see without VPN I can’t ping 7.7.7.7 and 8.8.8.8. The last one, 9.9.9.9, is accessible as expected.

When the tunnel is up the we can ping hosts 7.7.7.7 and 8.8.8.8 again:

ra-ipsec10.jpg


Now I’m going to add LAN host more and it will simulate user computer. This user sending something over the Internet should be nat-ed:
 
!
access-list 10 permit 192.168.1.1
!
ip nat inside source list 10 interface FastEthernet0/0 overload
!
interface Loopback10
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
end
!
!
interface FastEthernet0/0
ip nat outside
!

The one problem is when the VPN user wants to communicate with this LAN user the traffic will be NAT-ed too, what is not what we need:


ra-ipsec11.jpg

As you see I’m not able to ping this host. I have to exclude this source/destination pair from being NAT-ed:
 
!
access-list 110 deny   ip host 192.168.1.1 4.4.4.0 0.0.0.255
access-list 110 permit ip host 192.168.1.1 any
!
ip nat inside source list 110 interface FastEthernet0/0 overload
!

Let’s test if nat still works:
 
R14#ping 10.0.0.1 source loo10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/50/68 ms
R14#sh ip  nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 10.0.0.2:1024     192.168.1.1:6      10.0.0.1:6         10.0.0.1:1024
R14#

Let’s test again communication between VPN and LAN users:

ra-ipsec12.jpg

As you see everything works as expected.


Now I would like to add another requirement:
  • Vpn users should be able to ping both hosts but telnet to only 7.7.7.7
Checking what we have configured so far you can notice there is no feature to accomplish above requirement. There is one solution I will describe in my next post.

No comments:

Post a Comment