From: Frans Luteijn <f.a.g.luteijn@knoware.nl>
To: netfilter@lists.netfilter.org
Subject: Re: nat problem
Date: Thu, 15 Jul 2004 01:30:33 +0200 [thread overview]
Message-ID: <40F5C218.E57FEC60@knoware.nl> (raw)
In-Reply-To: 200407140953.50466.Antony@Soft-Solutions.co.uk
Antony Stone schreef:
> On Wednesday 14 July 2004 2:02 am, Frans Luteijn wrote:
>
> > Antony Stone schreef:
> > >
> > > No, I don't think so. Broadcast packets are not supposed to cross
> > > routers (they will enter the router as a machine on the local subnet, but
> > > they will not be routed anywhere else, because they already come from the
> > > subnet they are addressed to)
> >
> > I have been doing some testing:I have a machine, which broadcasts to
> > 192.168.1.255 prot.: udp sport/dport: 138/138
> > I typed in:
> >
> > iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 138
> > -j LOG iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp
> > --sport 138 -j DNAT 192.168.2.255
> >
> > Then I saw in my log:
> > Jul 14 02:34:16 firewall kernel: IN=eth0 OUT=
> > MAC=ff:ff:ff:ff:ff:ff:00:50:04:0e:d9:00:08:00 SRC=192.168.1.3
> > DST=192.168.1.255 LEN=240 TOS=0x00 PREC=0x00 TTL=32 ID=60162 PROTO=UDP
> > SPT=138 DPT=138 LEN=220
> >
> > and I saw trafic on my other network.
> > When I type:
> >
> > cat /proc/net/ip_conntrack
> >
> > I see:
> > udp 17 17 src=192.168.1.3 dst=192.168.1.255 sport=138 dport=138
> > [UNREPLIED] src=192.168.2.255 dst=192.168.1.3 sport=138 dport=138 use=1
> >
> > This means to me, that those packets are forwarded. So why can't I forward
> > the other packets (192.168.1.255, prot.: udp, sport/dport: 1025/2071)?
>
> What happens if you try the same test as above, but with the port numbers you
> are interested in? Do the connection tracking table and the log file
> suggest that packets are being forwarded? If you can get it to "work" on
> port 138, I don't see why it shouldn't "work" on port 2071.
>
Nothing happens, no logging or anything else:iptables -t nat -A PREROUTING -i eth0
-d 192.168.1.255 -p udp --sport 1025 -j LOG
iptables -t nat -A PREROUTING -i eth0 -d 192.168.1.255 -p udp --sport 1025 -j DNAT
--to 192.168.2.255
When I type:
cat /proc/net/ip_conntrack
I see:
udp 17 25 src=192.168.1.1 dst=192.168.1.255 sport=1025 dport=2071 [UNREPLIED]
src=192.168.1.255 dst=192.168.1.1 sport=2071 dport=1025 use=1
After typing:
iptables -t nat -I PREROUTING 2 -i eth0 -d 192.168.1.255 -p udp --sport 2071 -j
LOG
iptables -t nat -I PREROUTING 3 -i eth0 -d 192.168.1.255 -p udp --dport 1025 -j
LOG
iptables -t nat -I PREROUTING 4 -i eth0 -d 192.168.1.255 -p udp --dport 2071 -j
LOG
nothing happens either.
But after typing:
iptables -t filter -A INPUT -i eth0 -d 192.168.1.255 -p udp --sport 1025 -j LOG
I see the packets coming in:
Jul 15 00:59:11 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1 DST=192.168.1.255
LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=31435 PROTO=UDP SPT=1025 DPT=2071 LEN=96
Jul 15 00:59:21 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1 DST=192.168.1.255
LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=31436 PROTO=UDP SPT=1025 DPT=2071 LEN=96
Jul 15 00:59:31 firewall kernel: IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:08:00:4e:a6:f5:74:08:00 SRC=192.168.1.1 DST=192.168.1.255
LEN=116 TOS=0x00 PREC=0x00 TTL=64 ID=31437 PROTO=UDP SPT=1025 DPT=2071 LEN=96
So what is wrong here? I think, it is a bug, because it doesn't work as expected.
> BTW: I put "work" in quotes there because although you see the packets going
> through the firewall, does the actual NetBios service allow you to browse
> Windows shares on machines on the other subnet? My expectation is not,
> because there have been many questions on this list previously about share
> browsing across routers (Windows does network browsing using broadcast
> packets), the solution to which has always been a PDC on the source network,
> with knowledge of the second subnet.
>
That was not my intention. This was only an example to show you, it is possible to
forward broadcastpackets to another network.
> Regards,
>
> Antony.
>
> --
> I think, therefore I am.
> I'm pink, therefore I'm Spam.
> I drink, therefore I think I am.
>
> Please reply to the list;
> please don't CC me.
--
Frans Luteijn
PGP PblKey fprnt=C4 87 CE AF BC B6 98 C1 EF 42 A1 9A E2 C0 42 5B
GPG PblKey fprnt=ED20 0F25 C233 DC59 3FFA 170E D0BF 15F5 0BA6 1355
next prev parent reply other threads:[~2004-07-14 23:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-13 20:40 nat problem Frans Luteijn
2004-07-13 21:06 ` Antony Stone
2004-07-13 22:21 ` Frans Luteijn
2004-07-13 22:53 ` Antony Stone
2004-07-13 23:11 ` Nick Taylor
2004-07-14 1:02 ` Frans Luteijn
2004-07-14 8:53 ` Antony Stone
2004-07-14 23:30 ` Frans Luteijn [this message]
2004-07-15 8:21 ` Antony Stone
2004-07-19 1:26 ` Frans Luteijn
-- strict thread matches above, loose matches on Subject: below --
2004-07-05 16:33 Frans Luteijn
2004-07-07 13:07 ` Antony Stone
2003-10-06 12:30 NAT problem Jose Pascual
2003-10-06 13:19 ` Venkatesh. K
2003-10-06 13:33 ` Cedric Blancher
2003-10-06 20:38 ` Joel Newkirk
2002-11-22 22:52 nat problem Yogini Parkhi
2002-11-15 20:45 Rahul Jadhav
2002-10-21 13:04 NAT problem saravanan sakthi
2002-10-21 15:15 ` Antony Stone
2002-10-20 23:20 NAT Problem Morgan
2002-06-24 11:11 Nat PROBLEM lcef
2002-06-24 13:34 ` Antony Stone
2002-06-15 22:14 Completely NAT an ISP: A practical possibility? Brian Capouch
2002-06-15 22:33 ` Antony Stone
2002-06-15 23:17 ` Nick Drage
2002-06-17 4:25 ` Sathi
2002-06-17 10:58 ` nat problem umar
2002-06-17 18:11 ` Antony Stone
2002-05-09 4:41 NAT problem Tyler Kemp
2002-06-13 16:03 ` Antony Stone
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=40F5C218.E57FEC60@knoware.nl \
--to=f.a.g.luteijn@knoware.nl \
--cc=netfilter@lists.netfilter.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