NetBIOS datagram nat helper proposal

NetBIOS datagram nat helper proposal

[John A. Sullivan III]

It appears that we may need a netbios datagram NAT helper.  Unless we
can find a workaround, it we have encountered a couple of environments
where we need to NAT netbios datagram packets.  Since they have embedded
IP address information in the netbios header, this protocol breaks with
NAT.  We see the packets enter the server with the NAT address but the
replies are addressed to the original address as per the netbios header.

We have not seen such a helper within netfilter.  There appears to be a
simple helper for this at
http://suif.stanford.edu/~csapuntz/ip_nat_netbios.c

We are seeing if we have the resources to finish and polish this patch
and submit it.  It seems that we then simply post it to this list to
submit it.  Is that the correct procedure?

We are likely not to have the in-house resources to do this.  We might
be interested in sponsoring someone to write this patch.  If you are
interested, please contact me.  Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

If you would like to participate in the development of an open source
enterprise class network security management system, please visit
http://iscs.sourceforge.net

Re: NetBIOS datagram nat helper proposal

[Phil Oester]

On Mon, Sep 19, 2005 at 05:10:15PM -0400, John A. Sullivan III wrote:
> It appears that we may need a netbios datagram NAT helper.  Unless we
> can find a workaround, it we have encountered a couple of environments
> where we need to NAT netbios datagram packets.  Since they have embedded
> IP address information in the netbios header, this protocol breaks with
> NAT.  We see the packets enter the server with the NAT address but the
> replies are addressed to the original address as per the netbios header.

Like this one:

http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a2978aea393b5e00b55b219786a5b8a47f838a7f

which was merged 12 days ago?

Phil

Re: NetBIOS datagram nat helper proposal

[Krzysztof Oledzki]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 868 bytes --]



On Mon, 19 Sep 2005, Phil Oester wrote:

> On Mon, Sep 19, 2005 at 05:10:15PM -0400, John A. Sullivan III wrote:
>> It appears that we may need a netbios datagram NAT helper.  Unless we
>> can find a workaround, it we have encountered a couple of environments
>> where we need to NAT netbios datagram packets.  Since they have embedded
>> IP address information in the netbios header, this protocol breaks with
>> NAT.  We see the packets enter the server with the NAT address but the
>> replies are addressed to the original address as per the netbios header.
>
> Like this one:
>
> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a2978aea393b5e00b55b219786a5b8a47f838a7f
>
> which was merged 12 days ago?

No. This is a connection tracking helper, not NAT helper.

Best regards,
 				Krzysztof Olędzki

Re: NetBIOS datagram nat helper proposal

[John A. Sullivan III]

On Mon, 2005-09-19 at 14:27 -0700, Phil Oester wrote:
> On Mon, Sep 19, 2005 at 05:10:15PM -0400, John A. Sullivan III wrote:
> > It appears that we may need a netbios datagram NAT helper.  Unless we
> > can find a workaround, it we have encountered a couple of environments
> > where we need to NAT netbios datagram packets.  Since they have embedded
> > IP address information in the netbios header, this protocol breaks with
> > NAT.  We see the packets enter the server with the NAT address but the
> > replies are addressed to the original address as per the netbios header.
> 
> Like this one:
> 
> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a2978aea393b5e00b55b219786a5b8a47f838a7f
> 
> which was merged 12 days ago?
> 
> Phil
> 
Thanks but it looks like that's name service - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

Financially sustainable open source development
http://www.opensourcedevel.com

Re: NetBIOS datagram nat helper proposal

[Patrick McHardy]

John A. Sullivan III wrote:
> It appears that we may need a netbios datagram NAT helper.  Unless we
> can find a workaround, it we have encountered a couple of environments
> where we need to NAT netbios datagram packets.  Since they have embedded
> IP address information in the netbios header, this protocol breaks with
> NAT.  We see the packets enter the server with the NAT address but the
> replies are addressed to the original address as per the netbios header.
> 
> We have not seen such a helper within netfilter.  There appears to be a
> simple helper for this at
> http://suif.stanford.edu/~csapuntz/ip_nat_netbios.c

The helper does stateless NAT without issuing any expectations
or even adjusting the conntrack entry. I'm not sure this is
enough, but I'm not familiar with the netbios stuff. What is
running on port 138? Do you have any pointers to a description
of the protocol?

> We are seeing if we have the resources to finish and polish this patch
> and submit it.  It seems that we then simply post it to this list to
> submit it.  Is that the correct procedure?

Yes, if the patch is OK conceptually. If you send me some pointers,
I'll have a look.

Re: NetBIOS datagram nat helper proposal

[John A. Sullivan III]

On Tue, 2005-09-20 at 02:32 +0200, Patrick McHardy wrote:
> John A. Sullivan III wrote:
> > It appears that we may need a netbios datagram NAT helper.  Unless we
> > can find a workaround, it we have encountered a couple of environments
> > where we need to NAT netbios datagram packets.  Since they have embedded
> > IP address information in the netbios header, this protocol breaks with
> > NAT.  We see the packets enter the server with the NAT address but the
> > replies are addressed to the original address as per the netbios header.
> > 
> > We have not seen such a helper within netfilter.  There appears to be a
> > simple helper for this at
> > http://suif.stanford.edu/~csapuntz/ip_nat_netbios.c
> 
> The helper does stateless NAT without issuing any expectations
> or even adjusting the conntrack entry. I'm not sure this is
> enough, but I'm not familiar with the netbios stuff. What is
> running on port 138? Do you have any pointers to a description
> of the protocol?
Yes, this is what I mean by finishing and polishing.
> 
> > We are seeing if we have the resources to finish and polish this patch
> > and submit it.  It seems that we then simply post it to this list to
> > submit it.  Is that the correct procedure?
> 
> Yes, if the patch is OK conceptually. If you send me some pointers,
> I'll have a look.
> 
I believe it is defined by RFC1002.  You can find it here:
http://ubiqx.org/cifs/rfc-draft/rfc1002.html#s4.4
I would think it is pretty straightforward but it is so easy to
dreadfully underestimate these things.  Thanks - John

-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

Financially sustainable open source development
http://www.opensourcedevel.com

IPT_RETURN is not worked in the kernel 2.6.10

[Vincent]

Hello folks,

I am currently writing a iptables target. And I want to use the
IPT_RETURN as the return value from target.
But I found that IPT_RETURN will result as NF_ACCEPT does. What I mean
is, while I use IPT_RETURN in my target module.
It will not go back to the upper directory. Does anyone ever experience
the same problem?

Enviroment: 
linux kernel 2.6.10
Iptables 1.2.9

Vincent

The following code is part of the ipt_do_table in the ip_tables.c
But I don’t know how to modify it to fix the bug? :(

            if (!t->u.kernel.target->target) {
                int v;

                v = ((struct ipt_standard_target *)t)->verdict;
                if (v < 0) {
                    /* Pop from stack? */
                    if (v != IPT_RETURN) {
                        verdict = (unsigned)(-v) - 1;
                        break;
                    }
                    e = back;
                    back = get_entry(table_base,
                             back->comefrom);
                    continue;
                }

Re: NetBIOS datagram nat helper proposal

[Patrick McHardy]

John A. Sullivan III wrote:
> On Tue, 2005-09-20 at 02:32 +0200, Patrick McHardy wrote:
> 
>>>We are seeing if we have the resources to finish and polish this patch
>>>and submit it.  It seems that we then simply post it to this list to
>>>submit it.  Is that the correct procedure?
>>
>>Yes, if the patch is OK conceptually. If you send me some pointers,
>>I'll have a look.
>>
> 
> I believe it is defined by RFC1002.  You can find it here:
> http://ubiqx.org/cifs/rfc-draft/rfc1002.html#s4.4
> I would think it is pretty straightforward but it is so easy to
> dreadfully underestimate these things.  Thanks - John

Thanks. Looking at the RFC, the patch is incomplete in at least two
ways. First, the protocol includes broadcasts, these need to be tracked
in a similar way to ip_conntrack_netbios_ns. Second, the helper only
NATs the source IP but the packets also include the source port, it
needs to be translated as well. I'm not sure how the reply packets
look, I found some broadcast queries in my local network, but don't
have access to any of the machines to sniff the unicast replies.

# tcpdump -i eth0 -ntv port 138
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96
bytes
IP (tos 0x0, ttl 128, id 64557, offset 0, flags [none], proto: UDP (17),
length: 229) 172.16.0.77.138 > 172.16.255.255.138: NBT UDP PACKET(138)
IP (tos 0x0, ttl 128, id 52744, offset 0, flags [none], proto: UDP (17),
length: 239) 172.16.1.56.138 > 172.16.255.255.138: NBT UDP PACKET(138)
IP (tos 0x0, ttl 128, id 37133, offset 0, flags [none], proto: UDP (17),
length: 229) 172.16.1.11.138 > 172.16.255.255.138: NBT UDP PACKET(138)
IP (tos 0x0, ttl 128, id 53239, offset 0, flags [none], proto: UDP (17),
length: 229) 172.16.1.56.138 > 172.16.255.255.138: NBT UDP PACKET(138)

If you can provide me with some packet dumps of a machine sending and
receiving these packets I'll give it a try, it shouldn't be much work.