Download this app from Microsoft Store for Windows 10, Windows 10 Mobile, Windows 10 Team (Surface Hub), HoloLens, Xbox One. See screenshots, read the latest customer reviews, and compare ratings for AnyConnect.

Software release

1. Cisco VPN client. The VPN gateway setup presented in the previous section is interoperable with the Cisco VPN client configured in mutual group authentication (this is a synonym for Hybrid authentication). The group and group password required by Cisco VPN client are ignored by racoon(8), but that does not make user authentication unsecure.
2. Some USC online services require access through on-campus USC Secure Wireless or a wired network connection. USC offers Virtual Private Networking (VPN) to provide secure remote access to these services when you are off-campus. Use AnyConnect VPN if you are away from the USC campus and are unable to connect to services. Additionally, you must.
3. TL;DR If Cisco AnyConnect is disconnecting, reconnecting every few minutes, try blocking UDP in/out ports for the vpnagent executable/service. Cisco AnyConnect Secure Mobility Client version 4.7.04056 This one drove me nuts for the longest time until I found time to dedicate to troubleshooting it myself.
4. Using Windows XP and Cisco VPN client version 5.0.4.xxx to connect to a remote customer site. We are able to establish the connection and start an RDP session, but within 1-2 minutes the connection drops and the VPN connection disconnects. The PC making the connection is on a DMZ which is NATed to a public IP address.

Remote user access VPN

User remote access using IPsec

A VPN gateway setup

How To Install Cisco VPN Client On Windows 10 | TechRadar

VPN client

Software release

Kernel

The information in this document applies to the following NetBSD kernel:

• NetBSD-current as of may 2005 or above
• NetBSD-3.0_BETA as of may 2005 or above

Userland

The information in this document applies to the following userland (setkey(8), racoon(8), racoonctl(8) and libipsec):

• NetBSD-current as of may 2005 or above
• NetBSD-3.0_BETA as of may 2005 or above
• Earlier NetBSD releases with the ipsec-tools 0.6.beta2 package or above from NetBSD's pkgsrc

Remote user access VPN

Context

Many organisations have a Remote Access Server (RAS) providing users a remote access to the internal network through modem connections over the Plain Old Telephone System (POTS).

With the raise of high bandwidth connections like Digital Subscriber Line (DSL) and cable, using POTS for the remote access is getting obsolete, and users want a high bandwidth remote access. Using Virtual Private Networks (VPN) is a solution to this problem.

User authentication for VPN access can be done by different methods:

• Group password (all users have the same password)
• Login and password
• x509 certificate

Group password is a weak solution and should not be used, because users are not really authenticated. x509 certificate gives you the highest security, but user certificates might be troublesome to manage. If you can afford it, then everything you need to know is in the IPsec FAQ. Login and password are an average security level. Because passwords can be guessed or disclosed by another protocol (e.g.: POP3 without SSL), it is not highly secure, but it can be made reasonably secure if strong passwords are enforced and if the protocol used ensures they cannot be sniffed.

This HOW-TO covers the situation where login and password are to be used for remote user VPN access.

Security considerations

In order to establish a secured VPN, the remote user must authenticate to the VPN gateway, and the VPN gateway must authenticate to the remote user. If the mutual authentication is not performed, then there is a loophole open for Man in the Middle (MiM) attacks, where an attacker can masquerade as the VPN gateway and collect user passwords.

We said the remote user will authenticate using login and password. How can the VPN gateway authenticate? If a pre-shared key is used, then anyone knowing the key will be able to masquerade as the VPN gateway, and all the legitimate users will have to know about the pre-shared key. This is really weak security. The alternative is to use a x509 certificate on the VPN gateway. This is a server certificate, which is much easier to manage than user certificates. We will assume a certificate is used to authenticate the VPN gateway.

Solutions

We want user authentication using a login and a password, and VPN gateway authentication using a certificate. There are not many solutions available. OpenVPN is a Secure Socket Layer (SSL) based solution that is able to do what we want. An alternative is to use IPsec, which is what we will cover here.

User remote access using IPsec

IPsec phase 1 authentications

IPsec phase 1 is part of the IPsec Key Exchange (IKE) operations performed by the IKE daemon, also known as racoon(8) in NetBSD. Its goal is to authenticate the peers and set up master keys for performing a secured IPsec phase 2. The goal of phase 2 is to derive the keys used for exchanging IPsec traffic. Phase 2 rekeying can occur regularly while IPsec traffic is exchanged.

IPsec phase 1 offers two authentication methods: pre-shared keys and certificates. This is not what we want because

Cisco Anyconnect Vpn Client Ports

• pre-shared keys are not bound to logins. We have no management tools to handle them properly, leaving a group password as the only manageable option.
• IPsec phase 1 authentication is supposed to be symmetric: pre-shared keys on both endpoints or certificates on both endpoints. This is not what we are looking for.

