Re: port forwarding unsin iptables
On Fri, Aug 11, 2000 at 02:03:10AM -0400, michael a. hacker wrote:
> Thanks for the reply, some things were cleared up in my mind, yet some
> have not changed. Yes i was using 2.4.0-test1-ac23, but yesterday (due
> to some other problems) i switched to 2.4.0-test5 and iptables-1.1.1
> (newest is always better right *wink*). I am using DNAT and here are
> the rules i have defined.
> -----cut------
> #-- Forwading Options
> ###
> # forward Incoming HTTP traffic on into internal host
> /sbin/iptables -t nat -A PREROUTING -p tcp -d $EXTIP1 --dport 80 -j
> DNAT --to $PORTFWIP1:80
> # forward Incoming FTP traffic on into internal hosts
> /sbin/iptables -t nat -A PREROUTING -p tcp -d $EXTIP1 --dport 21 -j
> DNAT --to $PORTFWIP1:21
> # forward Incoming ssh traffic on into internal hosts
> /sbin/iptables -t nat -A PREROUTING -p tcp -d $EXTIP1 --dport 22 -j
> DNAT --to $PORTFWIP1:22
> # forward DCC send requests into internal hosts
> /sbin/iptables -t nat -A PREROUTING -p tcp -d $EXTIP1 --dport 1029 -j
> DNAT --to $PORTFWIP1:1029
> #
> ###
> -----end-----
>
> Yet with these rules this way it seems that the source addres is being
> mangled as well as the
> destination. Everyone who connects to my ftp or www has a source address of
> my proxy/firewall.
> This is completely baffiling to me. now i have my SNAT rules defined prior
> to my DNAT, but
> I would _think_ that wouldnt make a stinkin bit of difference.
>
Yes and no. It doesn't make a difference since they're on different
chains, however, yes order can make a difference. However, the difference
probably isn't the problem so I'll describe it later and get to the point.
Remember that (for packets not destined for localhost) that the chains
traversed are PREROUTING, (then routing occurs), then FORWARD, then
POSTROUTING. The most likely source of your difficulty is that your
inbound connections are also firing your SNAT rules in the PREROUTING
chain. You need to have sufficient narrowness of scope in your SNAT
rules that they aren't fired if you don't want them to be.
One way to do that is by, e.g., using -i or -o match criteria (or both).
For example, I have some forwarding rules (in a user-defined chain linked
into the FORWARD chain) like:
iptables -A fwd-ver -p udp -i ppp+ -o eth+ --dport 123 --sport 123 -j ACCEPT
iptables -A fwd-ver -p udp -i eth+ -o ppp+ --dport 123 --sport 123 -j ACCEPT
Another way is to use port information, or marking, or .... Just make
sure that the connections you don't want to SNAT aren't picked up by
any of your SNAT rules since the PREROUTING table *is* traversed for
inbound connections.
#####
Back to an earlier comment about rule ordering. For built-in targets
ACCEPT, DROP, QUEUE, and RETURN, ordering only matters if rules have
overlapping scopes. So, if you try to do something like
iptables -A PREROUTING -p tcp -j REJECT
iptables -A PREROUTING -p tcp --dport 80 -j ACCEPT
an incoming tcp dport 80 packet will get rejected because, although
the packet would get accepted by the second rule, it never sees it
because it's also in scope of the first rule, which matches it first,
and which causes the packet to get rejected. That is, these targets
cause termination of the rule scanning which is done in order.
Another reason order may matter within a chain is that some targets,
like LOG and MARK don't cause termination of the rule scanning but have
other effects you may care about.
The last reason (I can think of) that ordering matters is that rules
that are fired very often are better placed near the top of the chain
to reduce the amount of rule testing per packet that needs to be done.
(Use iptables --list -v to see which rules are fired how often.)
#####
BTW, you probably don't need the -d flag unless you're multi-homed.
Also, you don't need the port in the --to argument unless you want to
modify the port. The default is to leave the port unmodified.
> quite possibly i have my rules wrong, if someone could straighten me out id
> appreciate it.
>
> thanks
> mike
>
[snip]
Happy hacking!
Steve
Reply to: