A little iptables help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Quoting Rodrigo Barbosa <rodrigob@xxxxxxxxxxxxxxx>:

> On Thu, Sep 29, 2005 at 09:21:40AM -0500, Aleksandar Milivojevic wrote:
>> >>>I did this successfully providing external SSH access to a collection
>> >>>of hosts on a private network. However for this to work, the hosts on
>> >>>the private net also need to be doing SNAT back out through the
>> >>>firewall.
>> >>
>> >>Unless you are doing something funky, SNAT is not needed.  All he needs
>> >>is DNAT.
>> >>Netfilter should take care of returning packets automagically (unless, as
>> >>I
>> >>said, you are doing something funky and confusing Netfilter with it).
>> >
>> >If you have a RELATED,ESTABLISHED matching rule only.
>>
>> Somebody will probably correct me if I'm wrong, but I think restriction is
>> as
>> long as you have connection tracking module loaded.  And you will have it as
>> soon as you call any of NAT targets (iptable_nat module depends on
>> ip_conntrack
>> module).  So you don't have to have any state related rules at all.
>
> If your default rule for the related chain is DROP, then you do need
> the state rules.

But, the returning packet will be in ESTABLISHED state, not the RELATED 
state. RELATED is simmilar to NEW, it matches only the first packet 
(that firewall
saw) of a new connection that is somehow related to an already established
connection (and all subsequent packets in that related connection will be in
ESTABLISHED state if you accepted the RELATED packet).

I've just tested it on a spare box I have.  Single DNAT rule in nat table, no
rules at all in filter table, checked with tcpdump, everything worked as I
described.

The rule was:

# iptables -A PREROUTING -p tcp --dport 2200 -i eth0 \
           -j DNAT --to-destination host2:22

Showing the first incomming (syn) and first outgoing (syn ack) packet here
(edited to remove non-relevant clutter):

# tcpdump 'tcp[tcpflags] & tcp-syn != 0'
IP host1.49506 > fw.2200: S
IP host1.49506 > host2.ssh: S
IP host2.ssh > host1.49506: S ack
IP fw.2200 > host1.49506: S ack

You can see how firewall rewrote destination address and destination 
port on the
incomming packet (first two lines), and then it rewrote source address and
srouce port number on returning packet (last two lines).

Then I added some logging rules into filter table to detect in what state will
be the returning packet, and it was in ESTABLISHED state as expected.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux