Windows/NetBIOS & SNAT

Windows/NetBIOS & SNAT

[Nicholas Couchman]

I've done quite a bit of Google searching and haven't turned up anything definitive hear.  I have a few Windows XP machines that I want to put behind a Linux/iptables NAT configuration.  The domain controllers and WINS servers sit outside the NAT configuration.  On the Linux side, I've enabled ip forwarding, and added the following rule with iptables:

iptables -t nat -A POSTROUTING -s 172.16.34.0/24 -j SNAT --to-source 192.168.100.100

However, I'm getting the following error when trying to log on to Windows:
The system cannot log you on now because the domain DOMAIN is not
available.  I've loaded the nf_conntrack and nf_conntrack_netbios_ns modules in Linux, but this hasn't helped.  I've done some packet tracing, and when I look at tcpdump, on the "inside" interface, I see requests to the WINS system but never any replies.  When I look at packets on the "outside" interface, I see the SNAT'd requests from the 192.168.100.100 interface going to the WINS server on port 138, and I see the replies coming from the WINS server to the 192.168.100.100 IP address, port 138.  Herein lies my problem - I'm guessing that the Linux system itself isn't actually expecting the reply on port 138, and so it's discarding the packet.  My question is this: is there some rule I ought to put somewhere else in iptables to have these packets returned to the "inside" network, to the co
 rrect host?

Oh, yeah, one other thing - all iptables is doing is NAT - there are no firewall rules that would block trafffic, and the default policy is "ACCEPT".

Thanks,
Nick

Re: Windows/NetBIOS & SNAT

[Gerardo Fernandez]

2009/9/4 Nicholas Couchman <nick.couchman@yahoo.com>:
> I've done quite a bit of Google searching and haven't turned up anything definitive hear.  I have a few Windows XP machines that I want to put behind a Linux/iptables NAT configuration.  The domain controllers and WINS servers sit outside the NAT configuration.  On the Linux side, I've enabled ip forwarding, and added the following rule with iptables:
>
> iptables -t nat -A POSTROUTING -s 172.16.34.0/24 -j SNAT --to-source 192.168.100.100
>
> However, I'm getting the following error when trying to log on to Windows:
> The system cannot log you on now because the domain DOMAIN is not
> available.

In an environment almost equal to yours, without doing any packet
tracing, we've found that some XPs (I would say that just the first 3
or 4) can logon in the domain, but there is a point where noone else
can logon.

The only difference with your setup is the fact that we don't use a
WINS server.

--
Saludos.
Gerardo.
http://www.AjedrezVasco.com

Re: Windows/NetBIOS & SNAT

[Nicholas Couchman]

-Sigh- Well, Microsoft has done it, again.  I think I've finally located the problem, and the solution is going to be a bit more difficult - maybe impossible - for SNAT to handle (I think).  I was doing some packet sniffing and noticed that I was not getting any attempts to reply to messages sent on port 138 for my machines by my NAT router.  I started looking into the packets, and, guess what?  On NetBIOS datagram packets (port 138), Microsoft has decided to embed the IP address of the original requesting machine in the packet, rather than just using the information already on the IP header.  I'm guessing they did this to try to make an already unsecure protocol a bit more secure, but it is defeating the SNAT'ing I'm trying to do on my network.  In looking at the packet in Wireshark, the 
 "NetBIOS Datagram Service" portion of the packet has Source IP and Source Port fields.  So, in addition to standard NAT'ing, I'm going to have to "mangle" these fields
 in the packet, too.  I'm not even sure that's possible, even in a connection tracking helper module - any hints would be greatly appreciated.

-Nick

Re: Windows/NetBIOS & SNAT

[Mart Frauenlob]

Nicholas Couchman wrote:
> -Sigh- Well, Microsoft has done it, again.  I think I've finally located the problem, and the solution is going to be a bit more difficult - maybe impossible - for SNAT to handle (I think).  I was doing some packet sniffing and noticed that I was not getting any attempts to reply to messages sent on port 138 for my machines by my NAT router.  I started looking into the packets, and, guess what?  On NetBIOS datagram packets (port 138), Microsoft has decided to embed the IP address of the original requesting machine in the packet, rather than just using the information already on the IP header.  I'm guessing they did this to try to make an already unsecure protocol a bit more secure, but it is defeating the SNAT'ing I'm trying to do on my network.  In looking at the packet in Wireshark, th
 e "NetBIOS Datagram Service" portion of the packet has Source IP and Source Port fields.  So, in addition to standard NAT'ing, I'm going to have to "mangle" these fields
>  in the packet, too.  I'm not even sure that's possible, even in a connection tracking helper module - any hints would be greatly appreciated.
>
> -Nick
>   
Hello,

