The rest narrows the filter further to the destination TCP port being 443 and the destination host being the VPN server. 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. This command adds a rule to the chain called PREROUTING within the nat table, where packets arrive before the routing decision happens. One way is using NAT functionality from iptables: iptables -t nat -A PREROUTING -i $LAN_IF -p tcp -dport 443 -d $VPN_SERVER -j REDIRECT -to 443 When all this works, the last bit is to redirect traffic towards the VPN server to SSLH.
#Cisco anyconnect ports windows#
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. SSL/TLS clients send binary Client Hello packets that identify the protocol version and supported ciphers.SSH clients send plain text one-liners that identify the protocol and client version, while.This works reliably because they are really easy to tell apart upon the first packet: 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.Īnd 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. As netstat has shown, a TCP connection towards port 443 was kept open throughout the VPN session, and subsequent connections were allowed by theįiltering mentioned above – we could even see these SYN packets on the gateway. This left us with a single opportunity: keeping even the TCP port the same as the port used by the tunnel already. 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. 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 next idea was the VPN server itself since it had to be able to receive packets from the clients as part of normal operation. 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.
Our first stop was the gateway in our LAN towards the internet – and thus towards the VPN concentrator. So we embarked on a quest to find what could be done within the rules imposed by the VPN vendor. What others have already discovered: the routing table is modified (and kept in this state), while packets are further filtered, probably using kernel hooks.īoth IPv4 and IPv6 are affected by this filtering, and traffic towards additional network interfaces also got redirected. We started investigating on both supported platforms mentioned above and found
#Cisco anyconnect ports drivers#
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. 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. When that happens, connecting to the VPN seals off the client from the rest of the LAN.
Some VPNs allow split tunneling, however, Cisco An圜onnect and many other solutions offer a way for network administrators to forbid this.