forwarded ports become "filtered" instead of "open"

[/dev/rob0]

On Wednesday 2005-August-10 12:27, Anthony DiSante wrote:
> Jörg Harmuth wrote:
> >>Can anyone offer some pointers here?  I imagine more of my
> >> narc.conf and/or iptables' output would be helpful, but rather
> >> than me attaching the whole thing right now, just ask if you want
> >> me to post any of that.

I would point out that this "narc.conf" appears to be controlling a 
rather complex script. I cannot answer anything about it. I can look 
over your rules ... needlessly complex IMO ... and point out problems. 
But for issues with this script, consult its documentation (and source 
code) and ask elsewhere.

> # iptables-save
> # Generated by iptables-save v1.3.1 on Wed Aug 10 13:21:27 2005
> *mangle
>
> -A PREROUTING -d 0.0.0.0/255.0.0.0 -i eth0 -m state --state NEW -j
> DROP

Filtering in the nat or mangle tables is not advised. It might not even 
work as expected. I have no idea what the script writer is doing here, 
nor why s/he is doing it here in particular.

Here are the rules in INPUT:

> -A INPUT -j SPOOF_CHK
> -A INPUT -p tcp -j SANITY_CHK
> -A INPUT -j STATE_CHK
> -A INPUT -s 127.0.0.0/255.255.255.0 -d 127.0.0.0/255.255.255.0 -i lo
> -m state --state NEW -j ACCEPT
> -A INPUT -p tcp -j TCP_CHK
> -A INPUT -p udp -j UDP_CHK
> -A INPUT -p icmp -j ICMP_CHK

We'll consider SSH. That is first examined by SPOOF_CHK, then by 
SANITY_CHK, then by STATE_CHK, and finally by TCP_CHK.

> -A STATE_CHK -m state --state RELATED,ESTABLISHED -j ACCEPT

You're probably right that when you manually try in both directions, 
you're going to fool connection tracking into thinking that it's 
related.

> -A STATE_CHK -p tcp -m state --state NEW -m tcp ! --tcp-flags
> SYN,RST,ACK SYN -j DROP

I'm not sure what this does. It might be dropping your SSH depending on 
the TCP flags which are set.

> -A TCP_CHK -s 10.0.0.12 -d 10.0.0.12 -p tcp -m tcp --dport 3029:3038
> -j ACCEPT

These rules are bypassed. The last rule in SPOOF_CHK :
> -A SPOOF_CHK -s 10.0.0.12 -i eth0 -j CUST_LOG
has already dropped anything which would match. I don't understand what 
they were supposed to do anyway, both source and destination the local 
eth0 IP address?

> -A TCP_CHK -i eth0 -p tcp -m multiport --dports 22,873,80,9618 -m
> state --state NEW -m tcp --tcp-flags SYN,RST,ACK SYN -j ACCEPT

This looks like it should be accepting your SSH, but for some reason 
it's not. What is the IP you are using, the NAT'ed external IP, or the 
direct 10.0.0.12 and .13? If you're using the NAT'ed IP, the problem is 
on the router which is doing the NAT. (And I agree, that was a lousy 
way to set this up.)

> -A TCP_CHK -i eth0 -p tcp -m multiport --dports 22,80,873,9618 -m
> state --state NEW -m tcp --tcp-flags SYN,RST,ACK SYN -j ACCEPT

Same rule twice? That's strange.

Anyway, your solution is quite simple. Put an ACCEPT rule ahead of 
anything which would drop or reject the packets you want.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header