Linux Netfilter discussions
 help / color / mirror / Atom feed
* DNAT problem /  question
@ 2004-06-18 15:45 Arnauts, Bert
  2004-06-18 16:06 ` Patrick Leslie Polzer
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Arnauts, Bert @ 2004-06-18 15:45 UTC (permalink / raw)
  To: netfilter

Hello all,

I am still stuck with my DNAT. I updated the information that was
requested.
Could you please check my config, if I execute this I can not ping my
internal lan ip of this host 172.25.239.208 any more. I think this is
really wierd. I included all kinds of information, hopefully enough for
you guys to take a look at.

Cheers,

Bert

$IPTABLES -t nat -A PREROUTING -d 172.25.239.220/27 -j DNAT
--to-destination 11.0.0.16 $IPTABLES -t nat -A OUTPUT -d
172.25.239.220/27 -j DNAT --to-destination 11.0.0.16 

$IPTABLES -A INPUT   -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT  -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -N RULE_0
$IPTABLES -A OUTPUT -d 11.0.0.16  -m state --state NEW  -j RULE_0
$IPTABLES -A FORWARD -d 11.0.0.16  -m state --state NEW  -j RULE_0
$IPTABLES -A RULE_0  -j LOG  --log-level info --log-prefix "RULE 0 --
ACCEPT " 
$IPTABLES -A RULE_0  -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Monday, June 14, 2004 4:51 PM
To: netfilter@lists.netfilter.org
Subject: Re: DNAT question

On Monday 14 June 2004 3:35 pm, Arnauts, Bert wrote:

> Hello all,
>
> I want to DNAT some machines in another subnet.
> The target machines have ip's like 11.0.0.x/24
>
> My available lan ip's are 172.239.239.x/27 (255.255.255.224)
>
> These are my rules. Wich are apparently not working.

How are you trying to test the rules?   What tells you they're not
working?

Where are you testing from?

I am testing from a machine that can ping the nat box'es IP and I can
access all sorts of other systems services on that subnet.
(my nat box : 172.25.239.208)

> I created virtual interfaces on eth1, one for each DNAT'ed ip.

Can you ping one of those addresses fom a machine directly connected to
eth1, qand then check the arp cache (arp -an under Linux) to be sure
that the IP / MAC address link is working correctly?

Yes I can ping these addresses. (without my iptables) With my rules it
doesn't work anymore.

> What am I missing ? Forget about normal tables stuff, I only want this

> machine to do DNAT.

What does "iptables -L -t nat -nvx" show you for the packet / byte
counters?    see below
Does it look like netfilter thinks it's doing any NAT?    yes ... I
guess. see below

I also ripped something frowm fwbuilder, adepted it a little bit .. this
is my new script.


#!/bin/bash
LSMOD="/sbin/lsmod"
MODPROBE="/sbin/modprobe"
IPTABLES="/sbin/iptables"
LOGGER="/usr/bin/logger"
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_intvl

$IPTABLES -P OUTPUT ACCEPT 
$IPTABLES -P INPUT   ACCEPT 
$IPTABLES -P FORWARD ACCEPT 

cat /proc/net/ip_tables_names | while read table; do
  $IPTABLES -t $table -L -n | while read c chain rest; do
      if test "X$c" = "XChain" ; then
        $IPTABLES -t $table -F $chain
      fi
  done
  $IPTABLES -t $table -X
done

MODULE_DIR="/lib/modules/`uname -r`/kernel/net/ipv4/netfilter/" 
MODULES=`(cd $MODULE_DIR; ls *_conntrack_*  *_nat_* | sed 's/\.o.*$//;
s/\.ko$//')` for module in $(echo $MODULES); do
  if $LSMOD | grep ${module} >/dev/null; then continue; fi
  $MODPROBE ${module} ||  exit 1
done

echo "Activating firewall script generated Thu Jun 10 15:03:22 2004 CEST
by root"

$IPTABLES -t nat -A PREROUTING -d 172.25.239.220/27 -j DNAT
--to-destination 11.0.0.16 $IPTABLES -t nat -A OUTPUT -d
172.25.239.220/27 -j DNAT --to-destination
11.0.0.16 

$IPTABLES -A INPUT   -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT  -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -N RULE_0
$IPTABLES -A OUTPUT -d 11.0.0.16  -m state --state NEW  -j RULE_0
$IPTABLES -A FORWARD -d 11.0.0.16  -m state --state NEW  -j RULE_0
$IPTABLES -A RULE_0  -j LOG  --log-level info --log-prefix "RULE 0 --
ACCEPT " 
$IPTABLES -A RULE_0  -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward



thx Antony !
(nice quote)

--
If the human brain were so simple that we could understand it, we'd be
so simple that we couldn't.

                                                     Please reply to the
list;
                                                           please don't
CC me.

------------------------------------------------------------------------
---------------------------------------------


[root@linuxrouter root]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:E0:18:02:7E:9B  
          inet addr:11.0.0.3  Bcast:11.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4822 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:286513 (279.7 Kb)  TX bytes:6516 (6.3 Kb)
          Interrupt:5 Base address:0xd800 Memory:fb000000-fb000038 

eth1      Link encap:Ethernet  HWaddr 00:D0:B7:E0:1F:2C  
          inet addr:172.25.239.208  Bcast:172.25.239.223
Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7342 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2091 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:629297 (614.5 Kb)  TX bytes:342349 (334.3 Kb)
          Interrupt:11 Base address:0xd400 Memory:fa000000-fa000038 

eth1:1    Link encap:Ethernet  HWaddr 00:D0:B7:E0:1F:2C  
          inet addr:172.25.239.220  Bcast:172.25.255.255
Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0xd400 Memory:fa000000-fa000038 

[root@linuxrouter root]# ping 11.0.0.16
PING 11.0.0.16 (11.0.0.16) 56(84) bytes of data.
64 bytes from 11.0.0.16: icmp_seq=1 ttl=128 time=0.261 ms


[root@linuxrouter root]# ping 172.25.239.220 PING 172.25.239.220
(172.25.239.220) 56(84) bytes of data.
64 bytes from 172.25.239.220: icmp_seq=1 ttl=128 time=0.264 ms


[root@linuxrouter root]# iptables -L -t nat -nvx Chain PREROUTING
(policy ACCEPT 16 packets, 3256 bytes)
    pkts      bytes target     prot opt in     out     source
destination         
      70    11224 DNAT       all  --  *      *       0.0.0.0/0
172.25.239.192/27  to:11.0.0.16 

Chain POSTROUTING (policy ACCEPT 19 packets, 6614 bytes)
    pkts      bytes target     prot opt in     out     source
destination         

Chain OUTPUT (policy ACCEPT 5 packets, 420 bytes)
    pkts      bytes target     prot opt in     out     source
destination         
       5      404 DNAT       all  --  *      *       0.0.0.0/0
172.25.239.192/27  to:11.0.0.16 

[root@linuxrouter root]# arp -an
? (172.25.239.201) at 00:30:05:11:F9:EA [ether] on eth1 ?
(172.25.239.193) at 00:60:47:40:F7:A5 [ether] on eth1 ? (11.0.0.16) at
00:E0:18:02:38:60 [ether] on eth0

[BRUBARNA7M] D:\some_crapy\windows_box>ping 172.25.239.220

Pinging 172.25.239.220 with 32 bytes of data:

Request timed out.

Ping statistics for 172.25.239.220:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss), Control-C ^C

