Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Frans Luteijn <f.a.g.luteijn@knoware.nl>
To: netfilter@lists.netfilter.org
Subject: Re: nat problem
Date: Wed, 14 Jul 2004 03:02:10 +0200	[thread overview]
Message-ID: <40F48611.67902349@knoware.nl> (raw)
In-Reply-To: 200407132353.57143.Antony@Soft-Solutions.co.uk



Antony Stone schreef:

> On Tuesday 13 July 2004 11:21 pm, Frans Luteijn wrote:
>
> > Antony Stone schreef:
> > > On Tuesday 13 July 2004 9:40 pm, Frans Luteijn wrote:
> > > > I have a little problem, which might be a bug. I have an 3COM
> > > > ISDN-router. It broadcasts every 10 seconds its connectionstatus to the
> > > > internal net. Now I want to forward those broadcasts to another
> > > > network.
> > >
> > > > What do you mean by "broadcasts"?   What protocol is being used?   What
> > > > address are the packets sent to?
> >
> > These are real broadcasts to 192.168.1.255. The protocol is UDP, the source
> > port is 1025 and the destination port is 2071.Isn't it weird, that at the
> > nat-table, when I add a rule for logging, I can't see the above meant
> > packets, but at the filter- and the mangle-table those packets are logged?
>
> 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)?

> > At a company I worked for, DHCP broadcasts were sent from one network to
> > another, so it should be possible.
>
> I would suggest that the network you refer to had a DHCP relay server on it.
>
> > > > > Now I want to forward those broadcasts to another network.
> > > >
> > > > If, by broadcasts, you mean packets addressed to the "broadcast
> > > > address" of your subnet, it can't be done - you cannot route broadcast
> > > > packets across a router (that's why people use bridges).   The only way
> > > > it could be done is to have a machine which understands the protocol,
> > > > and is connected to both networks, picking up the broadcast packets on
> > > > one subnet, and then creating new broadcast packets to send to the
> > > > other network (and, of course, dealign sensibly with the replies).
> >
> > This is exactly what I mean. I want to forward the broadcastpackets from
> > 192.168.1.255 to 192.168.2.255. I don't want to use a bridge here. I want
> > those networks separated, so I can share the connection to others without
> > concerning they can see my private network.
>
> In that case put a DHCP relay server on the subnet on which the broadcasts are
> being generated, and configure it to forward the packets to the DHCP server
> on the other subnet.
>
> You cannot use netfilter to do this, simply because broadcast packets don't
> cross routers.   That is why DHCP relays exist.
>
> Regards,
>
> Antony.
>
> --
> How I want a drink, alcoholic of course, after the heavy chapters involving
> quantum mechanics.
>
>  - 3.14159265358979
>
>                                                      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




  parent reply	other threads:[~2004-07-14  1:02 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 [this message]
2004-07-14  8:53         ` Antony Stone
2004-07-14 23:30           ` Frans Luteijn
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=40F48611.67902349@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