- Right-click the Cisco AnyConnect VPN Client log, and select Save Log File as AnyConnect.evt. Note: Always save it as the.evt file format. If the user cannot connect with the AnyConnect VPN Client, the issue might be related to an established Remote Desktop Protocol (RDP) session or Fast User Switching enabled on the client PC.
- First time posting here, I signed up to ask this question after a good search around. I also use Cisco AnyConnect VPN on a work laptop behind a pfsense firewall at home and the scenario is very similar to a post on this forum i.e. If I use a simple device such as an ISP provided modem/router, 4G nighthawk or hotspot'ing to the phone all is good.
- Ensure both TCP and UDP (443 or the port AnyConnect is configured to listen on) are open on your upstream firewall to receive connections. Below we see the AnyConnect port on the AnyConnect Settings page on the dashboard is set to port 443.
- Anyconnect Firewall Ports
- Cisco Vpn Client 64 Bit Windows 10
- Anyconnect Firewall-rule Client-interface
The anyconnect ask command specifies how the anyconnect client will be installed on the user’s computer. The none default anyconnect part tells the ASA not to ask the user if he/she wants to use WebVPN or anyconnect but just starts the download of the anyconnect client automatically. The anyconnect dpd-interval command is used for Dead Peer Detection. The remote user’s anyconnect.
Some VPNs allow split tunneling, however, Cisco AnyConnect and many other solutions offer a way for network administrators to forbid this. When that happens, connecting to the VPN seals off the client from the rest of the LAN. As it turns out, breaking this seal is not that hard, which can be useful for special cases like performing pentests over a VPN designed for average users.
In our case, we had to use a hardware token that only had drivers for Windows and Mac, while most of our tools run best (and are already installed) on Linux. We started investigating on both supported platforms mentioned above and found
what others have already discovered: the routing table is modified (and kept in this state), while packets are further filtered, probably using kernel hooks.
Both IPv4 and IPv6 are affected by this filtering, and traffic towards additional network interfaces also got redirected. So we embarked on a quest to find what could be done within the rules imposed by the VPN vendor. Our first stop was the gateway in our LAN towards the internet – and thus towards the VPN concentrator. The VPN client explicitly installed routes to keep that reachable, however, packets sent directly towards the LAN gateway never arrived there, leading us towards the idea of further kernel-based filters.
The next idea was the VPN server itself since it had to be able to receive packets from the clients as part of normal operation. However, the question is: how can you tell the packets apart on the gateway – as you still have to forward packets that are part of the normal VPN operator towards the VPN server. The trivial way was TCP port numbers, so we tried connecting to various TCP ports on the VPN server, but the gateway saw no SYN packets.
This left us with a single opportunity: keeping even the TCP port the same as the port used by the tunnel already. As netstat has shown, a TCP connection towards port 443 was kept open throughout the VPN session, and subsequent connections were allowed by the
filtering mentioned above – we could even see these SYN packets on the gateway. The only problem was to tell TCP streams apart at the gateway so that the VPN still worked while we could initiate connections outside of it at the same time.
And then it clicked: while trying to cope with the fact that many public (or semi-public) Wi-Fi networks filter everything besides TCP/443 (HTTPS), we had SSLH deployed to multiplex HTTPS and SSH on the same TCP port. This works reliably because they are really easy to tell apart upon the first packet:
- SSH clients send plain text one-liners that identify the protocol and client version, while
- SSL/TLS clients send binary Client Hello packets that identify the protocol version and supported ciphers.
SSH fits this case since its port forwarding features makes it possible to punch as many holes as necessary, regardless of the direction (VPN to LAN vs. LAN to VPN).
On Debian and its derivative systems, SSLH can be installed simply from the package with the same name (sslh) and configuration can be found in the file /etc/default/sslh as a command line, as this is where SSLH takes its options from. Below is the significant line:
This just means that SSLH listens on the internal (LAN) IP address of the gateway and based on the first packet received from a client that reaches this port, it either forwards it to
- a local SSH server (here we had the VPN client running on a Windows VM, and the Linux host had the SSH daemon running, hence the variable name
$VM_HOST_IP) or - the original VPN server.
Changes to the options can be applied under Debian and its derivatives by running /etc/init.d/sslh restart and the results can be tested in isolation first by connecting to TCP port 443 of the gateway, which should behave like the VPN server when using a TLS client like openssl s_client and act as an SSH server when using OpenSSH or PuTTY.
When all this works, the last bit is to redirect traffic towards the VPN server to SSLH. One way is using NAT functionality from iptables:
This command adds a rule to the chain called PREROUTING within the nat table, where packets arrive before the routing decision happens. The next part is the filter, which is important to avoid loops: we only apply the magic to packets where the network interface that the packet arrives through is the LAN interface. The rest narrows the filter further to the destination TCP port being 443 and the destination host being the VPN server. The last part is what happens when this rule matches: we invoke the REDIRECT target that rewrites
- the destination host to the IP address of the interface the packet arrived through (here: LAN interface) and
- the destination port to the one supplied (here: 443).
Anyconnect Firewall Ports
Since SSLH was configured to listen on TCP port 443 on the LAN interface, this results in the same effect as in the above SSLH testing scenario, where we connected directly to TCP port 443 on the gateway. And the best part is that the NAT solution provided by iptables is fully bidirectional, reply packets from SSLH are automatically translated back to make it seems as if they were sent by the VPN server.
Cisco Vpn Client 64 Bit Windows 10
So with the iptables rule in place, everything is ready for a real-life test. The progress of SSLH can be followed in syslog and as it can be seen below, after the AnyConnect client has connected properly, SSH connections can also get through, and everything gets routed to its proper destination.
Something strange would happen when I connected to a Firepower 2130 running Firepower Threat Defense with Cisco AnyConnect.
Basically, the AnyConnect client would contact the VPN gateway just fine, prompt for user credentials, authenticate and connect but then literally after about 3 seconds of being connected it would immediately drop and attempt to reconnect again. This would typically happen about two or three times before the VPN client would make the connection and stay connected and stable. I actually never had to re-enter my user credentials during this connect / reconnect process.
While there are some topics discussed that I found by doing a couple of searches, none of them explicitly talked about Firepower 2100 series appliances, Firepower Threat Defense, or Firepower Management Center (FMC) in particular. Most articles or forum discussions were centered around ASA Firewall topics, but I think the concept behind the fix is the same.
Anyconnect Firewall-rule Client-interface
A little bit of background regarding what device(s) are at play here:
- Cisco Firepower Management Center 6.2.3.7-51 running on VMware
- Cisco Firepower 2130 Next Generation Firewall on Firepower Threat Defense 6.2.3.7-51
- Cisco AnyConnect Secure Mobility Client 4.5.05030 on Windows 10 64-bit
Let’s take a look at some logs to see the problem in action.
Some information seemed to point to DTLS as being the problem and while the link here suggests this on ASA releases 9.0 and 9.1, the topic of MTU size caught my eye. Some other posts I read mentioned MTU as well, so I figured I would change the default MTU size from 1406 to something different and see if this helped, and it did.
Let’s see the problem first hand. Here are the message history logs from within Cisco AnyConnect:
What is the workaround to solve this “reconnecting” behavior?
Let’s go into FMC and change the MTU settings for the Group Policy associated with your Remote Access VPN setup.
Navigate to Objects tab > VPN > Group Policy > NAME OF YOUR RA VPN GROUP POLICY > Click on the pencil “Edit” icon.
Once you are on the Edit Group Policy screen, go to the “AnyConnect” Tab > SSL Settings > Change MTU Size to 1300 Bytes.
Don’t forget to click on Save at the bottom and then deploy the changes to the firewall that AnyConnect clients are connecting to. Grab some coffee, and check the latest weather update (since FMC takes a while to push policy… ugh). Once it is done, let’s connect through VPN and take a look at those AnyConnect message history entries again.
The logs show that the VPN connection was made, and then no reconnects were tried after the successful connection. I let the client stay connected for a few minutes just to make sure everything was OK, then manually disconnected at 11:27:06.
While leaving the MTU setting at 1300 bytes may not be possible for whatever environment you are working in, for now this seems to be working just fine. At any given time we have only about 50 concurrent AnyConnect sessions, so it’s a fairly low volume of remote workers that are being supported. If any long-term issues arise from this setup, i’ll be sure to update this post.
Thanks for reading, good luck!