Today I would like to implement remote access VPN (IPsec) on the cisco router. I check all features you can enable/disable.
As for any IPsec VPN we need to add ISAKMP (phase1 ):
In next step I add pool with IP addresses that will be allocated for users:
Now I add client configuration group:
I can now add this group to aaa configuration:
I have to specify where is the user database (local/ACS/etc):
The ISAKMP part is completed and now I can IPsec transform set:
and then crypto map:
And then I can map client authentication and isakmp authorization lists to my crypto map:
The last step is applying the map on the interface:
I need to know add three loopback interfaces to simulate different LANs:
Ok, the tunnel is up:
Looking on the routing details you can notice that all traffic (0.0.0.0) is going be secured:
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:
And then the acl needs to be added to the isakmp client configuration:
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:
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:
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:
Let’s test it:
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:
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:
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:
As you see I’m not able to ping this host. I have to exclude this source/destination pair from being NAT-ed:
Let’s test if nat still works:
Let’s test again communication between VPN and LAN users:
As you see everything works as expected.
Now I would like to add another requirement:
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 ciscoThe ISAKMP part is completed and now I can IPsec transform set:
crypto ipsec transform-set TS esp-aes 256 esp-sha-hmacand 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 respondThe 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
! 
Ok, the tunnel is up:
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:
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# 
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 And then the acl needs to be added to the isakmp client configuration:
crypto isakmp client configuration group CG
acl 101I reconnected once again and we can notice that now only specified IPs/subnets are secured and the rest is not (split-tunneling):
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:
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:
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:
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:
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:
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
Comments
Post a Comment