Xauth

Xauth is an IKE extension that occurs after phase 1 and adds a login/password authentication. This solves half of the authentication problem: because Xauth occurs just after phase 1, it is secured by phase 1 authentication. You still need a pre-shared key or a certificate in phase 1. Using a pre-shared key is not secure, and using a certificate means you use user certificates, which is something we wanted to avoid.

Hybrid auth

Hybrid auth is another IKE extension, that makes phase 1 asymmetric. During phase 1, the VPN gateway can use a certificate, while the remote user does not have to authenticate. After phase 1 we are in a situation where:

• Remote user knows it speaks to the VPN gateway
• Communications between the remote user and the VPN gateway are secure
• The VPN gateway has no idea about who it is talking with

After this phase 1, an Xauth exchange can occur to securely authenticate the remote user. Then phase 2 can take place.

The security level of IPsec + Xauth + Hybrid auth is roughly equivalent to SSH using password authentication.

ISAKMP mode config

So our authentication problem is solved by using IPsec + Xauth + Hybrid auth. In order to make the thing really user friendly, we need to make the remote user machine configuration automatic. ISAKMP mode config is an IKE extension that enable the VPN gateway to provide the network configuration for the remote user's machine: Internal IP address, DNS address, domain name, and so on.

NAT Traversal

The remote user might be hidden behind a Network Address Translator (NAT), which will not work when using IPsec encrypted streams. When traffic has to be encrypted, IPsec uses a layer 4 protocol known as Encapsulated Security Payload (ESP). Unlike TCP or UDP, ESP has no port number and cannot easily be handled by NAT devices.

RFC 3947 and 3948 describe a method to encapsulate ESP in UDP, and IKE extensions to manage NAT in between endpoints of IPsec streams. The encapsulation method and IKE extensions are together known as NAT Traversal (NAT-T).

NAT-T might be encumbered by a US patent.

IKE fragmentation and ESP fragmentation

Remote users will often connect from behind DSL modem-router appliances. Most of these devices are utterly broken when dealing with big UDP packets: they assume UDP can only be used for DNS requests and will drop bigger or fragmented UDP packets. IKE transactions and ESP over UDP will tend to use big UDP packets, and will therefore be blocked.

In order to address that problem, we use IKE fragmentation, which is an IKE extension used to fragment the IKE packets into smaller fragments. ESP fragmentation addresses the problem of big ESP over UDP packets, by performing IP fragmentation before the ESP encapsulation: instead of sending frag(IP/UDP/ESP/IP) on the network, we send IP/UDP/ESP/frag(IP). Devices between the IPsec endpoints therefore do not see any fragmented packets.

Dead Peer Detection

Last problem: the remote user Internet connection can be unstable, leading to spurious disconnections. The only built-in mechanism IPsec has to handle that is to force IKE phase 2 rekeying after some time. If the peer is not on-line anymore, it will fail, thus causing the VPN tunnel to be destroyed.

This is not very convenient as it forces frequent rekeying to detect that the remote user got off-line. Dead Peer Detection (DPD) is an IKE extension used to regularly probe the remote IPsec endpoint for activity. DPD can be used to detect that the remote host went off-line within a few seconds.

A VPN gateway setup

Here is a setup example for a VPN gateway using IPsec + Xauth + Hybrid auth + ISAKMP mode config + NAT-T + DPD + IKE fragmentation + ESP fragmentation.

Kernel configuration

First you need to build and install a kernel with at least the following options:

Packet forwarding

You need to enable IPv4 packet forwarding, by using the following command:

This can be automatically executed on reboot by adding this line to /etc/sysctl.conf:

Certificate generation

If you have not already configured OpenSSL, start by installing the sample config file:

Then create a private key and use it to create a Certificate Signing Request (CSR):

Send the CSR, vpngw.csr to a Certificate Authority (CA) for signature. You will get a x509 certificate, that we shall name vpngw.crt

If you want to be your own CA, then perform the following steps to generate the CA private key and certificate, and to sign your CSR:

Keep the secret keys secret, as your VPN will not be secure anymore if they get disclosed. Give the CA certificate ca.crt to remote users, and move to the next step.

Configuring racoon(8)

Here is a sample /etc/racoon/racoon.conf file:

The mode_cfg section defines the configuration sent from the VPN gateway to the client using ISAKMP mode config. For now only IPv4 configuration is supported. The VPN address pool is defined there, by a base address (network4) and a pool size (pool_size). auth_source explains how the login and password are validated. Possible values are system, to validate against the system user database, pam to use the Pluggable Authentication Module (PAM) system (/etc/pam.d/racoon will be used), and radius to validate logins against RADIUS.

Once your /etc/racoon/racoon.conf file is ready, you can launch racoon(8):

