Router to Router VPN working, but NT Domain login times out?

[oggy1]

I have a successful router to router (Cisco) IPSEC VPN working, DHCP works at remote branch, DNS and WINs are both working (Wins clients at remote branch are registered on WINs server, and in DNS server).

I can ping across the VPN between internal networks successfully. When I try to login to the domain however, I get the login prompt (so I know it's communicating to the PDC across the VPN) and after submitting a valid username and password, it times out with a message 'specified name is no longer available'.

If I enter the DNS domain name after authenication, then it times out with 'semaphore timeout has expired' (or something similar).

The same laptop successfully logged into the domain at the head office, and it can also login when running the Cisco VPN client when connected to the internet, BUT when connected to the internal LAN at the remote branch, then logging into the domain times out after entering username/pwd at login prompt.

It's not router access lists or fw inspect names, since removing these makes no difference. It's probably some quirky name resolution thing or some other wonderfully weird Microsoft parameter config setting? Any ideas or suggestions most welcome!

 

[PaulGillespie]

I didn't think what you wanted was possible! as both sides are on differant subnets.

I'm trying to achive the same thing kind of but i'm using a DC at each end.

 

[oggy1]

I have moved 2 steps forward and 1 step back.
I changed checked 'NetBIOS of TCP/IP' to disabled on the workstation, and guess wot!? I successfully authenticated to the domain! Amazing I thought. Anyway, as is always required a reboot was requested, and subsequently, the PC 'hangs' on 'applying computer settings'.

The only way around this was to temporarily remove the patch cord to the LAN, and wait for the login prompt to appear. I am still trying to figure out what is really going on here. Particulary since using the Cisco VPN client works just fine to the same router VPN head office termination point and PDC.

 

[oggy1]

After much pulling of hair and gnashing of teeth, and WITH the aid of something called initiative and the use of personal gear and resources to recreate the problem in a lab environment, we were able to come up with a workaround to the problem of a Domain login NOT working over a Cisco router-to-router VPN network.

Here is the crux of the problem. During the login process Microsoft, in an effort to maximize the efficiency of the data transmission, is trying to transmit as much data as possible in the fewest number of packets (pretty reasonable idea actually), and in the process is setting something called the defrag bit to 'do not defragament', also, the maximum TCP segment size is probably being negotiated at 1480 or close to 1500 bytes.

This is normally works just fine. Trouble is that with VPNs, extra bytes are added to the segment size due to encapsulation and is causing the Max Transmission Unit size to exceed 1500 bytes. This then causes the data session to just 'hang' mid-stream during the domain login process.

Here is what is required on the inside interfaces at either end of the Cisco routers to get around this problem:

interface "inside-interface" (e.g. fa0/0 or vlan10, etc)

! This causes the router to IGNORE the defrag bit setting on any incoming traffic to router
!
ip policy route-map clear-df
!
route-map clear-df permit 10
set ip df 0

And also on both inside interfaces:

ip tcp adjust-mss 1300


And then you need to reset both interfaces at either end or reload the router.
Regds,
Oggy1

 

[CliveN]

Hi Oggy1

Thanks for this info- while not exactly what I was looking for it gave me some important pointers. My question for your consideration is:
Our ISP manage the cisco router their MTU size is 1500, we run a SST VPN tunnel over this link between 2 shiva boxes, the MTU size on the shiva box is set to 1500 also, would you consider any value in adjusting this setting , we are getting "path too deep" messages when uploading files across this link , download is fine, a dos session throws a semaphore timeout. It is only the last month that these problems have come to light, the only factors that are known to have changed are PC configuration due to downloading MS XP updates [reference -

http://support.microsoft.com/default.aspx?kbid=817069

as an example] ,and an ISP upgrade of the router post msblaster and nachii virus.

Thanks
CliveN