IPTables port forwarding issues

[...]

As a side-note: you should set the default policies before flushing the chains. Also you should delete user-defined chains.

[...]

That line is supposed to do the trick, except that you could've omitted the port in the --to since you don't redirect to a different port.

iptables -t nat -A PREROUTING -I ${WAN} -p tcp --dport 9023 -j DNAT \\ --to ${IPVPNMAIN}

Does this fail? If so: what did the logs say about incoming packets on that port?

[...]

You're thinking too complicated. DNAT merely rewrites the destination address before the packet enters the actual filtering chains (see the NAT-HOWTO [1]). Do the filtering in the filtering chains where it belongs:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i ${WAN} -p tcp --dport 9023 -m state --state NEW \\ -j ACCEPT

You don't need SNAT, because you're already doing Masquerading (which is a special form of SNAT).

[1] cu 59cobalt

Hi thanks for the response, unforunately not there yet :(. I changed the default policys to set before the chain flushes thanks.

The line

iptables -t nat -A PREROUTUING --protocol tcp --dport 9023 -j DNAT

Regarding the logs do you know where i would find these on gentoo linux 2.6.19-release-r5? I looked in /var/log/messages but there was only system general logging, no iptables from what i could see.

Is there a sepecial command in the firewall script i need to log tracking of how iptables parses its connections through the various chains?

Thanks again for all the help.

It may be just a typo, but it's supposed to read PREROUTING, not PREROUTUING. And no, the line isn't supposed to raise an error, as the syntax is correct AFAICS (aside from said typo).

I'm not familiar with Gentoo, but I'd try /var/log/syslog. And of course you need advise netfilter to create log entries first by adding a logging rule at the end of each chain. Also I need to correct my previous suggestion: of course you need to allow the forwarded packets in the FORWARD chain, not in the INPUT chain. Sorry.

iptables -A PREROUTING -i ${WAN} -p tcp --dport 9023 -j DNAT \\ --to ${IPVPNMAIN}

# ... tracking of how iptables parses its connections through the various

You mean how the packets flow through the chains? That's well-defined, see e.g. [1].

[1] cu 59cobalt

I recommend looking at:

and on that picture you see that the INPUT chain will filter no packets for targets not adressed to the filtering host. All filtering of NATTED packets is done in the FORWARD chain, never in INPUT.

I'd simply recommend loading the rules and then iptables -nvL and iptables -nvL -t nat

to see the loaded ruleset.

To see where the packets go I'd add

iptables -A FORWARD -j LOG --log-prefix "debug "

as the first rule of FORWARD chain and some grep on the logfile afterwards.

Assuming a pretty normal config of syslog or syslog-ng the logs from the packet filter should be found either in /var/log/messages or /var/log/firewall or so,

Wolfgang

What exactly does that ASCII drawing show that's not present in the image I linked?

[...]

Nonsense. You add the logging rule at the end of the chain, because you want to know about the dropped packets. Why would you care about accepted packets? For the given problem they just add unnecessary noise to the logs. Adding a prefix is a good suggestion, though, as it helps identifying the relevant log entries.

One could use 'grep "PREFIX STRING" /var/log/*' to identify the log file.

cu

59cobalt

The packets the OP looks for are not dropped. They seem to vanish. And to check that, you need to see every packet that enters the filter and then follow it's tracks.

Of course you don't need that in normal operation. But here we are talking about 'debug mode'. Sometimes one needs that for debugging, to make that clear I wrote '--log-prefix "debug "'

Nope, you want to hear everything in debug mode. ,)

Wolfgang

Packets do not "vanish". Unless there are rules doing some funky stuff (which isn't the case here, except for two REJECT rules that don't apply to the packets in question) packets are either ACCEPTed or DROPed. Period. And how would you know that the packets are not dropped? The logging rules the OP has in place (according to what he posted) won't match the NATed packets, so they simply won't show up in the logs.

[...]

I most certainly do not want to drown in log entries when trouble- shooting something. I'd start with a basic ruleset (only ACCEPT rules) and the LOG rule at the end of the chain. Either the packet is logged when it hits the LOG rule (and is subsequently dropped), or it hits an ACCEPT rule before and is delivered, in which case I'd suggest to start inspecting the traffic with a sniffer, because the problem probably lies elsewhere.

cu

59cobalt

I've trouble-shooted Linux filters more than once and sonething like

tail -f /path/to/logfile | grep debug | grep ...

has saved me from drowning most of the time. ;)

The 'log-all' rule at the beginnig of a chain (or even all chains) makes quite a good sniffer and installing such a rule takes far less time than firing up etherreal and getting monitor port on the switch ready.

Wolfgang

Well, Ansgar, because it is you, I'll give an example to make things clear:

;)

Think about the following sample:

---8

Don't get smart with me, bub. I know pretty well how to use logging and log-prefixes. I just don't agree that it would be easier than what I suggested:

----88----

Either a packet is logged (in case it didn't match any ACCEPT rule), or it is ACCEPTed and thus delivered by netfilter. In the latter case I'd run 'tcpdump -nvvi $INTERFACE "tcp port 9023"' to see where the traffic is going after it leaves the filter.

Maybe we can agree on something like this:

----88----

However, you'd still have to inspect the traffic that is not dropped.

cu

59cobalt

I know.

;)

Yes, I regard that as an acceptable compromise. ;)

best wishes Wolfgang