Re: Windows/NetBIOS & SNAT

[Nicholas Couchman <nick.couchman@yahoo.com>]

> 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