PDC on external network

Steve Langasek vorlon at dodds.net
Fri Mar 5 16:38:42 GMT 1999

On Fri, 5 Mar 1999, Sanjeev Ananth wrote:

> I am running a linux server (Red Hat 5.1) with 2 network interfaces , 
> one connecting to the internet and the other to the internal network.

> Using IPfwadm all hosts on the internal network access the internet.  
> The only config statements  in rc.firewall are

> ipfwadm -F -p deny
> ipfwadm -F -a m -S   -D

> Using this have no problem to access anywhere from the internal network 
> and no reason for the external network to access the internal until now.  

> I have connected an NT Server 4.0 on the external network which is a 
> PDC.  From an NT workstation on the internal network when I try to 
> connect to the NT domain - I get a 'The domain controller for this 
> domain cannot be located' message.

> Can anyone tell me what 'ipfwadm' needs to allow authentication?

I don't know specifically what's going to be failing here, not having looked
at this part of the SMB protocol, but there are a couple of problems you're
likely to run into.  If the PDC has to send data back to the workstation on a
different port than the one data was being received from, IP Masq will fail to
catch it; if the PDC expects the src addr in the IP header to match an IP it
has on record, or that is contained in the packet data itself, you'll also see
a failure.  Perhaps the PDC is picking up multiple machines behind the
firewall all coming from the same IP (the masqing box), and this is causing a
problem somehow...  I don't know.  I don't think it's a simple problem with
WINS resolution, since in my experience WINS works through masqing firewalls
just fine, but beyond that I have no idea.

Someone here may be able to tell you easily what parts of the protocol are
failing, and it may be something that can be fixed w/ the kernel port
auto-forwarding stuff or with the addition of a kernel masqing module (like
ip_masq_ftp).  You might also try sniffing some of the traffic from the
firewall box, to see what's being sent where.

If it can't be fixed with a firewall rule or kernel module--and this is quite
possible, since the workstation is registering with WINS using the IP it
knows, a private IP that's inaccessible from the network--the other option
would be to set up an SMB masqing proxy daemon on the firewall machine that
would take the SMB traffic from inside the firewall and translate it for use
outside.  I've been vaguely entertaining the notion of writing such a program,
since I have some masqueraded networks of my own that I'd like to link
together, but I don't have time to do any serious work on it right now, and
probably won't for a couple months to come.

I'm always willing to donate some time as a debugger, tho. ;)

-Steve Langasek

More information about the samba-technical mailing list