Professional Documents
Culture Documents
inShare
Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that allows the encapsulation of a wide variety of network layer protocols inside point-to-point links. A GRE tunnel is used when packets need to be sent from one network to another over the Internet or an insecure network. With GRE, a virtual tunnel is created between the two endpoints (Cisco routers) and packets are sent through the GRE tunnel. It is important to note that packets travelling inside a GRE tunnel are not encrypted as GRE does not encrypt the tunnel but encapsulates it with a GRE header. If data protection is required, IPSec must be configured to provide data confidentiality this is when a GRE tunnel is transformed into a secure VPN GRE tunnel. The diagram below shows the encapsulation procedure of a simple - unprotected GRE packet as it traversers the router and enters the tunnel interface:
While many might think a GRE IPSec tunnel between two routers is similar to a site to site IPSec VPN
(crypto), it is not. A major difference is that GRE tunnels allow multicast packets to traverse the tunnel whereas IPSec VPN does not support multicast packets. In large networks where routing protocols such as OSPF, EIGRP are necessary, GRE tunnels are your best bet. For this reason, plus the fact that GRE tunnels are much easier to configure, engineers prefer to use GRE rather than IPSec VPN. This article will explain how to create simple (unprotected) and secure (IPSec encrypted) GRE tunnels between endpoints. We explain all the necessary steps to create and verify the GRE tunnel (unprotected and protected) and configure routing between the two networks.
we have an added overhead because of GRE, we must reduce the MTU to account for the extra overhead. A setting of 1400 is a common practice and will ensure unnecessary packet fragmentation is kept to a minimum. Closing, we define the Tunnel source, which is R1s public IP address, and destination R2s public IP address As soon as we complete R1s configuration, the router will confirm the creation of the tunnel and inform about its status: R1# *May 4 21:30:22.971: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up Since the Tunnel 0 interface is a logical interface it will remain up even if there is no GRE tunnel configured or connected at the other end. Next, we must create the Tunnel 0 interface on R2: R2(config)# interface Tunnel0 R2(config-if)# ip address 172.16.0.2 255.255.255.0 R2(config-if)# ip mtu 1400 R2(config-if)# ip tcp adjust-mss 1360 R2(config-if)# tunnel source 2.2.2.10 R2(config-if)# tunnel destination 1.1.1.10 R2s Tunnel interface is configured with the appropriate tunnel source and destination IP address. As with R1, R2 router will inform us that the Tunnel0 interface is up: R2# *May 4 21:32:54.927: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
network will still not be able to reach the other side unless a static route is placed on each endpoint: R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.0.2 On R1 we add a static route to the remote network 192.168.2.0/24 via 172.16.0.2 which is the other end of our GRE Tunnel. When R1 receives a packet for 192.168.2.0 network, it now knows the next hop is 172.16.0.2 and therefore will send it through the tunnel. The same configuration must be repeated for R2: R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.0.1 Now both networks are able to freely communicate with each over the GRE Tunnel.
First step is to configure an ISAKMP Phase 1 policy: R1(config)# crypto isakmp policy 1 R1(config-isakmp)# encr 3des R1(config-isakmp)# hash md5 R1(config-isakmp)# authentication pre-share R1(config-isakmp)# group 2 R1(config-isakmp)# lifetime 86400 The above commands define the following (in listed order): 3DES - The encryption method to be used for Phase 1. MD5 - The hashing algorithm Pre-share - Use Pre-shared key as the authentication method Group 2 - Diffie-Hellman group to be used 86400 Session key lifetime. Expressed in either kilobytes (after x-amount of traffic, change the key) or seconds. Value set is the default value. Next we are going to define a pre shared key for authentication with R1's peer, 2.2.2.10: R1(config)# crypto isakmp key firewallcx address 2.2.2.10 The peers pre shared key is set to firewallcx. This key will be used for allISAKMP negotiations with peer 2.2.2.10 (R2).
R1(config-if)# tunnel protection ipsec profile protect-gre Now it's time to apply the same configuration on R2: R2(config)# crypto isakmp policy 1 R2(config-isakmp)# encr 3des R2(config-isakmp)# hash md5 R2(config-isakmp)# authentication pre-share R2(config-isakmp)# group 2 R2(config-isakmp)# lifetime 86400 R2(config)# crypto isakmp key firewallcx address 1.1.1.10 R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac R2(cfg-crypto-trans)# mode transport R2(config)# crypto ipsec profile protect-gre R2(ipsec-profile)# set security-association lifetime seconds 86400 R2(ipsec-profile)# set transform-set TS R2(config)# interface Tunnel 0 R2(config-if)# tunnel protection ipsec profile protect-gre
inShare
Site-to-Site IPSec VPN Tunnels are used to allow the secure transmission of data, voice and video between two sites (e.g offices or branches). The VPN tunnel is created over the Internet public network and encrypted using a number of advanced encryption algorithms to provide confidentiality of the data transmitted between the two sites. This article will show how to setup and configure two Cisco routers to create a permanent secure siteto-site VPN tunnel over the Internet, using the IP Security (IPSec) protocol. In this article we assume both Cisco routers have a static public IP address. Readers interested in configuring support for dynamic public IP address endpoint routers can refer to our Configuring Site to Site IPSec VPN with Dynamic IP Endpoint Cisco Routers article. IPSec VPN tunnels can also be configured using GRE (Generic Routing Encapsulation) Tunnels with IPsec. GRE tunnels greatly simply the configuration and administration of VPN tunnels and are covered in our Configuring Point-to-Point GRE VPN Tunnels article. Lastly, DMVPNs a new VPN trend that provide major flexibility and almost no administration overhead can also be examined by reading ourUnderstanding Cisco Dynamic Multipoint VPN (DMVPN), Dynamic Multipoint VPN (DMVPN) Deployment Models & Architectures andConfiguring Cisco Dynamic Multipoint VPN (DMVPN) - Hub, Spokes , mGRE Protection and Routing - DMVPN Configuration articles. ISAKMP (Internet Security Association and Key Management Protocol) and IPSec are essential to building and encrypting the VPN tunnel. ISAKMP, also called IKE (Internet Key Exchange), is the negotiation protocol that allows two hosts to agree on how to build an IPsec security association. ISAKMP negotiation consists of two phases: Phase 1 and Phase 2. Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data. IPSec then comes into play to encrypt the data using encryption algorithms and provides authentication, encryption and anti-replay services.
These steps are: (1) Configure ISAKMP (ISAKMP Phase 1) (2) Configure IPSec (ISAKMP Phase 2, ACLs, Crypto MAP) Our example setup is between two branches of a small company, these are Site 1 and Site 2. Both the branch routers connect to the Internet and have a static IP Address assigned by their ISP as shown on the diagram:
Site 1 is configured with an internal network of 10.10.10.0/24, while Site 2 is configured with network 20.20.20.0/24. The goal is to securely connect both LAN networks and allow full communication between them, without any restrictions.
The above commands define the following (in listed order): 3DES - The encryption method to be used for Phase 1. MD5 - The hashing algorithm Pre-share - Use Pre-shared key as the authentication method Group 2 - Diffie-Hellman group to be used 86400 Session key lifetime. Expressed in either kilobytes (after x-amount of traffic, change the key) or seconds. Value set is the default value. We should note that ISAKMP Phase 1 policy is defined globally. This means that if we have five different remote sites and configured five different ISAKMP Phase 1 policies (one for each remote router), when our router tries to negotiate a VPN tunnel with each site it will send all five policies and use the first match that is accepted by both ends. Next we are going to define a pre shared key for authentication with our peer (R2 router) by using the following command: R1(config)# crypto isakmp key firewallcx address 1.1.1.2 The peers pre shared key is set to firewallcx and its public IP Address is 1.1.1.2. Every time R1 tries to establish a VPN tunnel with R2 (1.1.1.2), this pre shared key will be used.
Configure IPSec
To configure IPSec we need to setup the following in order: - Create extended ACL - Create IPSec Transform - Create Crypto Map - Apply crypto map to the public interface
VPN-TRAFFIC
R2(config-isakmp)# encr 3des R2(config-isakmp)# hash md5 R2(config-isakmp)# authentication pre-share R2(config-isakmp)# group 2 R2(config-isakmp)# lifetime 86400 R2(config)# crypto isakmp key firewallcx address 1.1.1.1 R2(config)# ip access-list extended VPN-TRAFFIC R2(config-ext-nacl)# permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255 R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac R2(config)# crypto map CMAP 10 ipsec-isakmp R2(config-crypto-map)# set peer 1.1.1.1 R2(config-crypto-map)# set transform-set TS R2(config-crypto-map)# match address VPN-TRAFFIC R2(config)# interface FastEthernet0/1 R2(config- if)# crypto map CMAP
And Site 2s router: R2(config)# ip nat inside source list 100 interface fastethernet0/1 overload R2(config)# access-list 100 remark -=[Define NAT Service]=R2(config)# access-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255 R2(config)# access-list 100 permit ip 20.20.20.0 0.0.0.255 any R2(config)# access-list 100 remark
The first ping received a timeout, but the rest received a reply, as expected. The time required to bring up the VPN Tunnel is sometimes slightly more than 2 seconds, causing the first ping to timeout. To verify the VPN Tunnel, use the show crypto session command: R1# show crypto session Crypto session current status Interface: FastEthernet0/1 Session status: UP-ACTIVE Peer: 1.1.1.2 port 500 IKE SA: local 1.1.1.1/500 remote 1.1.1.2/500 Active IPSEC FLOW: permit ip 10.10.10.0/255.255.255.0 20.20.20.0/255.255.255.0
inShare
Introduction
NAT (Network Address Translation) is a method that allows the translation (modification) of IP addresses while packets/datagrams are traversing the network. NAT Overload, also known as PAT (Port Address Translation) is essentially NAT with the added feature of TCP/UDP ports translation. The main purpose of NAT is to hide the IP address (usually private) of a client in order to reserve the public address space. For example a complete network with 100 hosts can have 100 private IP addresses and still be visible to the outside world (internet) as a single IP address. Other benefits of NAT include security and economical usage of the IP address ranges at hand. The following steps explain basic Cisco router NAT Overload configuration. NAT overload is the most common operation in most businesses around the world, as it enables the whole network to access the Internet using one single real IP address. If you would like to know more about the NAT theory, be sure to read our popular NAT articles, which explain in great depth the NAT functions and applications in today's networks.
Example Scenario
The diagram below represents our example network which consists of a number of internal clients and a router connected to our ISP via its serial interface. The company has been assigned the following Class C subnet: 200.2.2.0/30 (255.255.255.252). This translates to one usable real IP address - 200.2.2.1 - configured on our router's serial interface. IP address 200.2.2.2 will be used on the other end, that is, the ISP's router. Our ISP has also provided us with the necessary default gateway IP address (configured on our router - not shown) in order to route all traffic to the Internet. Our goal in this example is to configure NAT Overload (PAT) and provide all internal workstations with Internet access using one public IP address (200.2.2.1).
configuration for almost all of today's networks. In addition, NAT Overload (PAT) is covered in great depth on Firewall.cx, please click here to read more.
The first step in any NAT configuration is to define the inside and outside interfaces. It is imperative that we define the these interfaces for NAT overload to function. Set the fast ethernet 0/0 interface as the inside interface: terminal fastethernet0/0 nat inside serial0/0 outside
R1# configure R1(config)# interface R1(config-if)# ip R1(config-if)# interface R1(config-if)# ip R1(config-if)# exit
Next step is to set the serial interface S0/0 as the outside interface: nat
We now need to create an Access Control List (ACL) that will include local (private) hosts or network(s). This ACL will later on be applied to the NAT service command, effectively controlling the hosts that will be able to access the Internet. You can use standard or extended access lists depending on your requirements: R1(config)# access-list 100 remark == [Control NAT Service]== R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any The above command instructs the router to allow the 192.168.0.0/24 network to reach any destination. Note that Cisco router standard and extended ACLs always use wildcards (0.0.0.255). All that's left now is to enable NAT overload and bind it to the outside interface previously selected: R1(config)# ip nat inside source list 100 interface serial 0/0 overload From this point onward, the router will happily create all the necessary translations to allow the
Pro Inside global Inside local udp 200.2.2.1:53427 192.168.0.6:53427 udp 200.2.2.1:53427 192.168.0.6:53427 tcp 200.2.2.1:53638 192.168.0.6:53638 tcp 200.2.2.1:57585 tcp 200.2.2.1:57586 192.168.0.7:57585 192.168.0.7:57586
As shown, the first 2 translations directed to 74.200.84.4 & 195.170.0.1 are DNS requests from internal host 192.168.0.6. The third entry seems to be an http request to a web server with IP address 64.233.189.99. Looking at the fourth and fifth translation entry, you should identify them as pop3 requests to an external server, possibly generated by an email client. Because these entries are all dynamically created, they are temporary and will be removed from the translation table after some time. Another point you might want to keep in mind is that when we use programs that create a lot of connections e.g Utorrent, Limewire, etc., you might see sluggish performance from the router as it tries to keep up with all connections. Having thousands of connections running through the router can put some serious stress on the CPU. In these cases, we might need to clear the IP NAT table completely to free up resources. This is easily done using the following command: R1# clear ip nat translation * Assuming no request has been sent right after the command was entered, the NAT translation table should be empty: R1# show ip nat translations Pro Inside global ...........Inside local .....Outside local .......Outside global Lastly, you can obtain statistics on the overload NAT service. This will show you the amount of current
translations tracked by our NAT table, plus a lot more: R1# show ip nat statistics Total active translations: 200 (0 static, 200 dynamic; 200 extended) Outside interfaces: Serial 0/0 Inside interfaces: FastEthernet0/0 Hits: 163134904 Misses: 0 CEF Translated packets: 161396861, CEF Punted packets: 3465356 Expired translations: 2453616 Dynamic mappings: -- Inside Source [Id: 2] access-list 100 interface serial 0/0 refcount 195 Appl doors: 0 Normal doors: 0 Queued Packets: 0
Configuring Cisco Site to Site IPSec VPN with Dynamic IP Endpoint Cisco Routers
Written by Administrator Monday, 21 January 2013 02:07
inShare
This article serves as an extension to our popular Cisco VPN topics covered here on Firewall.cx. While weve covered Site to Site IPSec VPN Tunnel Between Cisco Routers (using static public IP addresses), we will now take a look on how to configure our headquarter Cisco router to support remote Cisco routers with dynamic IP addresses. One important note to keep in mind when it comes to this implementation, is that Site-to-Site VPN networks with Dynamic remote Public IP addresses can only be brought up by the remote site routers as only they are aware of the headquarter's router Public IP address. IPSec VPN tunnels can also be configured using GRE (Generic Routing Encapsulation) Tunnels with IPsec encryption. GRE tunnels greatly simply the configuration and administration of VPN tunnels and are covered in our Configuring Point-to-Point GRE VPN Tunnels article. Lastly, DMVPNs a new VPN trend that provide outstanding flexibility and almost no administration overhead can also be examined by reading our Understanding Cisco Dynamic Multipoint VPN (DMVPN), Dynamic Multipoint VPN (DMVPN) Deployment Models & Architecturesand Configuring Cisco Dynamic Multipoint VPN (DMVPN) -
Hub, Spokes , mGRE Protection and Routing - DMVPN Configuration articles. ISAKMP (Internet Security Association and Key Management Protocol) and IPSec are essential to building and encrypting the VPN tunnel. ISAKMP, also called IKE (Internet Key Exchange), is the negotiation protocol that allows two hosts to agree on how to build an IPsec security association. ISAKMP negotiation consists of two phases: Phase 1 and Phase 2. Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data. IPSec then comes into play to encrypt the data using encryption algorithms and provides authentication, encryption and anti-replay services.
Our Headquarters is assigned an internal network of 10.10.10.0/24, while Remote Site 1 has been assigned network20.20.20.0/24. and Remote Site 2 network 30.30.30.0/24. The goal is to securely connect both remote sites with our headquarters and allow full communication, without any
restrictions.
Configure IPSec
To configure IPSec we need to setup the following in order: - Create extended ACL - Create IPSec Transform - Create Dynamic Crypto Maps Apply crypto Let us examine each of the above steps. map to the public interface
First we create a crypto map named VPN which will be applied to the public interface of our headquarter router, and connect it with the dynamic crypto maps we named as hq-vpn. crypto map VPN 1 ipsec-isakmp dynamic hq-vpn The ipsec-isakmp tag tells the router that this crypto map is an IPsec crypto map. Now we create our two dynamic crypto maps using the following configuration commands: crypto dynamic-map hq-vpn 10 set security-association lifetime seconds 86400 set transform-set TS match address VPN1-TRAFFIC ! crypto dynamic-map hq-vpn 11 set security-association lifetime seconds 86400 set transform-set TS match address VPN2-TRAFFIC Notice how we create one dynamic map for each remote network. The configuration is similar for each dynamic crypto map, with only the instance number (10 , 11) and match address (VPN1TRAFFIC , VPN2-TRAFFIC) changing. Adding additional remote sites in the future is as easy as simply adding more dynamic crypto maps, incrementing the index number and specifying the match address extended access-lists for each remote network.
Our remote routers connect to the Internet and are assigned a dynamic IP address which changes periodically by the ISP. In most part, the configuration is similar to that of the headquarter router, but with a few minor changes. In the configuration below, IP address 74.200.90.5 represents the public IP address of our headquarter router. Remote Site 1 Router crypto encr 3des hash md5 authentication pre-share group 2 lifetime 86400 ! crypto isakmp key firewallcx address 74.200.90.5 ! ip access-list extended VPN-TRAFFIC permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255 ! crypto ipsec transform-set TS esp-3des esp-md5-hmac ! crypto map vpn-to-hq 10 ipsec-isakmp set peer 74.200.90.5 set transform-set TS match ! interface FastEthernet0/1 crypto map vpn-to-hq Remote Site 2 Router crypto isakmp policy 1 encr 3des hash md5 authentication pre-share group 2 lifetime 86400 ! crypto isakmp key firewallcx address 74.200.90.5 ! address VPN-TRAFFIC isakmp policy 1
ip access-list extended VPN-TRAFFIC permit ip 30.30.30.0 0.0.0.255 10.10.10.0 0.0.0.255 ! crypto ipsec transform-set TS esp-3des esp-md5-hmac ! crypto map vpn-to-hq 10 ipsec-isakmp set peer 74.200.90.5 set transform-set TS match address VPN-TRAFFIC ! interface FastEthernet0/1 crypto map vpn-to-hq It is noticeable that the only major difference between the two routers configuration is the extended access list.
For Remote Site 1 Router, deny NAT for packets destined to the headquarter network:
ip nat inside source list 100 interface fastethernet0/1 overload ! access-list 100 remark -=[Define NAT Service]=access-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255 access-list 100 permit ip 20.20.20.0 0.0.0.255 any access-list 100 remark
For Remote Site 2 Router, deny NAT for packets destined to the headquarter network: ip nat inside source list 100 interface fastethernet0/1 overload ! access-list 100 remark -=[Define NAT Service]=access-list 100 deny ip 30.30.30.0 0.0.0.255 10.10.10.0 0.0.0.255 access-list 100 permit ip 30.30.30.0 0.0.0.255 any access-list 100 remark
To verify the VPN Tunnel, use the show crypto session command: R2# show crypto session Crypto session current status Interface: FastEthernet0/1 Session status: UP-ACTIVE Peer: 74.200.90.5 port 500 IKE SA: local 73.54.120.100/500 remote 74.200.90.5 /500 Active IPSEC FLOW: permit ip 20.20.20.0/255.255.255.0 10.10.10.0/255.255.255.0 Active SAs: 2, origin: crypto map
From Remote Site 2, lets ping the headquarter router: R3# ping 10.10.10.1 source fastethernet0/1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds: Packet sent with a source address of 85.100.120.5 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 47/50/53 ms Again, the first ping received a timeout, but the rest received a reply, as expected. The time required to bring up the VPN Tunnel is sometimes slightly more than 2 seconds, causing the first ping to timeout. To verify the VPN Tunnel, use the show crypto session command: R3# show crypto session Crypto session current status Interface: FastEthernet0/1 Session status: UP-ACTIVE Peer: 74.200.90.5 port 500 IKE SA: local 85.100.120.5/500 remote 74.200.90.5 /500 Active IPSEC FLOW: permit ip 30.30.30.0/255.255.255.0 10.10.10.0/255.255.255.0 Active SAs: 2, origin: crypto map Issuing the show crypto session command at the headquarter router will reveal all remote routers public IP addresses. This is usually a good shortcut when trying to figure out the public IP address of your remote routers.
How to Restrict Cisco IOS Router VPN Client to Layer-4 (TCP, UDP) Services Applying IP, TCP & UDP Access Lists
Written by Administrator Tuesday, 05 February 2013 01:06
inShare
In our article Cisco VPN Client Configuration - Setup for IOS Router we explained how to setup up a Cisco IOS router to support Cisco IPSec VPN clients, allowing remote users to securely connect to the company network and access the available resources. It is recommended that users with little or no experience on Cisco router VPN client configuration read our Cisco Router VPN Client Configuration article before proceeding. Restricting access to your IPSec VPN clients (or Groups) is possible with the use of standard or extended access lists, which are applied to the crypto isakmp client configuration group section. The problem many administrators and Cisco engineers are faced with is even though usage of extended ACLs, defining layer-4 services such as TCP or UDP, is allowed, the router will only apply up to layer-3 access list information. Layer-4 information in the defined access lists is completely ignored.
Lets take for example the following configuration, designed to restrict our CCLIENT-VPN VPN group to host 192.168.0.6 and TCP ports 80 & 1433: ! aaa aaa aaa aaa aaa ! crypto isakmp policy 1 encr 3des authentication pre-share group 2 ! crypto isakmp policy 2 encr 3des hash md5 authentication pre-share group 2 ! crypto key pool acl max-users 5 ! crypto isakmp profile vpn-ike-profile-1 match identity group CCLIENT-VPN client authentication list vpn_xauth_ml_1 isakmp authorization list vpn_group_ml_1 client configuration address respond virtual-template 2 isakmp client configuration group CCLIENT-VPN firewall.cx VPN-Pool 120 authentication authentication authorization login login network session-id default vpn_xauth_ml_1 vpn_group_ml_1 new-model local local local common
! crypto ipsec transform-set encrypt-method-1 esp-3des esp-sha-hmac ! crypto ipsec profile VPN-Profile-1 set transform-set encrypt-method-1 ! ! interface Virtual-Template2 type tunnel ip unnumbered Vlan1 tunnel mode ipsec ipv4 tunnel protection ipsec profile VPN-Profile-1 ! access-list 120 remark ==[VPN Group CCLIENT-VPN access-list 120 permit tcp host 192.168.0.6 eq 80 192.168.0.0 0.0.0.255 access-list 120 permit tcp host 192.168.0.6 eq 1433 192.168.0.0 0.0.0.255 When a VPN client belonging to the CCLIENT-VPN group connects, he is expected to have access to host 192.168.0.6 and the defined (by the ACLs) services - TCP ports 80 & 1433 - right? Wrong! Access lists under the crypto isakmp client configuration group are not filtering access lists. Their purpose is not to control Layer-4services, but identify the network routes the remote VPN user(s) will have access to. This is also called Split-Tunneling. It is for this reason the IOS router will allow full access to our host 192.168.0.6. TCP/UDP services, located on Layer-4 of the OSI model, are completely ignored when defined in VPN group access lists. As a result, this design or limitation (if you like) is a big problem for many network administrators and engineers as it does not provide the flexibility and granularity required in todays complex and demanding VPN networks. Access Lists]==
The Solution to Making Extended ACLs Work For Cisco IOS VPN Clients Restricting VPN Clients to Layer 4 Services
Despite the setback, it is possible to control access to layer 4 TCP/UDP services for your VPN groups. The solution involves creating different Virtual-Template interfaces to which the ISAKMP profiles, and therefore VPN groups, are bound. We then create a new set of access lists and apply them to the Virtual-Template in the inbound direction as shown below: ! crypto isakmp client configuration group web-sql-group key $firewall.cx$ pool VPN-Pool acl 110 max-users 3 !
crypto isakmp profile vpn-ike-profile-2 match identity group web-sql-group client authentication list vpn_xauth_ml_5 isakmp authorization list vpn_group_ml_1 client configuration address respond virtual-template 3 ! ! interface Virtual-Template3 type tunnel ip unnumbered Vlan1 ip access-group 121 in tunnel mode ipsec ipv4 tunnel protection ipsec profile VPN-Profile-1 ! access-list 110 remark ==[Cisco VPN- WEB Service ]== access-list 110 permit ip host 192.168.0.6 any access-list 110 remark ! access-list 121 remark ==[Virtual Template3 - Restrict Access to 192.168.0.6 - HTTP & MSSQL]== access-list 121 permit tcp any host 192.168.0.6 eq www access-list 121 permit tcp any host 192.168.0.6 eq 1433 access-list 121 deny ip any any access-list 121 remark Notice how we still use a set of access-lists (110) for our new group web-sql-group, restricting access to host 192.168.0.6. These will ensure the VPN group will be able to access the particular host. Next, we create a new set of access-lists (121) which are placed under the new VirtualTemplate3 in the inbound direction. These are the extended access-lists that do the job. Keep in mind that these access-lists must always be placed in the inbound direction of the VirtualTemplate3 interface, to ensure they work correctly and block other types of VPN user traffic from reaching our network or hosts. Finally, it is equally important to pay attention to the crypto isakmp profile vpn-ike-profile2 command, which essentially maps the VPN group with our new Virtual-Template3 interface. If there is a need to create additional vpn groups with restricted access, all that is required is to configure new crypto isakmp profiles and Virtual-Templates along with the necessary access lists as shown by this example.