rule is ignored for the localhost

rule is ignored for the localhost

[Artem Y. Pervin]

Dear netfilter/iptables users!

Can you please help me with iptables setup?
I want to do a simple thing. I want some port of the external
interface to redirect TCP traffic to the private network.
So, I have the following rule sequence:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
$ cat rules.sh
INTIF="eth1"
EXTIF="eth2"

# Default policy
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# Flush tables
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat

# Setup NAT
iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

# Port forwarding
iptables -t nat -I PREROUTING -i $EXTIF -p tcp --dport 30099 -j DNAT
--to 192.168.10.119:22
iptables -t nat -I PREROUTING -i lo -p tcp --dport 30099 -j DNAT --to
192.168.10.119:22
iptables -I INPUT -i $EXTIF -p tcp --dport 30099 -j ACCEPT
iptables -I INPUT -i lo -p tcp --dport 30099 -j ACCEPT
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.

When I try to access my machine from a remote host, everything works fine:
[versus@demo ~]$ ssh -p 30099 root@somehost.somedomain
...
Are you sure you want to continue connecting (yes/no)?

But when I try to access the 30099 port from the localhost, I get
connection refused:
[root@somehost ~]# ssh -vp 30099 root@localhost
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 30099.
debug1: connect to address 127.0.0.1 port 30099: Connection refused
ssh: connect to host localhost port 30099: Connection refused

I've tried to use the external ip adress as well, but I'm getting the
same result:
[root@somehost ~]# ssh -vp 30099 root@somehost.somedomain
OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
...
ssh: connect to host somehost.somedomain port 30099: Connection refused

What is wrong with my configuration? Why iptables ignore the rule for
the localhost case?
I'm using iptables v1.3.7, kernel is 2.6.21.1.

--
Best regards,
Artem Pervin

Re: rule is ignored for the localhost

[Grant Taylor]

On 06/16/08 14:41, Artem Y. Pervin wrote:
> I want to do a simple thing. I want some port of the external 
> interface to redirect TCP traffic to the private network.

Ok...

> So, I have the following rule sequence:

At a quick glance your rules seem to be ok.

> When I try to access my machine from a remote host, everything works 
> fine:

*nod*

> I've tried to use the external ip adress as well, but I'm getting the 
> same result:

*nod*

> What is wrong with my configuration? Why iptables ignore the rule for 
> the localhost case?

I don't think it is anything with your rules per say.  Rather I think 
the problem is that you are trying to redirect something from localhost 
to something not on localhost.  The Linux kernel will prevent this for 
security reasons.

I would suggest that you use some sort of proxy program (see below) 
listening on localhost:30099 that will proxy connections to 
192.168.10.119:22 for you.

You could even have the proxy program listen on the external interface, 
or all interfaces for that matter, and do all the redirecting for you.
However keep in mind that when the proxy program connects to 
192.168.10.119 on your behalf, the connection(s) will appear to be from 
the host running the proxy app, so logging on the target host will not 
show the real source of the connection.  If you think about it, when the 
host that is doing the redirecting connects to 192.168.10.119, it would 
be the source of the traffic, so there is little difference (if any) in 
it connecting via the proxy or connecting directly to 192.168.10.119.

With this in mind, I would be tempted to DNAT with IPTables so that the 
target host will see the real source IP and proxy traffic from localhost 
on the DNAT box to 192.168.10.119.

"socat" and "rinetd" are a couple of example proxy applications.



Grant. . . .

Re: rule is ignored for the localhost

[Pascal Hambourg]

Hello,

Grant Taylor a écrit :
> On 06/16/08 14:41, Artem Y. Pervin wrote:
> 
>> I want to do a simple thing. I want some port of the external 
>> interface to redirect TCP traffic to the private network.
>> So, I have the following rule sequence:
>> 
>> # Port forwarding
>> iptables -t nat -I PREROUTING -i $EXTIF -p tcp --dport 30099 -j DNAT
>> --to 192.168.10.119:22
>> iptables -t nat -I PREROUTING -i lo -p tcp --dport 30099 -j DNAT --to
>> 192.168.10.119:22
> 
> At a quick glance your rules seem to be ok.

I beg to differ. AFAIK packets routed through the loopback interface 
don't go through the nat/PREROUTING chain, so the latter rule will never 
match any packet. My understanding is that only packets creating a new 
yet unconfirmed connection go through the nat chains, and the connection 
is confirmed right after the POSTROUTING chains, before the packet is 
looped back into the PREROUTING chains. I have the feeling that 
conntrack and NAT on loopback is somehow dodgy.

So the rule must be added to the OUTPUT chain :

iptables -t nat -I OUTPUT -o lo -p tcp --dport 30099 -j DNAT --to 
192.168.10.119:22

Re: rule is ignored for the localhost

[Grant Taylor]

On 06/17/08 09:03, Pascal Hambourg wrote:
> I beg to differ. AFAIK packets routed through the loopback interface 
> don't go through the nat/PREROUTING chain, so the latter rule will never 
> match any packet. My understanding is that only packets creating a new 
> yet unconfirmed connection go through the nat chains, and the connection 
> is confirmed right after the POSTROUTING chains, before the packet is 
> looped back into the PREROUTING chains. I have the feeling that 
> conntrack and NAT on loopback is somehow dodgy.
> 
> So the rule must be added to the OUTPUT chain :
> 
> iptables -t nat -I OUTPUT -o lo -p tcp --dport 30099 -j DNAT --to 
> 192.168.10.119:22

I'll mostly agree with you (based on my (mis)understandings) on the 
OUTPUT verses PREROUTING chain and the fact that only the first packet 
in a connection pass through the nat table.

However I believe the dodyness is at least partially do to the kernel 
treating the loopback subnet special.  If I were to bind 192.0.2.1 to 
the loopback or dummy interface and try to NAT them, I'd need to use the 
OUTPUT chain for locally generated traffic.



Grant. . . .