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.
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.
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.
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 !
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?
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.
Here's the complete config: (minus passwords, etc)
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
logging queue-limit 100
enable secret 5
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
netbios-name-server x.x.x.x y.y.y.y
no ftp-server write-enable
crypto ipsec client ezvpn test
group xxxxxxxx key xxxxxxxx
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
no ip address
no ip mroute-cache
no atm auto-configuration
no atm ilmi-keepalive
no atm address-registration
no atm ilmi-enable
encapsulation aal5mux ppp dialer
dialer pool-member 1
dsl operating-mode itu-dmt
ip address negotiated
dialer pool 1
ppp authentication chap callin
ppp chap hostname xxxxxxxx
ppp chap password xxxxxxxx
crypto ipsec client ezvpn test
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
no modem enable
line aux 0
line vty 0 4
exec-timeout 120 0
password 7 xxxxxxxx
scheduler max-task-time 5000
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)
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?
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?
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.