also ... even a ping to my normal host is not working anymore. (wich was
working without the tables)

[BRUBARNA7M] D:\some_crapy\windows_box>ping 172.25.239.208

Pinging 172.25.239.208 with 32 bytes of data:

Request timed out.

Ping statistics for 172.25.239.208:
    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

you should think it is my firewall ... but I accept everything ... :(

[root@linuxrouter root]# iptables -L -nvx Chain INPUT (policy ACCEPT 0
packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source
destination         
     557    72706 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0          state NEW,RELATED,ESTABLISHED 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source
destination         
     147    13879 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0          state NEW,RELATED,ESTABLISHED 
       0        0 RULE_0     all  --  *      *       0.0.0.0/0
11.0.0.16          state NEW 

Chain OUTPUT (policy ACCEPT 1 packets, 152 bytes)
    pkts      bytes target     prot opt in     out     source
destination         
     269    31752 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0          state NEW,RELATED,ESTABLISHED 
       0        0 RULE_0     all  --  *      *       0.0.0.0/0
11.0.0.16          state NEW 

Chain RULE_0 (2 references)
    pkts      bytes target     prot opt in     out     source
destination         
       0        0 LOG        all  --  *      *       0.0.0.0/0
0.0.0.0/0          LOG flags 0 level 6 prefix `RULE 0 -- ACCEPT ' 
       0        0 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0          








^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: DNAT problem /  question
  2004-06-18 15:45 DNAT problem / question Arnauts, Bert
@ 2004-06-18 16:06 ` Patrick Leslie Polzer
  2004-06-18 16:14   ` Antony Stone
  2004-06-18 16:06 ` Antony Stone
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 9+ messages in thread
From: Patrick Leslie Polzer @ 2004-06-18 16:06 UTC (permalink / raw)
  To: netfilter

On Fri, 18 Jun 2004 17:45:20 +0200
"Arnauts, Bert" <Bert.Arnauts@fujitsu-siemens.com> wrote:

> Could you please check my config, if I execute this I can not ping my
> internal lan ip of this host 172.25.239.208 any more. I think this is
> really wierd.
Why? These lines:

> $IPTABLES -t nat -A PREROUTING -d 172.25.239.220/27 -j DNAT
> --to-destination 11.0.0.16
> $IPTABLES -t nat -A OUTPUT -d
> 172.25.239.220/27 -j DNAT --to-destination 11.0.0.16 

are doing everything to keep ALL packets away from you ;)
All outgoing packets (statement 2) are redirected to 11.0.0.16
and all incoming are as well (statement 1)!
How do you expect ping to work with that? :-O


Kind regards,

Leslie


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: DNAT problem /  question
  2004-06-18 15:45 DNAT problem / question Arnauts, Bert
  2004-06-18 16:06 ` Patrick Leslie Polzer
@ 2004-06-18 16:06 ` Antony Stone
  2004-06-18 16:45   ` Patrick Leslie Polzer
  2004-06-18 16:09 ` Rob Sterenborg
  2004-06-18 16:29 ` DNAT problem / question (nfcan: addressed to exclusive sender for this address) Jim Laurino
  3 siblings, 1 reply; 9+ messages in thread
From: Antony Stone @ 2004-06-18 16:06 UTC (permalink / raw)
  To: netfilter

On Friday 18 June 2004 4:45 pm, Arnauts, Bert wrote:

> Hello all,
>
> I am still stuck with my DNAT. I updated the information that was
> requested.
> Could you please check my config, if I execute this I can not ping my
> internal lan ip of this host 172.25.239.208 any more. I think this is
> really wierd. I included all kinds of information, hopefully enough for
> you guys to take a look at.

It appears you have overlooked both of John Sullivan's postings on this (both 
more recent than mine).

> $IPTABLES -t nat -A PREROUTING -d 172.25.239.220/27 -j DNAT
> --to-destination 11.0.0.16
> $IPTABLES -t nat -A OUTPUT -d 172.25.239.220/27 -j DNAT --to-destination
> 11.0.0.16

You have specified an inappropriate combination of address and netmask with 
172.25.239.220/27 - the address 220 is not the base address of a /27 range, 
and it is possible (I am not certain) that this combination is confusing 
netfilter.

The /27 range within which address .220 falls is 172.25.239.192 (the braodcast 
address is 172.25.239.223), so firstly, try specifying that as your address 
range and see if it helps.

Secondly, do you really mean that you want all packets addressed to anywhere 
within the /27 range to be redirected instead to 11.0.0.16?   That is a valid 
rule, but seems like a slightly strange requirement.

Regards,

Antony.

-- 
"Linux is going to be part of the future. It's going to be like Unix was."

 - Peter Moore, Asia-Pacific general manager, Microsoft

                                                     Please reply to the list;
                                                           please don't CC me.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: DNAT problem /  question
  2004-06-18 15:45 DNAT problem / question Arnauts, Bert
  2004-06-18 16:06 ` Patrick Leslie Polzer
  2004-06-18 16:06 ` Antony Stone
@ 2004-06-18 16:09 ` Rob Sterenborg
  2004-06-18 16:29 ` DNAT problem / question (nfcan: addressed to exclusive sender for this address) Jim Laurino
  3 siblings, 0 replies; 9+ messages in thread
From: Rob Sterenborg @ 2004-06-18 16:09 UTC (permalink / raw)
  To: netfilter

> $IPTABLES -A INPUT   -m state --state NEW,
> ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A OUTPUT  -m state --state NEW,
> ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A FORWARD -m state --state NEW,
> ESTABLISHED,RELATED -j ACCEPT

I do not think you want this. Since you don't specify protocol and/or
port, you are accepting any packet that is NEW, RELATED or ESTABLISHED.
That means any packet.
This is the same as having a policy of ACCEPT for all filter chains with
no rules to block anything. If you want to filter anything, leave the
NEW out of the rules, or just set policy to ACCEPT and skip these rules.
(Btw, do you have policy set to DROP for INPUT, OUTPUT and FORWARD so
that these rules make sense ?)


Gr,
Rob



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: DNAT problem /  question
  2004-06-18 16:06 ` Patrick Leslie Polzer
@ 2004-06-18 16:14   ` Antony Stone
  0 siblings, 0 replies; 9+ messages in thread
From: Antony Stone @ 2004-06-18 16:14 UTC (permalink / raw)
  To: netfilter

On Friday 18 June 2004 5:06 pm, Patrick Leslie Polzer wrote:

> On Fri, 18 Jun 2004 17:45:20 +0200
>
> "Arnauts, Bert" <Bert.Arnauts@fujitsu-siemens.com> wrote:
> > Could you please check my config, if I execute this I can not ping my
> > internal lan ip of this host 172.25.239.208 any more. I think this is
> > really wierd.
>
> Why? These lines:
> > $IPTABLES -t nat -A PREROUTING -d 172.25.239.220/27 -j DNAT
> > --to-destination 11.0.0.16
> > $IPTABLES -t nat -A OUTPUT -d
> > 172.25.239.220/27 -j DNAT --to-destination 11.0.0.16
>
> are doing everything to keep ALL packets away from you ;)
> All outgoing packets (statement 2) are redirected to 11.0.0.16
> and all incoming are as well (statement 1)!
> How do you expect ping to work with that? :-O

Good point, but surely a ping packet sent to 172.25.239.220 (let's overlook 
the netmask for the time being...) would get redirected to 11.0.0.16, and 
provided that machine responds to the ping (and the reply goes back through 
netfilter's NAT table) the origianting client might see the reply?

However, I am certainly highly confused by what Bert is trying achieve here - 
perhaps the answers to a few questions would help:

1. How many interfaces does the netfilter machine have?   What are their IP 
addresses?

2. Where is machine 11.0.0.16?   How are packets routed to that frm the 
netfiler machine?

3. What address are you sending the ping packets from (and to)?   How is that 
client routed to the netfilter box?

4. What, in simple terms, are you trying to achieve with the two rules which 
Patrick has queried above?

Regards,

Antony.

-- 
"It would appear we have reached the limits of what it is possible to achieve 
with computer technology, although one should be careful with such 
statements; they tend to sound pretty silly in five years."

 - John von Neumann (1949)

                                                     Please reply to the list;
                                                           please don't CC me.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: DNAT problem /  question (nfcan: addressed to exclusive sender for this address)
  2004-06-18 15:45 DNAT problem / question Arnauts, Bert
                   ` (2 preceding siblings ...)
  2004-06-18 16:09 ` Rob Sterenborg
@ 2004-06-18 16:29 ` Jim Laurino
  3 siblings, 0 replies; 9+ messages in thread
From: Jim Laurino @ 2004-06-18 16:29 UTC (permalink / raw)
  To: netfilter

On 2004.06.18 11:45, Arnauts Bert  - Bert.Arnauts@fujitsu- 
siemens.com wrote:
> Hello all,
> 
> I am still stuck with my DNAT. I updated the information
> that was requested. Could you please check my config, if  
> I execute this I can not ping my internal lan ip of this  
> host 172.25.239.208 any more. I think this is really  
> wierd. I included all kinds of information, hopefully  
> enough for you guys to take a look at.
> 
> Cheers,
> 
> Bert
> 
> $IPTABLES -t nat -A PREROUTING -d 172.25.239.220/27
> -j DNAT --to-destination 11.0.0.16

> $IPTABLES -t nat -A  OUTPUT -d 172.25.239.220/27
> -j DNAT --to-destination 11.0.0.16
>

The dest ip address/mask pattern looks odd.
I am not sure how this address matching works,
but the way I imagine it to work is that a mask
is generated and applied to an address to test
and then this is compared to the address given.
That is, I think the address given is not
masked. If this is so, then there might be a
failure to match destination addresses.

I think a /27 mask is meant to select a
contiguous group of 27 addresses, that is
5 bits. I think masking the 5 low bits of
a number like 220 or 208 gives 192 (xC0)
and a rule like .192/27 would match addresses
in the range 192-223 (xC0-xDF),
where .220/27 might match nothing.

Of course, the code might be written another
way, where this would not be a problem.

You could try logging what is happening
or looking at the counts to see if the
rules are matching. I think this will do it:

iptables -L -t nat -nvx

Jim


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: DNAT problem /  question
  2004-06-18 16:06 ` Antony Stone
@ 2004-06-18 16:45   ` Patrick Leslie Polzer
  0 siblings, 0 replies; 9+ messages in thread
From: Patrick Leslie Polzer @ 2004-06-18 16:45 UTC (permalink / raw)
  To: netfilter

On Fri, 18 Jun 2004 17:06:28 +0100
Antony Stone <Antony@Soft-Solutions.co.uk> wrote:

> You have specified an inappropriate combination of address and netmask with 
> 172.25.239.220/27 - the address 220 is not the base address of a /27 range, 
> and it is possible (I am not certain) that this combination is confusing 
> netfilter.
I don't think this is a problem. They'll be masked out anyway.

Leslie


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: DNAT problem /  question (nfcan: addressed to exclusive sender for this address)
  2004-06-20 22:24 DNAT problem / question Arnauts, Bert
