From: Nicholas Couchman <nick.couchman@yahoo.com>
To: netfilter@vger.kernel.org
Subject: Re: Windows/NetBIOS & SNAT
Date: Wed, 9 Sep 2009 07:35:34 -0700 (PDT) [thread overview]
Message-ID: <952994.89264.qm@web33405.mail.mud.yahoo.com> (raw)
In-Reply-To: <4AA7B8D0.8020202@plouf.fr.eu.org>
> >
> > 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
next prev parent reply other threads:[~2009-09-09 14:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-03 23:28 Windows/NetBIOS & SNAT Nicholas Couchman
2009-09-06 22:01 ` Gerardo Fernandez
2009-09-09 0:54 ` Nicholas Couchman
2009-09-09 8:05 ` Mart Frauenlob
2009-09-09 12:08 ` Nicholas Couchman
2009-09-09 14:21 ` Pascal Hambourg
2009-09-08 10:14 ` Mart Frauenlob
2009-09-08 23:50 ` Nicholas Couchman
2009-09-09 14:16 ` Pascal Hambourg
2009-09-09 14:35 ` Nicholas Couchman [this message]
2009-09-09 15:45 ` Pascal Hambourg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=952994.89264.qm@web33405.mail.mud.yahoo.com \
--to=nick.couchman@yahoo.com \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox