UDP Forwarding

UDP Forwarding

[John A. Sullivan III]

This is a fairly complex problem so please bear with me; this really
does have to do with iptables.  I have a client who is considering using
iptables based appliances from CyberGuard (the old SnapGear units to
build an IPSec WAN.  The problem is that they run a Citrix thin client
environment across the existing Frame Relay WAN and they use UDP
broadcast helpers (translate the UDP broadcast into a UDP unicast packet
to forward across the router) so that the thin clients can find the
Citrix servers.  I would like to find a way to do this with the
CyberGuard devices.  I do not have the option of installing a UDP helper
so I have to do this with iptables or iproute.

GRE tunnels over IPSec are out of the question as the existing 18 branch
offices cannot be readdressed to make one big bridged network.

I first thought about using iptables to DNAT the broadcast addresses to
unicast addresses and sending the unicast packets across the VPN, e.g., 
iptables -t nat -A PREROUTING -d 192.168.223.255 -p udp --dport 11111 -j
DNAT --to-destination 172.23.230.2

Then I realized that the connection tracking would change the source of
the reply packets to 192.168.223.255 and that wouldn't work.  I then
thought I would use the stateless nat in iproute2 but then realized that
it only does SNAT and not DNAT.

I turned my attention again to iptables and thought I could turn off
connection tracking in the raw table for packets destined for the
broadcast address on the required port and then DNAT them in the nat
table.  That did not work and I'm not sure why.

The packets hit and match the DNAT rule in the PREROUTING table but then
they completely disappear.  I was using ping to test, e.g., ping -b
192.168.223.255.  I tried logging the very first packets in both the
FORWARD and INPUT chains of the filter table but the packets are nowhere
to be seen.  /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts is 0.

So, I have two questions.  Most importantly, does anyone have any
suggestions of how I can set up this UDP broadcast helper?  Second, any
idea what is happening to the disappearing broadcast ping packets?
Thanks, all - 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

Stateless NAT in 2.6 (was Re: UDP Forwarding)

[John A. Sullivan III]

On Fri, 2005-02-18 at 22:37 -0500, John A. Sullivan III wrote:
> This is a fairly complex problem so please bear with me; this really
> does have to do with iptables.  I have a client who is considering using
> iptables based appliances from CyberGuard (the old SnapGear units to
> build an IPSec WAN.  The problem is that they run a Citrix thin client
> environment across the existing Frame Relay WAN and they use UDP
> broadcast helpers (translate the UDP broadcast into a UDP unicast packet
> to forward across the router) so that the thin clients can find the
> Citrix servers.  I would like to find a way to do this with the
> CyberGuard devices.  I do not have the option of installing a UDP helper
> so I have to do this with iptables or iproute.
> 
> GRE tunnels over IPSec are out of the question as the existing 18 branch
> offices cannot be readdressed to make one big bridged network.
> 
> I first thought about using iptables to DNAT the broadcast addresses to
> unicast addresses and sending the unicast packets across the VPN, e.g., 
> iptables -t nat -A PREROUTING -d 192.168.223.255 -p udp --dport 11111 -j
> DNAT --to-destination 172.23.230.2
> 
> Then I realized that the connection tracking would change the source of
> the reply packets to 192.168.223.255 and that wouldn't work.  I then
> thought I would use the stateless nat in iproute2 but then realized that
> it only does SNAT and not DNAT.
> 
> I turned my attention again to iptables and thought I could turn off
> connection tracking in the raw table for packets destined for the
> broadcast address on the required port and then DNAT them in the nat
> table.  That did not work and I'm not sure why.
> 
> The packets hit and match the DNAT rule in the PREROUTING table but then
> they completely disappear.  I was using ping to test, e.g., ping -b
> 192.168.223.255.  I tried logging the very first packets in both the
> FORWARD and INPUT chains of the filter table but the packets are nowhere
> to be seen.  /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts is 0.
> 
> So, I have two questions.  Most importantly, does anyone have any
> suggestions of how I can set up this UDP broadcast helper?  Second, any
> idea what is happening to the disappearing broadcast ping packets?
> Thanks, all - John

I decided to take another look at iproute2 since I was sure I had used
it to DNAT in the past.  Sure enough, I had skimmed the latest
documentation too quickly and assumed it had been limited to SNAT.  One
can indeed do an

ip route add nat x.x.x.x via y.y.y.y

for DNAT.  However, when I tried to do this on a 2.6 kernel, it failed.
Googling seems to indicate that stateless NAT using iproute2 is broken
in 2.6.

This brings me back to netfilter.  Is there any way to do stateless NAT
with netfilter? 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

Re: Stateless NAT in 2.6 (was Re: UDP Forwarding)

[Ming-Ching Tiew]

> >  I would like to find a way to do this with the
> > CyberGuard devices.  I do not have the option of installing a UDP helper
> > so I have to do this with iptables or iproute.
>>

Trying to understand your problem :-

Why is the option of installing a UDP helper is out ? Is it because
the can't compile C programs and install any program on these 
cyberguard devices? And you can only write scripts ?

Cheers.

Re: Stateless NAT in 2.6 (was Re: UDP Forwarding)

[John A. Sullivan III]

On Tue, 2005-02-22 at 16:18 +0800, Ming-Ching Tiew wrote:
> > >  I would like to find a way to do this with the
> > > CyberGuard devices.  I do not have the option of installing a UDP helper
> > > so I have to do this with iptables or iproute.
> >>
> 
> Trying to understand your problem :-
> 
> Why is the option of installing a UDP helper is out ? Is it because
> the can't compile C programs and install any program on these 
> cyberguard devices? And you can only write scripts ?
> 
<snip>
Yes, exactly.  They are very small footprint appliances running ucLinux
and I would not want to void any warranties by cross compiling and
adding binaries to the image.  Thanks for such a quick response - 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: Stateless NAT in 2.6 (was Re: UDP Forwarding)

[Ming-Ching Tiew]

> Yes, exactly.  They are very small footprint appliances running ucLinux
> and I would not want to void any warranties by cross compiling and
> adding binaries to the image.  Thanks for such a quick response - John

That totally defeat the spirit of open source. I would throw it away and
put in other small footprint appliances which I have full source. There
are many such devices around.

Anyway, it's probably not helping your situation at all. 

Sorry won't help much.

Cheers.

Re: Stateless NAT in 2.6 (was Re: UDP Forwarding)

[Philip Craig]

Hi John,

John A. Sullivan III wrote:
> On Tue, 2005-02-22 at 16:18 +0800, Ming-Ching Tiew wrote:
> 
>>>> I would like to find a way to do this with the
>>>>CyberGuard devices.  I do not have the option of installing a UDP helper
>>>>so I have to do this with iptables or iproute.
>>>>
>>
>>Trying to understand your problem :-
>>
>>Why is the option of installing a UDP helper is out ? Is it because
>>the can't compile C programs and install any program on these 
>>cyberguard devices? And you can only write scripts ?
>>
> 
> <snip>
> Yes, exactly.  They are very small footprint appliances running ucLinux
> and I would not want to void any warranties by cross compiling and
> adding binaries to the image.  Thanks for such a quick response - John

Customizing the firmware won't void the warranty per se.  The problem
is that our support processes cannot handle units with custom firmware
in them, so if you have a problem with the unit, we require that you
reinstall the standard firmware before contacting support.

So adding a UDP helper isn't too hard if you don't mind cross compiling
it and recreating the firmware image.  If you want to go this route,
then you can find the source code on www.snapgear.org.

Alternatively, we currently only ship Linux 2.4 firmware, so you could
use the stateless NAT in the ip route command.  Unfortunately we've only
enabled this for the high-end units, thinking very few people would
have a use for it when we already have iptables NAT.  So again, you
may have build your firmware image.

It's probably possible to write an iptables mangle target to perform
stateless NAT, but it doesn't exist yet that I am aware of.

-- 
Philip Craig - SnapGear, A CyberGuard Company - http://www.SnapGear.com

Re: Stateless NAT in 2.6 (was Re: UDP Forwarding)

[Ming-Ching Tiew]

From: "Philip Craig" <philipc@snapgear.com>
> 
> Customizing the firmware won't void the warranty per se.  The problem
> is that our support processes cannot handle units with custom firmware
> in them, so if you have a problem with the unit, we require that you
> reinstall the standard firmware before contacting support.
> 

I think this is fair with respect to supporting the system.

> So adding a UDP helper isn't too hard if you don't mind cross compiling
> it and recreating the firmware image.  If you want to go this route,
> then you can find the source code on www.snapgear.org.
> 

Whichever is the case, it seems custom firmware must be developed, so I 
would rather go with the UDP helper option. Those UDP helpers are just 
very small programs, I don't see any problem going down this path.

Cheers.