@ 2004-06-21  4:25 ` Jim Laurino
  0 siblings, 0 replies; 9+ messages in thread
From: Jim Laurino @ 2004-06-21  4:25 UTC (permalink / raw)
  To: netfilter

On 2004.06.20 18:24, Arnauts Bert  - Bert.Arnauts@fujitsu- 
siemens.com wrote:
> Hello all,
> 
> thx already for the hints, but I am still in a strugle.
> I changed my destination ip to 207,
> because 220 could cause problems.
> Forgive me that I don't understand why.
> Anyway, these rules give even a more confusing result.
> I am still not able to access my 11.0.0.16
> box through the 172.25.239.207 DNAT'ed alias.
> (not pingable, not nothing)
> I also can not connect anymore to my netfilter box
> anymore after executing this script,
> BUT my active ssh connection stays open ! ?
> I am still on my machine remotly,
> but I can not ping it anymore ?? :(
> 
> Any more ideas ?
> ------------------------------------------------------------
> 
> echo "Activating firewall script generated
> Thu Jun 10 15:03:22 2004 CEST by root"
> 
> $IPTABLES -t nat -A PREROUTING -d 172.25.239.207/27
> -j DNAT --to-destination 11.0.0.16
> 
> $IPTABLES -A INPUT   -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A OUTPUT  -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A FORWARD -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> 
> $IPTABLES -N RULE_0
> $IPTABLES -A OUTPUT  -d 11.0.0.16  -m state --state NEW
> - j RULE_0
> $IPTABLES -A FORWARD -d 11.0.0.16  -m state --state NEW
> -j RULE_0
> $IPTABLES -A RULE_0  -j LOG --log-level info
> --log-prefix "RULE 0 -- ACCEPT "
> $IPTABLES -A RULE_0  -j ACCEPT
> echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> execution of this script gives me this :
> (why is there 192 ? in stead of 207 ?)

> [root@linuxrouter root]# iptables -t nat -L
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination
> 
> DNAT       all  --  anywhere              
> 172.25.239.192/27 to:11.0.0.16

Because the programmers were being kind to you :)
The 192 is the base address for the range 192-223,
and is exactly what you need for a .207/27.
(That is, the low 5 bits need to be zeros.)

It will be less confusing, later,
if you change your rule to:

$IPTABLES -t nat -A PREROUTING -d 172.25.239.192/27
-j DNAT --to-destination 11.0.0.16
(but see below, I think you may not mean to do this)

If you change the List command from:

iptables -t nat -L
to
iptables -t nat -L -nvx

The -v (--verbose) and -x (--exact) flags
will give you (among other things) the
exact number of packets that have matched
each rule.

To look at the main (filter) table do:
iptables -L -nvx

I think that you will see that all packets
here match these first rules:

-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Therefore the "Rule 0" test, which comes later,
will never get a chance to look at them,
and will have a zero count.

Change those first rules to:

-m state --state ESTABLISHED,RELATED -j ACCEPT

Then the "Rule 0" tests will match NEW packets.

The PREROUTING rule says that any packet
addressed to 172.25.239.207 will be changed
to a destination address of 11.0.0.16.
(In fact any address 172.25.239.192 through
172.25.239.223 will become 11.0.0.16)

Therefore, when a packet originally addressed
to 172.25.239.207 (in on eth1) arrives (later)
at the filter table it will have a
destination address 11.0.0.16 and will
traverse the FORWARD chain and leave by eth0.
Only the host with that address (.16) will receive packets.
This explains why the netfilter host is inacessible.

Also, you said:

> I have everything in the 172.25.239.0/27 network.

This must be a typo, because this does not
include 172.25.239.207, which is one of
the 31 addresses in the 172.25.239.192/27 network.

From other things you have said,
I think you may be trying to translate a series
of addresses exactly one to one:

172.25.239.207 <--> 11.0.0.16

I think you can best do this by using an
explicit PREROUTING rule for each pair.
That is, get rid of the /27,
and add a rule for each address pair.
Then you can keep, say .208, not translated,
and allow this to be used as the address
of the netfilter host. Like this:

$IPTABLES -t nat -A PREROUTING -d 172.25.239.207
-j DNAT --to-destination 11.0.0.16

Jim


^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: DNAT problem /  question (nfcan: addressed to exclusive sender for this address)
@ 2004-06-21  9:14 Arnauts, Bert
  0 siblings, 0 replies; 9+ messages in thread
From: Arnauts, Bert @ 2004-06-21  9:14 UTC (permalink / raw)
  To: netfilter

 Thx Jim,

$IPTABLES -t nat -A PREROUTING -d 172.25.239.220 -j DNAT
--to-destination 11.0.0.16

I tried this rule. Firt I made a virtual interface on the external
network, then I executed my rules. (see below)
I still have access to my nat box now, (the 208), but I can not ping the
220 anymore. Apparently he forwards something ?
(3 packets ?) Is my broadcast address right ? I made this the same as
the nat box has ? What does this anyway ?

What about the subnetmask of my internal network  ? 255.255.255.224 ??
Will the nat rule know this ?

Cheers, and thx,

Bert



------------------------------------------------------------------------
-----------------------
eth1      Link encap:Ethernet  HWaddr 00:D0:B7:E0:1F:2C  
          inet addr:172.25.239.208  Bcast:172.25.239.223
Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:33527 errors:0 dropped:0 overruns:0 frame:0
          TX packets:791 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:1944722 (1.8 Mb)  TX bytes:113877 (111.2 Kb)
          Interrupt:11 Base address:0xd400 Memory:fa000000-fa000038 

eth1:1    Link encap:Ethernet  HWaddr 00:D0:B7:E0:1F:2C  
          inet addr:172.25.239.220  Bcast:172.25.239.223
Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0xd400 Memory:fa000000-fa000038 
------------------------------------------------------------------------
---------------------------
[root@linuxrouter root]# iptables -L -t nat -nvx
Chain PREROUTING (policy ACCEPT 241 packets, 40673 bytes)
    pkts      bytes target     prot opt in     out     source
destination         
       7      678 DNAT       all  --  *      *       0.0.0.0/0
172.25.239.220     to:11.0.0.16 

Chain POSTROUTING (policy ACCEPT 17 packets, 1403 bytes)
    pkts      bytes target     prot opt in     out     source
destination         

Chain OUTPUT (policy ACCEPT 6 packets, 461 bytes)
    pkts      bytes target     prot opt in     out     source
destination 
------------------------------------------------------------------------
---------------------------        
[root@linuxrouter root]# iptables -L -nvx
Chain INPUT (policy ACCEPT 51 packets, 5884 bytes)
    pkts      bytes target     prot opt in     out     source
destination         
     149    12360 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0          state RELATED,ESTABLISHED 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source
destination         
       0        0 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0          state RELATED,ESTABLISHED 
      24     1837 RULE_0     all  --  *      *       0.0.0.0/0
11.0.0.16          state NEW 

Chain OUTPUT (policy ACCEPT 1 packets, 152 bytes)
    pkts      bytes target     prot opt in     out     source
destination         
     116    26168 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0          state RELATED,ESTABLISHED 
       0        0 RULE_0     all  --  *      *       0.0.0.0/0
11.0.0.16          state NEW 

Chain RULE_0 (2 references)
    pkts      bytes target     prot opt in     out     source
destination         
      24     1837 LOG        all  --  *      *       0.0.0.0/0
0.0.0.0/0          LOG flags 0 level 6 prefix `RULE 0 -- ACCEPT ' 
      24     1837 ACCEPT     all  --  *      *       0.0.0.0/0
