I have a decent problem that started spreading out in an unconvinient way - for now it simply takes to much time to get solved; like most of the time it is an simple problem here we have it - portforwarding: I have a small LAN at home with a cable connection. so I get my ip from the ISP thru' dhcp.. and here's a part of my script: #!/bin/bash EXTIF=eth0 INTIF=eth1 EXTIP=www.xxx.yyy.zzz INTIP=192.168.0.1 WWWSRV=192.168.0.2 #here I'll make some echo 1 > /proc/sys/net/ipv4/* #to some features like ip_dynaddr, ip_forward, tcp_syncookie #then I set the default policies #accept everything except the FORWARD chain #and flush them iptables -P INPUT -j ACCEPT iptables -F INPUT iptables -P OUTPUT -j ACCEPT iptables -F OUTPUT iptables -P FORWARD -j DROP iptables -F FORWARD iptables -t nat -f #flush the nat table # and here's my little disaster # i try to forward port 1234 to my internal www-server iptables -t nat -A PREROUTING -p tcp -i $EXTIF -d $EXTIP --dport 1234 -j DNAT --to-destination $WWWSRV:80 iptables -A FORWARD -p tcp -i $EXTIF -o $INTIF -d $WWWSRV --dport 80 -j ACCEPT iptables -t nat -A POSTROUTING -p tcp -o $EXTIF -s $WWWSRV --sport 80 -j SNAT --to-source $EXTIP:1234 # for what i understand from iptables till now is # packet comes in thru ethernet, arrives in kernel # so packet looks like this # ip-layer: source-ip: WWWREQUEST destination-ip: $EXTIP # tcp-layer: source-port: a port higher than 1024 destination-port: 1234 # and hits the PREROUTING chain # with the DNAT rule above it changes following # ip-layer: source-ip: WWWREQUEST destination-ip: $WWSRV # tcp-layer: source-port: a port higher than 1024 destination-port: 80 # then hits FORWARD chain (usually it would hit the INPUT chain, # but we changed that with DNAT; it has to go out on $INTIF to reach # its destination..) # with the FORWARD rule it can bypass.. # when applying DNAT all other packets in that stream are bypassed as well # with this two rules it is sure that a request from a www-client from # the inet is reaching the inner $WWWSRV, and the $WWWSRV can respond but # there is still something wrong with the reply packet: # ip-layer: source-ip: $WWWSRV destination-ip: WWWREQUEST # tcp-layer: source-port: 80 destination-port: 1024: # when the packet arrives at the WWWREQUEST-host-browser it doesn't know # what to do with the packet (there was no request to this host $WWWSRV) # so here comes rule 3; it changes the source ip and port to this # ip-layer: source-ip: $EXTIP destination-ip: WWWREQUEST # tcp-layer: source-port: 1234 destination-port: 1024: # now the packet seems like the awaited reply from the request # he has given to $EXTIP:1234 # and another few rules to complete the firewall script # allow all connections from inside out and only related # and established ones in iptables -A FORWARD -p tcp -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -p tcp -o $EXTIF -i $INTIF -j ACCEPT # enable masquerading iptables -t NAT -A POSTROUTING -o $EXTIF -j MASQUERADE I hope anyone out there can help me.. I tried serveral permutations with the three portforwarding rules: I changed some params or even let them away One Variation was to ACCEPT the full FORWARD chain I hope there aren't any spelling mistakes, cause I wrote this script just for email purposeŽ; on my router is the original.. I've also read dozens of mailing-list entry like this and everyone seemed pausible but till now it didn't work - I've tried two days now and I'm kind of frustrated oh yeah, modules loaded by the kernel: ip_tables iptable_nat ip_conntrack ip_conntrack_ftp ip_conntrack_irc ip_nat_ftp iptable_filter ipt_state ipt_LOG ipt_MASQUERADE it must be a kind of silly, tiny failure one I haven't looked for yet.. thanks for any little hint! methodaut __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