I don't think it's possible what you want.
The first thing a wins client needs to do is, to register itself in the 
wins database. Now if you exchange the ip headers and the data in the 
data fields, your wins server will get registration requests from and 
for the same host over and over again. Even if that somehow works, your 
future queries will be messed up, as all answers of the wins server will 
point to the same ip address.

Regards

Mart

Re: Windows/NetBIOS & SNAT

[Nicholas Couchman]

> Hello,
> 
> I don't think it's possible what you want.
> The first thing a wins client needs to do is, to register itself in the wins database. Now if you exchange the ip headers and the data in the data fields, your wins server will get registration requests 
> from and for the same host over and over again. Even if that somehow works, your future queries will be messed up, as all answers of the wins server will point to the same ip address.
> 
> Regards
> 
> Mart

You may be right, but WINS is actually not the problem.  The WINS traffic (NetBIOS NS or NBNS) is done over port 137.  From what I can tell, this actually appears to be working okay - traffic is making it between the servers inside the NAT'd network and the WINS servers.  The traffic going over port 138, the NetBIOS Datagram Service, or NBDS, is what's the problem, because the NBDS frames have the IP address of the sending machine embedded in them in addition to the IP address in the IP header.  When an NT server replies to a NBDS request, it looks like it just ignores the IP header and uses the source IP and source port information embedded in the NBDS request.  So, you may be right that what I want to do is impossible, because it means mangling the actual NBDS request in addition the IP 
 header information, which I don't think can currently be done in Netfilter.  At best, I'm going to be writing some sort of application or module that does this - but
 I'm not even sure that will work, or that I'm really up to that challenge.

-Nick

Re: Windows/NetBIOS & SNAT

[Pascal Hambourg]

Nicholas Couchman a écrit :
> 
> mangling the actual NBDS request in addition the IP header information,
> which I don't think can currently be done in Netfilter.

NAT helpers such as nf_nat_ftp, nf_nat_sip do mangle addresses which are
embedded in the TCP or UDP payload.

Re: Windows/NetBIOS & SNAT

[Mart Frauenlob]

Nicholas Couchman wrote:
> I've done quite a bit of Google searching and haven't turned up anything definitive hear.  I have a few Windows XP machines that I want to put behind a Linux/iptables NAT configuration.  The domain controllers and WINS servers sit outside the NAT configuration.  On the Linux side, I've enabled ip forwarding, and added the following rule with iptables:
>
> iptables -t nat -A POSTROUTING -s 172.16.34.0/24 -j SNAT --to-source 192.168.100.100
>
> However, I'm getting the following error when trying to log on to Windows:
> The system cannot log you on now because the domain DOMAIN is not
> available.  I've loaded the nf_conntrack and nf_conntrack_netbios_ns modules in Linux, but this hasn't helped.  I've done some packet tracing, and when I look at tcpdump, on the "inside" interface, I see requests to the WINS system but never any replies.  When I look at packets on the "outside" interface, I see the SNAT'd requests from the 192.168.100.100 interface going to the WINS server on port 138, and I see the replies coming from the WINS server to the 192.168.100.100 IP address, port 138.  Herein lies my problem - I'm guessing that the Linux system itself isn't actually expecting the reply on port 138, and so it's discarding the packet.  My question is this: is there some rule I ought to put somewhere else in iptables to have these packets returned to the "inside" network, to the 
 correct host?
>
> Oh, yeah, one other thing - all iptables is doing is NAT - there are no firewall rules that would block trafffic, and the default policy is "ACCEPT".
>
> Thanks,
> Nick
>   
Hello,

I'm just guessing, but as you do source nat, the wins server will only 
see requests from the nat source and will only reply to that address - 
trying to assign a netbios name to 192.168.100.100. I don't know about 
nf_conntrack_netbios_ns, but maybe you would need something like 
nf_conntrack_nat_netbios_ns, which I don't know if it exists.
But, do you really need the nat? Why not add the proper routes for the 
networks? There nf_conntrack_netbios_ns may do it's job within a simple 
filtering ruleset.

Regards,

Mart

Re: Windows/NetBIOS & SNAT

[Nicholas Couchman]

> Hello,


> I'm just guessing, but as you do source nat, the wins server will only see requests from the nat source and will only reply to that address - trying to assign a netbios name to 192.168.100.100. I 
> don't know about nf_conntrack_netbios_ns, but maybe you would need something like nf_conntrack_nat_netbios_ns, which I don't know if it exists.
> But, do you really need the nat? Why not add the proper routes for the networks? There nf_conntrack_netbios_ns may do it's job within a simple filtering ruleset.

> Regards,

> Mart