0.0.0.0/0          
------------------------------------------------------------------------
----------------------- 
[root@linuxrouter root]# arp -an
? (172.25.239.193) at 00:60:47:40:F7:A5 [ether] on eth1
? (11.0.0.16) at 00:E0:18:02:38:60 [ether] on eth0
[root@linuxrouter root]# 


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Jim Laurino
Sent: Monday, June 21, 2004 6:25 AM
To: netfilter@lists.netfilter.org
Subject: Re: DNAT problem / question (nfcan: addressed to exclusive
sender for this address)

On 2004.06.20 18:24, Arnauts Bert  - Bert.Arnauts@fujitsu- siemens.com
wrote:
> Hello all,
> 
> thx already for the hints, but I am still in a strugle.
> I changed my destination ip to 207,
> because 220 could cause problems.
> Forgive me that I don't understand why.
> Anyway, these rules give even a more confusing result.
> I am still not able to access my 11.0.0.16 box through the 
> 172.25.239.207 DNAT'ed alias.
> (not pingable, not nothing)
> I also can not connect anymore to my netfilter box anymore after 
> executing this script, BUT my active ssh connection stays open ! ?
> I am still on my machine remotly,
> but I can not ping it anymore ?? :(
> 
> Any more ideas ?
> ------------------------------------------------------------
> 
> echo "Activating firewall script generated Thu Jun 10 15:03:22 2004 
> CEST by root"
> 
> $IPTABLES -t nat -A PREROUTING -d 172.25.239.207/27 -j DNAT 
> --to-destination 11.0.0.16
> 
> $IPTABLES -A INPUT   -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A OUTPUT  -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> $IPTABLES -A FORWARD -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> 
> $IPTABLES -N RULE_0
> $IPTABLES -A OUTPUT  -d 11.0.0.16  -m state --state NEW
> - j RULE_0
> $IPTABLES -A FORWARD -d 11.0.0.16  -m state --state NEW -j RULE_0 
> $IPTABLES -A RULE_0  -j LOG --log-level info --log-prefix "RULE 0 -- 
> ACCEPT "
> $IPTABLES -A RULE_0  -j ACCEPT
> echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> execution of this script gives me this :
> (why is there 192 ? in stead of 207 ?)

> [root@linuxrouter root]# iptables -t nat -L Chain PREROUTING (policy 
> ACCEPT)
> target     prot opt source               destination
> 
> DNAT       all  --  anywhere              
> 172.25.239.192/27 to:11.0.0.16

