A few weeks ago this was asked on one of the forums I post in. For a long time the ASA didn’t support DHCP relay then finally in version 9 it was added. The question was, can I provide DHCP relay but have the DHCP server on another site (connected via VPN).
Well I wasn’t sure, so I put it on the mental back burner, until I got my EVE-NG server rebuilt. Below I knocked up a simple two site setup, then connected them via IPSEC VPN. The DHCP client is Windows 7, and the DHCP Server is 2012 R2.
Solution
To be honest it could not be simpler! Obviously the site to site VPN needs to be up or it wont work! The config is simply added to the ASA on the DHCP Client side, (or the left hand one in the example above).
This one had me well and truly stumped! The client has two sites and from their remote site they could not open a remote Desktop connection to a server at the main site.
RDP Stuck at Securing remote connection.
At first, because the client had SBS at their main site I assumed this was the problem, but sadly it was not.
Solution
The following process goes through the steps taken to identify and rectify the problem.
1. Firstly, I’m assuming you can ‘ping’ the target server both by name and IP address, if you can’t do this, then read no further, you have a communication problem, fix that first!
2. Check that RDP (TCP Port 3389) is open by attempting to Telnet to that port on the destination server.
If you simply see a ‘cursor’ then the port is open, if not it will give you an error. (If that is the case then you need to look at comms to make sure TCP Port 3389 is not being blocked, either by a hardware firewall/router, or a software firewall on either of the machines.)
3. Check no third party security software is blocking RDP, by issuing the following command;
[box]
fltmc[/box]
This indicates the machine I’m on is running, “Trend Micro’.
4. Try disabling the security software to see if that rectifies the problem,
After much hand wringing, and a few days of rebuilding firewall VPNs, patching servers, and installing hot-fixes, I admitted defeat and got Microsoft on the phone.
5. The fist thing they found, was if they attempted to open a UNC path to the destinations server IP address it worked.
6. BUT If they did the same to the server name it failed.
Error:The specified network name is no longer valid
7. Normally this is an indication that the secure channel between this machine, and the target machine is broken. Normally this can be fixed with the following commands;
[box]
net stop KDC
klist purge
netdom resetpwd /server:{IP address of domain controller}/userd:{your-domain-name}administrator /passwordd:*
Then supply the domain administrators password
net start KDC
[/box]
However this did not fix our problem, but indicated that it was not just RDP that was failing. Both the machine we were using, and the destination machine were domain controllers, so domain replication was checked and the following was found;
Event ID 1865
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1311
Task Category: Knowledge Consistency Checker
Level: Error
Keywords: Classic
User: ANONYMOUS LOGON
Computer: your-server-your-domain.com
Description:
The Knowledge Consistency Checker (KCC) has detected problems with the following
directory partition.
Directory partition: CN=Configuration,DC=your-domain,DC=com There is insufficient site connectivity information for the KCC to create a spanning tree replication topology. Or, one or more directory servers with this directory partition are unable to replicate the directory partition information. This is probably due to inaccessible directory servers. User Action Perform one of the following actions: – Publish sufficient site connectivity information so that the KCC can determine a route by which this directory partition can reach this site. This is the preferred option. – Add a Connection object to a directory service that contains the directory partition in this site from a directory service that contains the same directory partition in another site.
Event ID 1311
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1566
Task Category: Knowledge Consistency Checker
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: your-server-your-domain.com
Description:
All directory servers in the following site that can replicate the directory partition
over this transport are currently unavailable.
Event ID 1566
Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Event ID: 1865
Task Category: Knowledge Consistency Checker
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: your-server-your-domain.com
Description:
The Knowledge Consistency Checker (KCC) was unable to form a complete spanning tree network topology. As a result, the following list of sites cannot be reached from the local site.
Sites:
CN=Your-OU,CN=Sites,CN=Configuration,DC=your-domain,DC=com
8. So we DO have a communications problem, some things work others do not! Let’s make sure our traffic is not getting fragmented, you would expect a packet of 1500 bytes to be able to get though, ours did not, using trial and error Microsoft ascertained that 1320 was the highest we could get though without error.
[box]
ping -f -l {packet size}
[/box]
Note: To get the figure exactly right, you need to keep decreasing the packet size by 1, then when you have found the largest size permissible, you need to add 28 to it (for the overhead of the IP Header).
9. So the MTU was ‘locked’ at BOTH ENDS (source machine and destination server). To do so, Windows Key+R > regedit > Navigate to;
Note: There may be many ‘keys’ here, check each one in turn, to find the one that equates to the IP address on your machine, (the one you are working on).
When you have located the correct key, create a new DWORD (32 bit) value (or edit one if it exists) set the DECIMAL value to the same size that you could get though without error in step 8.
10. Reboot the machines and try again.
Related Articles, References, Credits, or External Links
Special thanks and credit to Harprit Singh at Microsoft, for his hard work and outstanding support.
It’s been ages since I has to do this, I usually just manage firewalls via SSH from outside. But I was out on a client site last week and needed to connect to to my ASA, so I simply connected in via AnyConnect;
Note: The same procedure is applicable if you are an IPSECVPN client, L2TPVPN client, or simply coming in over a site to site VPN link.
And attempted to SSH, no joy, I tried the ASDM, nothing. So basic troubleshooting kicked in, and I tried to ping its inside interface;
Solution
Normally, you would see this if you forgot to add ‘management-access inside‘ to the firewall. I was sure I had done, so I connected to one of my servers and then SSH’d to the firewall to check, and that command was there?
The cause of the problem was a change made in version 8.4(3). I had to edit the NAT rule for the remote traffic. But I’ll cover ALL the bases in case you are missing anything else.
1. Connect to the the firewall via CLI, and check management-access is on, on the interface you are connecting to, mines the ‘inside’ interface yours might be management or some other name you have allocated to the interface in question.
[box]
User Access Verification
Password:
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# show run management-accessmanagement-access inside
PetesASA#
If yours is different or missing;
PetesASA# configure terminal
PetesASA(config)# management-access inside [/box]
2. Now I know, my remote VPN clients are getting a 10.253.254.x addresses, (show run ip local pool should tell you, unless you are using internal DHCP for the remote clients). After version 8.4(3) you need an extra command on the end of the NAT rule for that traffic. I’ll highlight the line below;
