> 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