Because the programmers were being kind to you :) The 192 is the base
address for the range 192-223, and is exactly what you need for a
.207/27.
(That is, the low 5 bits need to be zeros.)

It will be less confusing, later,
if you change your rule to:

$IPTABLES -t nat -A PREROUTING -d 172.25.239.192/27 -j DNAT
--to-destination 11.0.0.16 (but see below, I think you may not mean to
do this)

If you change the List command from:

iptables -t nat -L
to
iptables -t nat -L -nvx

The -v (--verbose) and -x (--exact) flags will give you (among other
things) the exact number of packets that have matched each rule.

To look at the main (filter) table do:
iptables -L -nvx

I think that you will see that all packets here match these first rules:

-m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Therefore the "Rule 0" test, which comes later, will never get a chance
to look at them, and will have a zero count.

Change those first rules to:

-m state --state ESTABLISHED,RELATED -j ACCEPT

Then the "Rule 0" tests will match NEW packets.

The PREROUTING rule says that any packet addressed to 172.25.239.207
will be changed to a destination address of 11.0.0.16.
(In fact any address 172.25.239.192 through
172.25.239.223 will become 11.0.0.16)

Therefore, when a packet originally addressed to 172.25.239.207 (in on
eth1) arrives (later) at the filter table it will have a destination
address 11.0.0.16 and will traverse the FORWARD chain and leave by eth0.
Only the host with that address (.16) will receive packets.
This explains why the netfilter host is inacessible.

Also, you said:

> I have everything in the 172.25.239.0/27 network.

This must be a typo, because this does not include 172.25.239.207, which
is one of the 31 addresses in the 172.25.239.192/27 network.

From other things you have said,
I think you may be trying to translate a series of addresses exactly one
to one:

172.25.239.207 <--> 11.0.0.16

I think you can best do this by using an explicit PREROUTING rule for
each pair.
That is, get rid of the /27,
and add a rule for each address pair.
Then you can keep, say .208, not translated, and allow this to be used
as the address of the netfilter host. Like this:

$IPTABLES -t nat -A PREROUTING -d 172.25.239.207 -j DNAT
--to-destination 11.0.0.16

Jim





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2004-06-21  9:14 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-18 15:45 DNAT problem / question Arnauts, Bert
2004-06-18 16:06 ` Patrick Leslie Polzer
2004-06-18 16:14   ` Antony Stone
2004-06-18 16:06 ` Antony Stone
2004-06-18 16:45   ` Patrick Leslie Polzer
2004-06-18 16:09 ` Rob Sterenborg
2004-06-18 16:29 ` DNAT problem / question (nfcan: addressed to exclusive sender for this address) Jim Laurino
  -- strict thread matches above, loose matches on Subject: below --
2004-06-20 22:24 DNAT problem / question Arnauts, Bert
2004-06-21  4:25 ` DNAT problem / question (nfcan: addressed to exclusive sender for this address) Jim Laurino
2004-06-21  9:14 Arnauts, Bert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox