[vpn-help] Empty Passwords

Kevin VPN kvpn at live.com
Mon Nov 18 21:21:06 CST 2013


On 09/11/2013 05:11 PM, Warenda, John M. wrote:
> Greetings,
>
<snip>
> configuring the connection, but when Shrew Soft VPN Client brings up
> the Xauth prompt, it appears to be rejecting a login with a blank
> password as invalid without actually trying to pass it to the server.
> I click "connect" and it simply refuses to, saying "please enter a
> valid username and password".  While a blank password certainly makes
> little sense, that's actually what was entered in the Cisco VPN
> client login procedure, and this client simply won't accept an empty
> password.
>
> For what it's worth, the reason this is coming up is that the vendor
> has users connecting to their VPN to access the software on their
> network, but (despite users only connecting to one server ever) they
> have the DNS of the client computer completely dominated, ruining the
> ability of users to get to intranet resources as long as the VPN is
> up.  My hope, since the vendor is complete incompetent and can't
> understand the nature of the issue, was that I could find an
> alternative product that I could prevent from hijacking the DNS on
> the client side.
>

Hi John,

First, a way around the no-password problem may be to use the 
command-line.  Shrew supports command-line operation, so you may be able 
to create a batch file that initiates a Shrew connection (which bypasses 
the VPN Connect dialog) and simply use the switch to pass a null string 
password.  I've not tried this, so I don't know if it will work.

With respect to your comments on the vendor's setup, it's a tricky 
problem.  Best security practice is to completely lock a VPN client into 
the VPN network, preventing an attacker bouncing from the Internet 
through the client machine into your network.  That sounds like what the 
vendor has done.

For the vendor to allow your users access to their own intranet would be 
difficult to configure without having to build a separate VPN for each 
client based on their own internal IP addresses.  If they instead build 
a split-tunnel configuration (which could be used by multiple customers) 
where only traffic to their server is sent through the VPN, they open 
themselves up to the attack vector I mentioned above.



More information about the vpn-help mailing list