VPN and Join Windows 2000 Domain

[mcarini]

We have recently activated a site-to-site Internet VPN connection based on IPSEC protocol. This VPN is used to connect a small branch office LAN to our Headquarter. The branch LAN is made of 4 W2K PCs while the W2K servers are located in our Headquarter.

From the branch office we are able to map network drives related to servers located in our Hq. Also name resolution from the branch office works fine. These PCs are configured for using name resolution services provided by name servers located in our Headquarter.

The strange issue is that we are not able to join these PCs to the W2K domain available in our HQ. This sounds strange because these problems don't happen when the connection between a branch office and our HQ happens through a leased line instead of a VPN Internet connection.

Any help to fix the problem is very appreciated.

Thanks in advance for your kind answer.

[mnaveen]

Hi,

I'm not sure but if joining PCs to a W2K domain involves some kind of multicasting or broadcasting, then you can't do that over an IPSec tunnel. You need to run GRE over IPSec to circumvent this problem.

Thanks,

Naveen.

[andrew.burns]

Hi,

I've been trying to troubleshoot this exact problem!

I've traced it as follows: the PC connected to the ethernet port of the 837 sends out a SAM logon request (directed packet to the PDC on port UDP/138) which responds with an unknown station reply. (directed packet back to PC on UDP/138)

The 837 see's this packet (using debug IP packet) but doesn't put it out the ethernet port so the PC never sees the reply.

All other services and applications work fine - only this doesn't work, and I've been trying for hours to get this working. Good to know it's not just me.

Andrew.

[mnaveen]

Hi Andrew,

I very much suspect your crypto access-list and any access-list on the Ethernet interface. If the 837 can see the packet and drops it without sending to the Ethernet interface, then look no further than 837. Thatz the culprit. Try adding another access-list with the correct UDP port information. If this also doesn't work, then troubleshoot with the following points.

The router can drop packets when

1. NAT is configured and incoming traffic doesn't match the access-list. To circumvent this, use NAT-T instead.

2. Policy settings on the Ethernet interface hinders normal operation. Give careful consideration to this !

3. Incoming traffic was expected to be encrypted but was received as clear text traffic.

Try them out and let us know. Good luck !

Naveen

mnaveen@cisco.com

[mcarini]

Andrew and Naveen,

many thanks for your attempts to fix my problem.

I was wondering whether the problem could be related to Kerberos protocol. This protocol is used to authenticated w2k workstation to a domain controller. kerberos use by default large UDP packets and these packets cannot be fragmented (DF bit is set to 1). When you use IPSEC there is an overhead lowering the effective data length. I know there is a way to configure W2k domain to use TCP instead of UDP.

What do you think about this ? Could this be the reason of the problem?

[jrhofman]

We are also having this problem. Below is a link for changing the Kerberos from udp to TCP. This did fix our problem but it's a patch as far as I'm concerned. I have not had a chance the trace down where UPD is failing within the VPN network.

http://support.microsoft.com/default.aspx?scid=kb;en-us;244474

[andrew.burns]

Hi Naveen,

Here's the complete config: (minus passwords, etc)

version 12.2

no service pad

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname Home_Router

!

logging queue-limit 100

enable secret 5

!

ip subnet-zero

no ip domain lookup

!

ip dhcp excluded-address 192.168.0.1

!

ip dhcp pool Home

network 192.168.0.0 255.255.255.248

default-router 192.168.0.1

netbios-name-server x.x.x.x y.y.y.y

lease 30

!

no ftp-server write-enable

!

crypto ipsec client ezvpn test

connect auto

group xxxxxxxx key xxxxxxxx

mode client

peer x.x.x.x

!

interface Ethernet0

ip address 192.168.0.1 255.255.255.248

ip helper-address n.n.n.n

crypto ipsec client ezvpn test inside

hold-queue 100 out

!

interface ATM0

no ip address

no ip mroute-cache

no atm auto-configuration

no atm ilmi-keepalive

no atm address-registration

no atm ilmi-enable

pvc 0/38

encapsulation aal5mux ppp dialer

dialer pool-member 1

!

dsl operating-mode itu-dmt

!

interface Dialer1

ip address negotiated

encapsulation ppp

dialer pool 1

dialer-group 1

ppp authentication chap callin

ppp chap hostname xxxxxxxx

ppp chap password xxxxxxxx

crypto ipsec client ezvpn test

!

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer1

no ip http server

no ip http secure-server

!

dialer-list 1 protocol ip permit

!

line con 0

exec-timeout 0 0

password 7 xxxxxxxx

login

no modem enable

stopbits 1

line aux 0

stopbits 1

line vty 0 4

exec-timeout 120 0

password 7 xxxxxxxx

login local

length 0

!

scheduler max-task-time 5000

!

end

As I said, everything works perfectly apart from the problem with logins - if you log in locally then you can basically do everything (map network drives, use email, browse the intranet, etc etc)

Andrew.

[andrew.burns]

Here's the problem:

The router is NAT'ing the source port from 138 to a low number (e.g. 7) but the PDC only ever replies to port 138 even when the source port is 7. I can see the packet getting decrypted but as there won't be a NAT translation for the returning packet I guess it just gets dropped.

I'm stumped for a solution though. Is this a bug?

Andrew.

[mostiguy]

You cannot NAT windows networking (netbios over tcp, SMB/CIFS, etc) packets. What is happening - are all the machines on that lan getting PAT'd to one ip address at headquarters?

[reiner.fink]

Although we havent found a complete solution, we have found some hints that might help:

The problem seems to occur only if you use dynamic crypto maps.

It doesn't occur with static crypto maps.

And it doesn't matter if you use gre or not.

It also doesn't occur with a pix at the remote site, at least if you use a pix at the central site.