On Friday 28 March 2003 01:50 pm, Jean Khosalim wrote: > We are trying to NAT some UDP traffic and can't get iptables > configured correctly. We are using version 1.27 on familiar linux > version 0.5.3 Interesting. I assume this is embedded, not handheld, but won't ask for details... :^) > Here is our configuration: > # iptables -t nat -L the filter table is important here as well, at least the FORWARD chain. It's also more helpful to list the actual commands creating the rules, rather than the rule listing from iptables. > Chain PREROUTING (policy ACCEPT) > target prot opt source destination > > Chain POSTROUTING (policy ACCEPT) > target prot opt source destination > SNAT all -- anywhere anywhere > to:192.168.0.31 I assume this rule also matches to a specific interface. (that info is not included when you list rules - one reason including actual script snippets can be helpful) > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > When a TFTP packet comes in on 192.168.1.1 it gets SNAT'd > and sent out 192.168.0.31, but the reply is always dropped > and an unreachable messages is sent out. Have you applied the TFTP patch from Patch-O-Matic? As with 'normal' ftp, a special conntrack helper and NAT helper is available. But unlike FTP, they're not incuded in the normal distribution, but are available as a patch to be applied to the source code. You then rebuild the kernel/modules. http://netfilter.org/documentation/pomlist/pom-combined.html#tftp is the info on it, and a link to a listing of the patch itself. (using Patch-O-Matic itself is the correct way to apply it, however) This particular 'patch' is actually just two sourcecode files, for the ip_conntrack_tftp, and ip_nat_tftp modules. I've no idea the procedure for rebuilding a kernel/modules for Familiar, I would presume you'd need to do it on an x86 machine with cross-compiler. (I'm awaiting a Zaurus 5600 right now, expected delivery later this week - not running Familiar, but Embeddix/QTopia, and I have Debian ready to install when it arrives) > We have tried it with: > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > > this configuration does the same thing. No real surprise there - all MASQUERADE does is SNAT, but double-checks the IP of the outbound interface each time. > Does NAT work for UDP in general, and TFTP in particular? > The man page has lots of UDP specific options > do those only apply to filtering, and not NAT? For UDP in general it works wonderfully. For TFTP I've never tried it, but with the conntrack and nat helpers it should be fine. The UDP-specific options I'm aware of are simply matching options, usable in any table/chain to match the rule more precisely to specific traffic. IE, with conntrack and nat helpers installed, and a rule for ESTABLISHED,RELATED in the filter FORWARD chain (with a DROP policy), you could narrow down the FORWARD rule to ACCEPT only "-p udp --dport 69", and the same for the SNAT rule, and the rest would be handled for you. Then (barring other ACCEPT rules in FORWARD) only TFTP would be permitted through. Port 69 being its initial connection, and any others (data) being handled by the helpers as RELATED traffic. Once you load the conntrack and nat helpers, the data ports are RELATED in FORWARD, and RELATED is automatically matched with its 'parent' connection in the SNAT rule. If you're trying to do this stateless, without conntrack, I don't think you'll be successful SNATting a complex protocol like TFTP with your apparent setup. If only one client needs to connect with TFTP, you can try SNATting its outbound connections, then DNATting any TFTP reply traffic to that specific client. I suspect this isn't the case, though. > Thanks for any help. > Jean Khosalim and David Shifflett j
