Re: WINS Registration Issue through IPSEC VPN

["Ben Nagy" <ben () iagu net>]

Mods on crack! Mods on crack! Welcome to
firewalls-and-general-sysadmin-wizards! ;)

Anyway...

You've basically answered your own question. WINS doesn't work through some
NAT implementations.

Normally with an IPSec VPN you would be assigning clients addresses on your
internal network and NAT shouldn't be an issue. I don't know why you're
"forced to NAT", but that's a different story - intuitively the client
should register as multihomed (one address on the remote LAN and one address
that the VPN has assigned to them) and things should just work. Anyway, it's
not really relevant.

On W2K clients you can disable NetBT (netbios over TCP/IP) which will stop
the name registration. On NT4 I don't see why just disabling the WINS client
binding under the TCP properties shouldn't work. On the server side...you
should probably do all the research yourself - like 'em or loathe 'em, MS do
provide pretty good documentation for their own stuff. You could disable
WINS resolution on the servers (but that has downsides) or change the
NetBIOS node type, but both of those solutions mess with the network
performance.

Good luck.

ben
(Paul and mjr - you know I'm kidding about that crack thing...right? Right?
I just x97%###Le0: NO CARRIER)

----- Original Message -----
From: "VanCleave Phillip G" <Phillip.VanCleave () phs com>
To: <firewall-wizards () honor icsalabs com>
Sent: Monday, January 20, 2003 7:19 PM
Subject: [fw-wiz] WINS Registration Issue through IPSEC VPN


> Users mapping from their VPN client are unable to access Microsoft
resource
> domain shares. It appears to be a WINS validation issue. The following was
> supplied by the engineer working the issue.
>
>
> What we have identified is that it is a netbios issue that occurs when the
> server is asked to map a drive, and it queries WINS to verify the
requestor.
> When using the VPN, the client registers with WINS but with the actual
> address of the workstation, not his NAT'ed address, so when the server
> queries WINS, he gets the wrong address for routing back to the client and
> as such drops the connection request. We're forced to NAT for obvious
> routing reasons and we can't edit the WINS packets from the client prior
to
> registering, so the next step is to verify server configs to see why some
> seem to query WINS and others don't. Another angle is to see if we can
stop
> the WINS registration process from the remote client. Early tests seem to
> indicate that if the client is not registered, the server will respond
> correctly to the map request.


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards