Hi folks, Has anyone out there done port forwarding or DNAT for UDP packets that are normally sent to the broadcast address (255.255.255.255)? I have to support a nasty database application called FileMaker Pro (those of you who know it are probably groaning about now), which uses broadcasts to locate the database server. Theoretically, i can get around this requirement by using LDAP lookups (and this works on the Windows FileMaker client), but due to a bug in the startup code, it doesn''t work on Mac OS 10. Thus, what i need to do is take packets sent to UDP 5003 on 255.255.255.255 on one subnet, and redirect them at my shorewall box to the real database server on another subnet. I thought a rule like this: DNAT client server:1.2.3.4 udp 5003 or this: DNAT client server:1.2.3.4 udp 5003 - 255.255.255.255 would work, but it doesn''t. It creates rules that look right, and the packet counters on the DNAT rule increment as expected, but i never see the packets coming out the other side, and nor do the counters on the ACCEPT rule created by shorewall ever increment. Any ideas? -- Paul Gear, Manager IT Operations, Redlands College 38 Anson Road, Wellington Point 4160, Australia (Please send attachments in portable formats such as PDF, HTML, or OpenOffice.) -- The information contained in this message is copyright by Redlands College. Any use for direct sales or marketing purposes is expressly forbidden. This message does not represent the views of Redlands College.
----- Original Message ----- From: "Paul Gear" <pgear@redlands.qld.edu.au> To: <shorewall-users@lists.shorewall.net> Sent: Tuesday, June 21, 2005 23:17 Subject: [Shorewall-users] Port forwarding/DNAT of broadcast packets? Hi folks, Has anyone out there done port forwarding or DNAT for UDP packets that are normally sent to the broadcast address (255.255.255.255)? I have to support a nasty database application called FileMaker Pro (those of you who know it are probably groaning about now), which uses broadcasts to locate the database server. Theoretically, i can get around this requirement by using LDAP lookups (and this works on the Windows FileMaker client), but due to a bug in the startup code, it doesn''t work on Mac OS 10. Thus, what i need to do is take packets sent to UDP 5003 on 255.255.255.255 on one subnet, and redirect them at my shorewall box to the real database server on another subnet. I thought a rule like this: DNAT client server:1.2.3.4 udp 5003 or this: DNAT client server:1.2.3.4 udp 5003 - 255.255.255.255 would work, but it doesn''t. It creates rules that look right, and the packet counters on the DNAT rule increment as expected, but i never see the packets coming out the other side, and nor do the counters on the ACCEPT rule created by shorewall ever increment. Any ideas?> _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htmProxy-arp maybe, assign a second ip address, from lanA, to the server on lanB, and use proxyarp for the routing. Jerry
Robert K Coffman Jr - Info From Data Corporation
2005-Jun-23 12:26 UTC
RE: Port forwarding/DNAT of broadcast packets?
>Has anyone out there done port forwarding or DNAT for UDP packets that arenormally sent to the broadcast address (255.255.255.255)? Can you move the clients to the other subnet? Even if you get these to traverse the router, do you know if the server will respond correctly to a machine on another subnet? - Bob
Robert K Coffman Jr - Info From Data Corporation wrote:>> Has anyone out there done port forwarding or DNAT for UDP packets >> that are normally sent to the broadcast address >> (255.255.255.255)? > > Can you move the clients to the other subnet?I''m trying to move the clients *away* from the same subnet as the server, not *into* it. :-)> Even if you get these to traverse the router, do you know if the > server will respond correctly to a machine on another subnet?Because it uses a static route via my shorewall cluster which will do the right thing. Paul
Jerry Vonau wrote:> ... > Has anyone out there done port forwarding or DNAT for UDP packets that > are normally sent to the broadcast address (255.255.255.255)? > ... > Thus, what i need to do is take packets sent to UDP 5003 on > 255.255.255.255 on one subnet, and redirect them at my shorewall box > to the real database server on another subnet. > ... > > Proxy-arp maybe, assign a second ip address, from lanA, to the server on > lanB, and use proxyarp for the routing.I''ve been doing a bit of reading about this at netfilter.org, and according to http://lists.netfilter.org/pipermail/netfilter/2003-June/044613.html broadcasts cannot be routed. So it looks like this is a netfilter limitation, and i''ll have to use proxyarp or an application proxy to get the traffic across. -- Paul <http://paulgear.webhop.net> -- Did you know? If you receive a virus warning from a friend and not through a virus software vendor, it''s likely to be a hoax. See <http://gear.dyndns.org:81/features/virus_hoaxes> for more info.
Matt \"Cyber Dog\" LaPlante
2005-Jun-25 05:58 UTC
RE: Re: Port forwarding/DNAT of broadcast packets?
> -----Original Message----- > From: shorewall-users-bounces@lists.shorewall.net [mailto:shorewall-users- > bounces@lists.shorewall.net] On Behalf Of Paul Gear > Sent: Saturday, June 25, 2005 12:05 AM > To: shorewall-users@lists.shorewall.net > Subject: [Shorewall-users] Re: Port forwarding/DNAT of broadcast packets? > > Jerry Vonau wrote: > > ... > > Has anyone out there done port forwarding or DNAT for UDP packets that > > are normally sent to the broadcast address (255.255.255.255)? > > ... > > Thus, what i need to do is take packets sent to UDP 5003 on > > 255.255.255.255 on one subnet, and redirect them at my shorewall box > > to the real database server on another subnet. > > ... > > > > Proxy-arp maybe, assign a second ip address, from lanA, to the server on > > lanB, and use proxyarp for the routing. > > I''ve been doing a bit of reading about this at netfilter.org, and > according to > http://lists.netfilter.org/pipermail/netfilter/2003-June/044613.html > broadcasts cannot be routed. So it looks like this is a netfilter > limitation, and i''ll have to use proxyarp or an application proxy to get > the traffic across. > > -- > Paul > <http://paulgear.webhop.net> > -- > Did you know? If you receive a virus warning from a friend and not > through a virus software vendor, it''s likely to be a hoax. See > <http://gear.dyndns.org:81/features/virus_hoaxes> for more info.Strictly speaking, it''s not specifically a netfilter limitation; it''s a fact of routing. Switched layer 2 networks are referred to as broadcast domains, and extend only until they reach a layer 3 device. Any layer three device that performs routing on a packet terminates the "broadcast domain"...only unicast or multicast packets can be forwarded via routing. It''s logical if you think about it; unicast and multicast are directed communications, and can have a target on any end destination. The purpose of a broadcast is to communicate to any machine on the local subnet. There''s no way of routing this, as there''s no determinate destination...if you were to layer 3 route broadcasts, they could conceivably be broadcast to every machine on the internet! So in short, broadcast traffic is limited to the local layer 2 subnet (unless you have a means of creating a discontinuous subnet). - Matt
Matt "Cyber Dog" LaPlante wrote:> ... >>I''ve been doing a bit of reading about this at netfilter.org, and >>according to >>http://lists.netfilter.org/pipermail/netfilter/2003-June/044613.html >>broadcasts cannot be routed. So it looks like this is a netfilter >>limitation, and i''ll have to use proxyarp or an application proxy to get >>the traffic across.Sorry - s/routed/NATed/ Does it make more sense now? :-)> ... > Strictly speaking, it''s not specifically a netfilter limitation; it''s a fact > of routing. Switched layer 2 networks are referred to as broadcast domains, > and extend only until they reach a layer 3 device. Any layer three device > that performs routing on a packet terminates the "broadcast domain"...only > unicast or multicast packets can be forwarded via routing. It''s logical if > you think about it; unicast and multicast are directed communications, and > can have a target on any end destination. The purpose of a broadcast is to > communicate to any machine on the local subnet. There''s no way of routing > this, as there''s no determinate destination...if you were to layer 3 route > broadcasts, they could conceivably be broadcast to every machine on the > internet! So in short, broadcast traffic is limited to the local layer 2 > subnet (unless you have a means of creating a discontinuous subnet).Once you throw DNAT into the equation, it''s not such an unreasonable thing to expect, IMHO. NATing broadcast traffic, either to a single host or for static mapping purposes between subnets, seems to be a common request on the netfilter lists. The common thread seems to be programs like FileMaker or multiplayer games that use UDP broadcast to provide autoconfiguration. Cisco and 3Com provide UDP helpers with their router operating systems, so it seems to me that it''s reasonable to expect a Linux router to do it. Anyway - not much we can do about it. Sounds like a perl script or netcat might be needed for my particular application. -- Paul <http://paulgear.webhop.net> -- Tired of paying for Microsoft Office? Running an illegal copy and want to make it legal? Try OpenOffice.org! It''s free and does most of the things Microsoft Office does. <http://www.openoffice.org>