Cisco RV VPN - Attempt to Compromise Security

Hello -

I just setup a Gateway-to-Gateway VPN using two Cisco RV042 firewalls (to keep costs down) to support a temporary office.  The VPN works correctly in that workstations at the remote office can contact the server and other resources at the main office.  However we seem to have a 'rolling' error wherein some of the VPN workstations can't access server resources and instead get the dreaded 'Attempt to compromise security' message.  I have been over everything I and Google can think of so I am hoping someone here can offer some advice.  Here are the specs on the VPN and network:

Windows SBS 2011 Network (fully patched)
Single domain controller at main location
Windows 7 workstations at remote location
Two Cisco RV endpoints (fully patched)
Windstream Metro Ethernet at main location
Verizon DSL at remote location (modem is NOT bridged)
All workstations use the single domain controller as their only DNS server

I have ensured that all workstations are using the domain controller as their only DNS server and that name resolution is working correctly.  I can ping the DC from the workstations but anything that requires Kerberos authentication simply doesn't work.  I have played with MTU settings, NAT Traversal, etc. (everything is currently back to the default configuration.  If I shut everything down at the remote location and bring it all back up a few workstations will simply refuse to connect.  If it bring it all down and back up again a different set of workstations will refuse to connect.  There are only 7 workstations at the remote location and bandwidth/throughput is good (no problem opening files or accessing the Exchange server when they properly authenticate).  There is a wireless network at the remote location (just an access point hanging off the RV) and sometimes switching from wired to wireless (or vice versa) will allow a previously non-working workstation to connect.  

The only issues I can think of would be bandwidth related, or just the fact that I went cheap and used RV models.

This has me absolutely puzzled.  Any thoughts would be greatly appreciated.
Who is Participating?

Improve company productivity with a Business Account.Sign Up

Rich RumbleConnect With a Mentor Security SamuraiCommented:
I hadn't thought of a split tunnel as an issue, but it very well could be, and especially if the weight of the route or metric of the interface affects where it sends traffic. If the users have a wifi connection and a wired one (docking station perhaps) that could also make it act weird.
Cached creds shouldn't give you that error "Attempt to compromise security". I know you can try to force kerberos to use TCP instead of UDP.

It's always weird when you have seemingly sporadic connections even when it's the same hosts.
Rich RumbleSecurity SamuraiCommented:
That error is almost always related to Kerberos, and typically TCP/UDP port 88 is being filtered at the workstation. Some VPN software use their own Firewall rules, and that might be filtered. I would check to make sure the network's are not filtering port 88 (both tcp and udp)
You may want to install wireshark and verify port 88 is working or getting /sending responses.
intcomserAuthor Commented:
Hi Rich - ordinarily I would agree, but as some workstations can authenticate successfully and others can't (sometimes the same workstation will be able to authenticate correctly one time and then upon a reboot fail authentication) I don't think this is the issues.  This is a hardware based VPN using IPSec and it is passing all traffic between the two sites.  Could increasing the Kerberos timeout possibly address this issue?  If so can you tell me if creating and modifying this registry key on the DC is still valid?

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]KDCWaitTime (30 by default; thinking about increasing to 60 or 90).
btanConnect With a Mentor Exec ConsultantCommented:
Probably you already know but thought share on to trigger further inputs...

Most of the time, this error is when your machine can't connect to the to the KDC.
Pls see @ 

Lots have said to turn off split tunneling on your clients quite simple. Think on this disabling the split tunneling option generates a heavier load on VPN servers. But from a security perspective is this a safer method. Probably, the only thing what you need to do is also turn off the option "Use default gateway on remote network" on your VPN connection.
Pls see @

Another "school of thought" can also be some sort of problem with cached credentials (adding to the earlier mentioned inability to contact the DC). E.g. VPN setting does not set the DNS servers to your local Domain Controllers.
Pls see @

Not specific to Cisco but others
Pls see @

Previously, the remote site's VPN router handed out DHCP leases with the remote site's ISP's DNS for the DNS entries (that was the default behavior).

I hardcoded the my AD DCs' IP addresses into the DHCP server of the remote firewall such that any lease it hands out to clients will use the DCs as DNS servers and now things are a lot better. No more of the authentication errors even after leaving the laptop idle (but connected) overnight.
intcomserAuthor Commented:
Hi guys - thanks for the suggestions; split tunnelling was disabled on this VPN.  I ended up having to take down the VPN and revert back to Citrix.  I will revisit this issue at a later time.  Thank you again.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.