Re: Firewall blocking broadcasts in between NT Servers

[Richard Sharpe <sharpe () ns aus com>]

At 09:18 PM 7/15/98 -0400, roger nebel <roger () homecom com> wrote:
> Another possibility is that if the firewall you are using has Network
> Address Translation (NAT) or even IP masquerading, and your MS boxes are
> talking SMB over TCP/IP (NetBT), then the firewall can't translate the
> NetBEUI addresses since most, if not all, firewalls don't know how to
> open up the SMB headers to fix the NetBEUI addresses correctly according
> to your NAT mappings.  Of course I'm assuming you have all the net
> masks, gateways, and routes correctly set...

Ummm, this sounds a little confused. NetBEUI (NetBIOS Extended User Info)
is an ethernet only protocol, and as such is not routable and will not
carry IP addresses (except possibly in the final data area where they may
appear in SMB data as a result of IP addresses in files).

Since you also mention NetBT, what you may be referring to is WINS and
other Name lookup stuff that Microsoft Windows does, which definitely will
carry IP addresses that will need translation by the FW if NAT is in use
inside the network to be protected. NetBT is NetBIOS over TCP/IP, which
includes name lookup and SMB functions. An NetBT connection may result in a
redirect, which will contain an IP address that may need to be translated,
but all name lookup responses will need to be translated as well.

When a Domain Controller comes up it tries to register in the WINS server,
and checks to see if the names <DOMAIN>1c and <DOMAIN>1d are registered to
determine if a PDC already exists. Also, I believe that the PDC logs onto
BDCs using a special machine account, and it gets the IP address for the
BDC from WINS, so if the info is wrong, things will not work.

What is probably needed in that case is a WINS proxy.  I suspect that an
SMB proxy is not needed, as I don't remember any SMBs which carry IP
addresses that may need translating.

> good luck with the rest of the test
>
> Marriott, Charles wrote:
> > The IIS server is looking for a registered master browser and domain
> > controller in it's WINS server database and not finding it.
>
> snip
>
> > -----Original Message-----
> > From: borkin () netquest com [mailto:borkin () netquest com]
> > Sent: Monday, July 13, 1998 7:04 AM
> > To: firewall-wizards () nfr net
> > Subject: Firewall blocking broadcasts in between NT Servers
> >
> > Hello,
> >
> >   I am on a mailing list for people studying for their MSCE's and this
> > problem came across.. no one seems to be able to come up with a solution
>
> snip
>
> > TIA,
> >
> > Mike Borkin
> >
> > original message follows----------------------------------
> >
> > Hi all,
> > I have an NT4 server running IIS, which is a member (non-DC) server in a
> > domain and has now been moved behind a firewall. The PDC and the only
> > BDC are still in front of the firewall; as are the WINS servers.
> >
> > I've punched holes through the firewall for TCP:80, TCP:139, UDP:137 and
> > UDP:138, but domain synchronization and authentication no longer work.
> > The server can see the PDC and BDC when they're called by name, but it
> > can't find them when it's looking for the domain. This error message is
> > filling the log:
> >
> >         5719
> >         No Windows NT Domain Controller is available for domain ABC.
> >         (This event is expected and can be ignored when booting with the
> > 'No Net' Hardware Profile.)
> >         The following error occurred:
> >         There are currently no logon servers available to service the
> > logon request.
> >
> > I enabled an LMHOSTS file on this server to tell it where the DCs are,
> > but it didn't help (tried with and without WINS).
> >
> > When I run Usrmgr on the server, it comes up with its local accounts, as
> > expected.  When I tell it to change domain to ABC, it fails because no
> > DCs can be found.  When I tell it to change domain to the PDC, \\ABC-PDC
> > it gives me a message saying that ABC-PDC is a controller for domain
> > ABC; focus will be set to ABC.  That works.  So, it sees the domain when
> >
> > it looks for the DCs but it doesn't see the DCs when it looks for the
> > domain.
> >
> > The firewall logs (supposedly) all traffic that passes (or attempts to
> > pass) through.  It shows nothing being blocked either to or from
> > thisserver.  Help?!  What am I missing?  Thanks in advance
> >
> > Wayne van Velthoven, MCP
> > National Research Council Canada
> > wayne.vanvelthoven () nrc ca <mailto:wayne.vanvelthoven () nrc ca>
>
> snip
>
> > Hi,
> >
> > No, I haven't gotten it solved, yet.  One person on list suggested using
> > an LMHOSTS file, but I had already tried that without success.  He was
> > right in that the firewall would be blocking the broadcasts, but I
> > thought using WINS and/or LMHOSTS was the right way to deal with that.
> > Neither has worked.
> >
> > I found a Knowledge Base article (Q179442) that has another port (135)
> > listed with the others that I already opened (137, 138 and 139).  So I
> > added 135, but again, no luck.  The article also says "All ports above
> > 1024 for RPC Communication".  I haven't done that yet - I thought that
> > applied to the other end.  Also, the firewall hasn't logged any
> > (attempted) activity in that range.
> >
> > Here's how the lmhosts file from that server looks:
> > 100.10.10.10     ABC-PDC      #PRE #DOM:ABC
> > 100.10.10.11     ABC-BDC1     #PRE #DOM:ABC
> >
> > Any insight would be appreciated.  Thanks in advance.
> >
> > Wayne van Velthoven, MCP
> > National Research Council Canada

Regards
-------
Richard Sharpe, sharpe () ns aus com, NIC-Handle:RJS96
NS Computer Software and Services P/L, 
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080, 
Samba, Linux, Apache, Digital UNIX, AIX, Netscape, Stronghold, C, ...