📜 ⬆️ ⬇️

Configure SSL VPN on the Cisco Router

Greetings, colleagues, I would like to describe the steps to configure SSL VPN for Cisco, with a description of some interesting nuances encountered in practice.

To implement the scheme shown below, we will use the following real physical equipment, also please note that the interface names are conditional and are not used in the implementation (it was not possible to implement ssl vpn in unl-eve, since neither iol nor vios commands for configuring webvpn support) :

Cisco 881 (C880DATA-UNIVERSALK9-M 15.2 (4) M4)
Windows 7 x64 + AnyConnect 4.4
')
Connection diagram:



First, what is SSL VPN (or WEBVPN) from Cisco. This is a kind of heir to easy vpn or ipsec vpn, which allows you to remotely connect to your corporate or home network via ssl protocol (port 443). In addition to the simplicity of the configuration and the relatively “light” config, the biggest reason for using ssl is that it uses the practically open 443 port for connection, i.e. if you, for example, used ipsec, you would have to open the isakmp (500) ports on the firewall or on the border router, probably allow nat-t (4500), and also allow esp traffic in addition, whereas in the case of ssl connection goes through port 443, which is mostly allowed for hosts. In addition, there is no need to make any settings on the client side, for a remote user it is enough to know only the external ip or dns name of the router, as well as the login and password to log in (when using easyvpn, in addition to the above, you need a pre-share key, as well as the name client configuration group ).

Setup:

1. First, you need to activate the license on the router; in our case, use cisco 881 with ios 15.2 (4), for a trial activation for 60 days, enter the following. command in privilege mode:

license modify priority SSL_VPN high 

Then we agree with the license agreement.

2. Next, copy the any connect distribution to the router in any convenient way (copying is better to produce in the webvpn directory created before, because if you simply copy to the flash root, then an installation file will create a copy of the installation file in the same directory, respectively, will take more space on the flash) and install it:

 mkdir flash:/webvpn copy tftp: flash:/webvpn/ crypto vpn anyconnect flash:/webvpn/anyconnect-win-4.4.00243-k9.pkg 

3. Turn on aaa (required to specify the authentication list on our web gateway (webvpn gateway)), set up local users (login and password, which we specify here are required to connect to the portal from the Internet, by the type of external address ) and activate the https server:

 aaa new-model aaa authentication login SSL_USERS local username admin secret *************** ip http secure-server 

4. Generate RSA keys, create a trustpoint and then generate a self-signed certificate:

 crypto key generate rsa label SSLKEY modulus 1024 crypto pki trustpoint SALAM_TRUSTPOINT enrollment selfsigned serial-number subject-name CN=firewallcx-certificate revocation-check crl rsakeypair SSLKEY crypto pki enroll SALAM_TRUSTPOINT 

5. Configuring the address pool that will be issued to clients and creating WebVPN Gateway, for the ip interface command, you can specify the ip address directly with the ip address **** port 443 command:

 ip local pool WEBVPN_POOL 10.0.0.11 10.0.0.15 webvpn gateway WEBVPN_GW ip interface Dialer1 port 443 ssl trustpoint SALAM_TRUSTPOINT inservice 

6. Next, we create and bind to our gateway the so-called webvpn context, in which we specify the previously created auth list, the maximum number of connected users, and the greeting displayed when entering the portal through a browser (the inservice command in this and previous step activates the webvpn gateway and context):

 webvpn context WEBVPN_CON title "Assalyamu alyaikum" login-message "Salyam" aaa authentication list SSL_USERS gateway WEBVPN_GW max-users 5 inservice 

7. In the same configuration, in the webvpn context configuration, create a policy group in which we set our address pool, specify which traffic from clients will be wrapped in the tunnel (in our case, when destination clients have networks 192.168.1.0 / 24 or 172.16.1.0/24 the corresponding entries for these two networks appear in the routing table on the clients, indicating that this traffic will go to the encrypted tunnel), the functions svc-enabled command indicates that the remote user can connect using the independently installed anyconnect client, i.e. . do not go through the browser:

 policy group WEBVPN_POLICY functions svc-enabled svc address-pool "WEBVPN_POOL" netmask 255.255.255.0 svc split include 192.168.1.0 255.255.255.0 svc split include 172.16.1.0 255.255.255.0 default-group-policy WEBVPN_POLICY 

8. If we have an ACL on the external interface, then we need to add a rule:

 permit tcp any host «  » eq 443 

As a result, we launch a browser on our client, enter the external address of our router 212.212.0.1 and see the invitation:



It remains to enter the login password and establish a connection, this would be all, but there is one nuance.
If we refer to our scheme, then the network 192.168.1.0/24, the one to which we connect, is behind the NAT, the NAT setting for the R1 router is as follows:

 ip nat inside source list NAT_POOL interface Dialer1 overload 

where is NAT_POOL:

 ip access-list extended NAT_POOL permit ip 192.168.1.0 0.0.0.255 any 

What happens if we ping the network 192.168.1.0 from the client connected via vpn (the client received the address 10.0.0.12)? The packets encrypted from it will go to R1, which in turn creates a response from destination 10.0.0.12 and looks at the routing table:

 R1#sh ip route 10.0.0.12 Routing entry for 10.0.0.12/32 Known via "static", distance 0, metric 0 Routing Descriptor Blocks: * directly connected, via Virtual-Access3 Route metric is 0, traffic share count is 1 R1#sh interfaces virtual-access 3 Virtual-Access3 is up, line protocol is up Hardware is Virtual Access interface Description: ***Internally created by SSLVPN context WEBVPN_CON*** Interface is unnumbered. Using address of Dialer1 (212.212.0.1) MTU 1406 bytes, BW 100000 Kbit/sec, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation SSL SSL vaccess 

Those. packets leave the dialer 1 interface, and according to this remarkable traffic order table



after routing, we have NAT, and our nat rule tells us that our source will be replaced with a public address and in this form will go to a client who has no idea about our external address, therefore ping will not work and will not work, we will fix it by adding The following command in acl NAT_POOL:

 ip access-list extended NAT_POOL 1 deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255 

And, alhamdulillah1, everything works!

Source: https://habr.com/ru/post/324128/


All Articles