Well, I think I've found part of the problem.  The nf_conntrack_netbios_ns module only operates on port 137, not on port 138.  I don't know exactly what the difference is, but it seems that all my WINS queries are attempting to go across on port 138.  So, this explains why loading the nf_conntrack_netbios_ns module was not helping.  I've now taken to trying to write a conntrack module that will cover port 138, but this isn't so simple a task as I had first imagined.  Upon loading my newly written module, I start to see packets show up in the conntrack table, but no replies are ever registered.  Weird, but I'll keep working.

As far as the nf_conntrack_nat_netbios_ns module goes, no, it doesn't exist in the kernel, but I don't see any nf_conntrack_nat* modules their, either, so I'm thinking that the standard nf_conntrack modules are supposed to cover NAT in addition to standard routing.

The reason I'm resisting creating another subnet with proper routes is because there are only 6 machines on this subnet.  Sure I would save myself some time - it'd be done by now - but it' be nice to get this working, both to save myself another route/subnet and for future endeavors.

-Nick

Re: Windows/NetBIOS & SNAT

[Pascal Hambourg]

Hello,

Nicholas Couchman a écrit :
> 
> Well, I think I've found part of the problem.  The
> nf_conntrack_netbios_ns module only operates on port 137, not on port
> 138.  I don't know exactly what the difference is, but it seems that all
> my WINS queries are attempting to go across on port 138.

Port 137 is NetBios Name Service.
Port 138 is NetBios Datagram Service.
WINS is supposed to be Microsoft's implementation of Netbios Name
Service, so I am a bit surprised that WINS queries are sent on port 138.

[...]
> As far as the nf_conntrack_nat_netbios_ns module goes, no, it doesn't
> exist in the kernel,

If it were to exist it would be named ip_nat_netbios_ns, not
nf_conntrack_nat_netbios_ns. But IIUC the nf_conntrack_netbios_ns helper
module was specifically designed to handle replies to broadcast NBNS
queries, as the generic UDP conntrack handles only unicast, not
broadcast (the unicast source address in the reply does not match the
broadcast destination address in the query). There would be no point in
a NAT helper module.

> but I don't see any nf_conntrack_nat* modules their, either,
> so I'm thinking that the standard nf_conntrack modules are supposed to
> cover NAT

No, there are dedicated NAT helper modules. Search for nf_nat_* instead.

> in addition to standard routing.

s/standard routing/connection tracking/

Re: Windows/NetBIOS & SNAT

[Nicholas Couchman]

> > 
> > Well, I think I've found part of the problem.  The
> > nf_conntrack_netbios_ns module only operates on port 137, not on port
> > 138.  I don't know exactly what the difference is, but it seems that all
> > my WINS queries are attempting to go across on port 138.
> 
> Port 137 is NetBios Name Service.
> Port 138 is NetBios Datagram Service.
> WINS is supposed to be Microsoft's implementation of Netbios Name
> Service, so I am a bit surprised that WINS queries are sent on port 138.

Sorry, I was confused earlier - it actually isn't WINS traffic going over port 138, it's logon request traffic.  The WINS traffic is actually functioning correctly on port 137 - the WINS requests are sent & NAT'd correctly, and the responses are received.  For the logon traffic, I found that the NetBIOS Datagrams have the source IP & port embedded in the payload instead of just using the IP header information, which, I believe is what's causing problems for NetBIOS logons over NAT.  I'm guessing that the NT server receives the logon request, unpacks the data, and grabs the source IP & port embedded in the payload and uses that as the return destination rather than using the IP header information for that.

> 
> [...]
> > As far as the nf_conntrack_nat_netbios_ns module goes, no, it doesn't
> > exist in the kernel,
> 
> If it were to exist it would be named ip_nat_netbios_ns, not
> nf_conntrack_nat_netbios_ns. But IIUC the nf_conntrack_netbios_ns helper
> module was specifically designed to handle replies to broadcast NBNS
> queries, as the generic UDP conntrack handles only unicast, not
> broadcast (the unicast source address in the reply does not match the
> broadcast destination address in the query). There would be no point in
> a NAT helper module.
> 
> > but I don't see any nf_conntrack_nat* modules their, either,
> > so I'm thinking that the standard nf_conntrack modules are supposed to
> > cover NAT
> 
> No, there are dedicated NAT helper modules. Search for nf_nat_* instead.
> 
> > in addition to standard routing.
> 
> s/standard routing/connection tracking/

I'll look and see what I can find for nat modules - I did not see anything with *nat* in it in the net/netfilter directory in the Linux source tree.

Thanks,
Nick

Re: Windows/NetBIOS & SNAT

[Pascal Hambourg]

Nicholas Couchman a écrit :
> 
> I'll look and see what I can find for nat modules - I did not see
> anything with *nat* in it in the net/netfilter directory in the Linux
> source tree.

It is in located in net/ipv4/netfilter/ because NAT is IPv4-specific.