* Re: DNAT problem / question (nfcan: addressed to exclusive sender for this address)
2004-06-18 15:45 DNAT problem / question Arnauts, Bert
@ 2004-06-18 16:29 ` Jim Laurino
0 siblings, 0 replies; 4+ 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] 4+ messages in thread
* RE: DNAT problem / question
@ 2004-06-20 22:24 Arnauts, Bert
2004-06-21 4:25 ` DNAT problem / question (nfcan: addressed to exclusive sender for this address) Jim Laurino
0 siblings, 1 reply; 4+ messages in thread
From: Arnauts, Bert @ 2004-06-20 22:24 UTC (permalink / raw)
To: netfilter
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
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@linuxrouter root]#
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Antony Stone
Sent: Friday, June 18, 2004 6:15 PM
To: netfilter@lists.netfilter.org
Subject: Re: DNAT problem / question
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] 4+ 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; 4+ 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] 4+ 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; 4+ 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] 4+ messages in thread
end of thread, other threads:[~2004-06-21 9:14 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
-- strict thread matches above, loose matches on Subject: below --
2004-06-21 9:14 Arnauts, Bert
2004-06-18 15:45 DNAT problem / question Arnauts, Bert
2004-06-18 16:29 ` DNAT problem / question (nfcan: addressed to exclusive sender for this address) Jim Laurino
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox