Way around port 443 limitation when using NAT/port fowarding through firewall
I have a recent previous post about some related issues I was having with my new SSL312. One of the issues was tied to the fact that the SSL312 can only bind/listen on port 443, the standard SSL port. In my network, I have port 443 dedicated to forward to a pound reverse proxy, to handle all my secure website interactions with the public, so I cannot use 443 for my VPN access.
Since by HTTPS RFC specification, the incoming HTTP request headers have to be preserved to the endpoint, so as not to allow virtual hosts with SSL for obvious reasons (I may not be wording this exaclty correctly), one has to basically spoof this process on the client side.
If your public interface to your router is 188.8.131.52, and you have set an external port of 8999 to forward to your internal SSL312 at 10.1.2.20 at port 443, it won't work. The SSL VPN will still see the incoming request as:
So, if you still need to access your VPN via a different port than 443, you can try the following (it worked for me).
(1) Spoof your VPN domain to be localhost in your /etc/hosts (or equivalent) file.
(2) Set up ssh client and server on your local client host (I use cygwin on XP)
(3) ssh to your local client host from your local client host (i.e. ssh to yourself), and forward your local 443 port to your true destination:
ssh -L 443:your.vpndomain.com:8999 user@localhost
... Now any TCP traffic coming into your local client hosts' port 443 will automatically be tunneled to your.vpndomain.com:8898.
(4) Then, open up IE or Safari and go to your expected VPN URL
... Now the SSL312 will see
your.vpndomain.com [assuming 443]
(5) Log in and you should get your expected portal layout, and start doing whatever you do over the VPN.
So, I tried this and it worked for me. But now I'm having issues with the split tunneling. I have a VLAN internally that is restricted to a single class C of 10.2.16.1-10.2.16.255. I've configured the SSL312 to allocate 10 possible addresses to clients, 10.2.16.230-239. I've restricted the subnet to 255.255.255.0 for this. After I connect via the above method, it seems that some of the 10.* subnets at the external location I can still get access to, and others I can't. For example, I can get access to all of my development machines on 10.42.71.*, but I can no longer get access to my QA subnet 10.27.31.*. When I kill my VPN connection, I can re-gain my access to the 10.27.31.* subnet. Strange, since I limited my VPN client to that single specific class C. Anyone have any ideas?