In order to have racoon(8) started up at boot time, you need the following in /etc/rc.conf:

More fragmentation problems

In the configuration sample, esp_frag is specified so that ESP fragmentation is used to avoid sending packets bigger than 552 bytes. 552 bytes is quite low, but it should work with the most broken DSL modem-routers appliances. The higher esp_frag is, the better the performances are.

Using ESP fragmentation, it is possible to exchange IP packets of any size through the tunnel. However, there is a special case for TCP, which may have trouble with Path Maximum Transmission Unit (PMTU) discovery. The solution is to use Maximum Segment Size (MSS) clamping. This can be done in /etc/npf.conf, for example with:

And type the following to enable that configuration:

In order to have those commands executed on startup, you need the following in /etc/rc.conf:

Interaction with firewalls

In this VPN solution, the client needs to send UDP packets to ports 500 and 4500 of the VPN gateway. The first packets are exchanged on port 500, then NAT-T negotiation moves the transaction to port 4500.

Firewalls in front of the VPN gateway must be configured to let udp/500 and udp/4500 pass through to the VPN gateway.

VPN gateway and RADIUS

RADIUS can be used for login validation, IP addresses allocation and accounting. Here is a sample mode_cfg section for /etc/racoon/racoon.conf that enforces RADIUS usage:

Additionally, you need to create a /etc/radius.conf file that contains the RADIUS server address and the secret shared with the RADIUS server. This file must be owned by root and mode 0600 in order to keep the shared secret secure. Here is an example, see radius.conf(5) for the details:

VPN client

Cisco VPN client

The VPN gateway setup presented in the previous section is interoperable with the Cisco VPN client configured in mutual group authentication (this is a synonym for Hybrid authentication). The group and group password required by Cisco VPN client are ignored by racoon(8), but that does not make user authentication unsecure.

Do not forget to set up the client with IPsec over UDP transport to get NAT-T enabled.

racoon(8) as the client: configuration example

It is also possible to use racoon(8) as a client. You need to install the CA certificate in /etc/openssl/certs/ca.crt, and the configuration below in /etc/racoon/racoon.conf

Cisco Vpn Client Port Forwarding

The phase1-up.sh and phase1-down.sh scripts are called when the IKE phase 1 is established and terminated, that is, at VPN connection and disconnect time. They are responsible for setting up and deleting the IPsec Security Policies (SP), VPN IP address, and routing entries. The sample scripts should do what you need, but you can customize them to fit your particular needs.

Once this is ready, you can start racoon(8):

In order to have it started at boot time, add racoon=YES to /etc/rc.conf.

Connecting to and disconnecting from the VPN

racoonctl(8) can be used to connect to the VPN and to disconnect from it. The login is given through the -u option and the password is prompted on the terminal:

DNS addresses can be used instead of IP addresses in this example. Note that if for some reason the routing entries or Security Policy Database (SPD) get screwed, the DNS resolution will not work at VPN disconnect time. To recover from such a situation, type the following commands as root:

Anyone with read/write rights to the racoon(8) socket /var/racoon/racoon.sock can start or stop the VPN. The ownership and rights to the socket can be set using the adminsock statement in the listen section of /etc/racoon/racoon.conf.

Saving Xauth password

If you want to avoid typing the Xauth password, you can store it in racoon's Pre-Shared Key (PSK) file. Add the following statement in the remote section of /etc/racoon/racoon.conf:

Then add a line in /etc/racoon/psk.txt with the login and the password:

Cisco Vpn Ports To Open

With that setup, this command will establish the VPN connection using the toto login, without prompting for a password:

Most Cisco AnyConnect VPN configurations I see in the field, or have deployment myself, are terminated on a Cisco ASA firewall who is directly connected to the internet. However, in some bigger networks it is not uncommon to have another firewall in front of the remote access / VPN block in your network or to have an access-list on the routers in the internet edge.

Everybody knows the story about the biggest pro which the Cisco AnyConnect solution has if you compare it to the old IPSEC remote access based solution –> “it just works everywhere™”. That story is based on the fact that in most guest and mobile networks SSL network traffic (TCP/443) is allowed. This is true; AnyConnect will work fine if DNS is working and TCP port 443 is open. However, AnyConnect will try to use the DTLS protocol first which uses UDP port 443, if it fails than the client will fall back to use SSL for the transport of user data. The reason that AnyConnect prefers DTLS is that DTLS has less delay because of the connectionless nature of UDP and thus performance is better then with a SSL tunnel.

It is very easy to check if you are actually using DTLS in the AnyConnect client:

Cisco Asa Vpn Client Download

Conclusion:
If you filter the network traffic destinate to a Cisco IOS webvpn router or Cisco ASA firewall in the remote access / VPN block in your network don’t forget to open UDP port 443 also.. 🙂