updated iptables doesn't work with old rules

updated iptables doesn't work with old rules

[Daniel Nogradi]

I have updated my Fedora Core 3 box to the latest versions (in the FC3
branch) and now have

iptables-1.2.11-3.1.FC3
kernel-2.6.12-1.1381_FC3

and ip forwarding stopped working. Before the upgrade I had

iptables-1.2.11-3.1
kernel-2.6.9-1.667

The configuration is this:

machine A with FC3 ---------------- adsl modem -------------------- internet
  |
  |
  |
machine B
on a LAN

The FC3 box was using iptables for ip ipforwarding in order to let
'machine B' access the internet using these rules:

iptables --flush
iptables -t nat --flush
iptables --delete-chain
iptables -t nat --delete-chain
iptables -t nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables -t nat --append POSTROUTING -s 192.168.10.0/255.255.255.0 -j MASQUERADE
iptables --append FORWARD --in-interface eth1 -j ACCEPT

echo 1 > /proc/sys/net/ipv4/ip_forward

Now after the update these rules stopped working and nothing gets
through from 'machine B', although pinging works between machines A
and B both ways.

Any ideas as to what to change in these rules to have the same effect
as before the update?

Re: updated iptables doesn't work with old rules

[Rob Sterenborg]

On Wed, February 22, 2006 10:58, Daniel Nogradi wrote:
> I have updated my Fedora Core 3 box to the latest versions (in the FC3
> branch) and now have
>
> iptables-1.2.11-3.1.FC3
> kernel-2.6.12-1.1381_FC3
>
> and ip forwarding stopped working. Before the upgrade I had
>
> iptables-1.2.11-3.1
> kernel-2.6.9-1.667
>
> The configuration is this:
>
> machine A with FC3 ---------------- adsl modem -------------------- internet
>   |
>   |
>   |
> machine B
> on a LAN
>
> The FC3 box was using iptables for ip ipforwarding in order to let
> 'machine B' access the internet using these rules:
>
> iptables --flush
> iptables -t nat --flush
> iptables --delete-chain
> iptables -t nat --delete-chain

Does the nat table have user defined chains ?
If not then you don't need this rule.

> iptables -t nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
> iptables -t nat --append POSTROUTING -s 192.168.10.0/255.255.255.0 -j
> MASQUERADE

If eth0 is your internet NIC, eth1 your LAN nic and you use 192.168.10.0/24 on
your LAN then I think that no packet ever hits the latter rule.

> iptables --append FORWARD --in-interface eth1 -j ACCEPT
>
> echo 1 > /proc/sys/net/ipv4/ip_forward
>
> Now after the update these rules stopped working and nothing gets
> through from 'machine B', although pinging works between machines A
> and B both ways.

Machine A and B are on the same LAN so the FORWARD chain does not apply.
That traffic is controlled by the INPUT/OUTPUT chains.

> Any ideas as to what to change in these rules to have the same effect
> as before the update?

And the script does not generate any errors ?
Try adding (a) logging rule(s) in the FORWARD chain to see why packets are
dropped or rejected.
I suppose this is not your complete ruleset. Could it be that you have any
rules that might block this traffic ?


Gr,
Rob

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

> > iptables --flush
> > iptables -t nat --flush
> > iptables --delete-chain
> > iptables -t nat --delete-chain
>
> Does the nat table have user defined chains ?
> If not then you don't need this rule.


Well, I use these rules with all the flushes and deletes in order to
make sure nothing is at work behind the scenes.


> > iptables -t nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
> > iptables -t nat --append POSTROUTING -s 192.168.10.0/255.255.255.0 -j
> > MASQUERADE
>
> If eth0 is your internet NIC, eth1 your LAN nic and you use 192.168.10.0/24
> on
> your LAN then I think that no packet ever hits the latter rule.


Sorry, I should have detailed the cards and ip adresses before. There
are two cards in 'machine A': eth0 with 192.168.10.101 and eth1 with
192.168.10.102, eth0 is the internet NIC and eth1 is connected to the
hub to which 'machine B' with 192.168.10.103 connects as well. So the
picture should be:


'machine A' ---------------- adsl modem ---------- internet
   |
   |
  hub----------'machine B'


> And the script does not generate any errors ?
> Try adding (a) logging rule(s) in the FORWARD chain to see why packets are
> dropped or rejected.
> I suppose this is not your complete ruleset. Could it be that you have any
> rules that might block this traffic ?

There are no errors. I thought that doing the flush and delete at the
beginning makes sure that only these rules are applied, this is not
the case? In any event, these rules were working absolutely okay
before the update, but I don't insist on these at all, if any other
rule set will make B have internet access that would be great.

Re: updated iptables doesn't work with old rules

[Rob Sterenborg]

On Wed, February 22, 2006 12:25, Daniel Nogradi wrote:

>> > iptables -t nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
>> > iptables -t nat --append POSTROUTING -s 192.168.10.0/255.255.255.0 -j
>> > MASQUERADE
>>
>> If eth0 is your internet NIC, eth1 your LAN nic and you use 192.168.10.0/24
>> on your LAN then I think that no packet ever hits the latter rule.
>
>
> Sorry, I should have detailed the cards and ip adresses before. There
> are two cards in 'machine A': eth0 with 192.168.10.101 and eth1 with
> 192.168.10.102, eth0 is the internet NIC and eth1 is connected to the
> hub to which 'machine B' with 192.168.10.103 connects as well. So the
> picture should be:
>
>
> 'machine A' ---------------- adsl modem ---------- internet
>    |
>    |
>   hub----------'machine B'

And both NIC's have a /24 subnet ? If so, you should change that, eg. eth0:
192.168.10.0/24 and eth1: 192.168.11.0/24 (in which case machine B should also
be in 192.168.11.0/24).
Right now I think you (may) have a routing problem.

Something like :

Kernel IP routing table
Destination     Gateway         Genmask         Iface
192.168.10.0    192.168.10.1    255.255.255.0   eth0
192.168.11.0    192.168.11.1    255.255.255.0   eth1
0.0.0.0         192.168.10.1    0.0.0.0         eth0

echo 0 > /proc/sys/net/ipv4/ip_forward
$ipt -P FORWARD DROP
$ipt -F FORWARD
$ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
$ipt -A FORWARD -m state --state NEW -i eth1 -o eth0 \
  -s 192.168.11.0/24 -j ACCEPT
$ipt -t nat -F POSTROUTING
$ipt -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.10.101
echo 1 > /proc/sys/net/ipv4/ip_forward


Gr,
Rob

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

> And both NIC's have a /24 subnet ? If so, you should change that, eg. eth0:
> 192.168.10.0/24 and eth1: 192.168.11.0/24 (in which case machine B should
> also
> be in 192.168.11.0/24).
> Right now I think you (may) have a routing problem.
>
> Something like :
>
> Kernel IP routing table
> Destination     Gateway         Genmask         Iface
> 192.168.10.0    192.168.10.1    255.255.255.0   eth0
> 192.168.11.0    192.168.11.1    255.255.255.0   eth1
> 0.0.0.0         192.168.10.1    0.0.0.0         eth0
>
> echo 0 > /proc/sys/net/ipv4/ip_forward
> $ipt -P FORWARD DROP
> $ipt -F FORWARD
> $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> $ipt -A FORWARD -m state --state NEW -i eth1 -o eth0 \
>   -s 192.168.11.0/24 -j ACCEPT
> $ipt -t nat -F POSTROUTING
> $ipt -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.10.101
> echo 1 > /proc/sys/net/ipv4/ip_forward


Thanks a lot, I'll try this in the evening.




On 2/22/06, Ben Lentz <BLentz@channing-bete.com> wrote:
> To answer this question, can you get on the Internet from
> machine A? ping sourceforge.net?
>

Yes, from 'machine A' it is possible to connect to the internet. And
it is possible to ssh from 'machine B' to 'machine A' and then access
the internet. The only problem is (I think) with packet
forwarding/masquareding, since 'macine A' doesn't want to let the
packets from 'machine B' through.

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

(sorry if the formating is screwed up, I have only lynx at the moment)














> > echo 0 > /proc/sys/net/ipv4/ip_forward
> > $ipt -P FORWARD DROP
> > $ipt -F FORWARD
> > $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> > $ipt -A FORWARD -m state --state NEW -i eth1 -o eth0 \
> >   -s 192.168.11.0/24 -j ACCEPT
> > $ipt -t nat -F POSTROUTING
> > $ipt -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.10.101
> > echo 1 > /proc/sys/net/ipv4/ip_forward


This set of rules didn't work either and in fact I don't understand
why should one of the machines be named 192.168.11.x, everything being
192.168.10.x is not okay?

Anyway, what I have tried is:

# make sure we start from zero

iptables --flush
iptables -t nat --flush
iptables --delete-chain
iptables -t nat --delete-chain

# set up masquerading from LAN to modem which is hook up on eth0

iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE

# allow forwarding from LAN which is hookup up on eth1

iptables -A FORWARD --in-interface eth1 -j ACCEPT

# enable ip forwarding

echo 1 > /proc/sys/net/ipv4/ip_forwarding

Just to recap, my configuration is this:

machine A - eth0 ------------------ modem ------------ internet
  |
 eth1
  |
  |
  |
 hub
  |
  |
machine B

And I would like to access the internet from machine B, however the
above rules don't work even without specifying the sources and
allowing everything.

Any ideas?

Re: updated iptables doesn't work with old rules

[Chinh Nguyen]

Daniel Nogradi wrote:
> Anyway, what I have tried is:
> 
> # make sure we start from zero
> 
> iptables --flush
> iptables -t nat --flush
> iptables --delete-chain
> iptables -t nat --delete-chain
> 
> # set up masquerading from LAN to modem which is hook up on eth0
> 
> iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
> 
> # allow forwarding from LAN which is hookup up on eth1
> 
> iptables -A FORWARD --in-interface eth1 -j ACCEPT

I think that when you have a rule like this, you need the converse. ie,
iptables -A FORWARD --in-interface eth0 -j ACCEPT

If you want restrictions such that connections are initiated from B only, you
could restrict the inbound forward.

iptables -A FORWARD --in-interface eth0 -m state --state ESTABLISHED,RELATED -j
ACCEPT

> 
> # enable ip forwarding
> 
> echo 1 > /proc/sys/net/ipv4/ip_forwarding
> 
> Just to recap, my configuration is this:
> 
> machine A - eth0 ------------------ modem ------------ internet
>   |
>  eth1
>   |
>   |
>   |
>  hub
>   |
>   |
> machine B
> 
> And I would like to access the internet from machine B, however the
> above rules don't work even without specifying the sources and
> allowing everything.
> 
> Any ideas?
> 

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

On 2/22/06, Chinh Nguyen <cnguyen@certicom.com> wrote:
>
> Daniel Nogradi wrote:
> > Anyway, what I have tried is:
> >
> > # make sure we start from zero
> >
> > iptables --flush
> > iptables -t nat --flush
> > iptables --delete-chain
> > iptables -t nat --delete-chain
> >
> > # set up masquerading from LAN to modem which is hook up on eth0
> >
> > iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
> >
> > # allow forwarding from LAN which is hookup up on eth1
> >
> > iptables -A FORWARD --in-interface eth1 -j ACCEPT
>
> I think that when you have a rule like this, you need the converse. ie,
> iptables -A FORWARD --in-interface eth0 -j ACCEPT

> If you want restrictions such that connections are initiated from B only,
> you
> could restrict the inbound forward.
>
> iptables -A FORWARD --in-interface eth0 -m state --state ESTABLISHED,RELATED
> -j
> ACCEPT

Hi Chinh, I tried interchanging eth0 and eth1 and still no luck. I
didn't want to restrict the source yet, because I first would like to
see that it works at all, and then start tightening security.
/var/log/messages also says nothing. Is there any other log file which
would be useful to check?

Re: updated iptables doesn't work with old rules

[Chinh Nguyen]

Daniel Nogradi wrote:
> 
> Hi Chinh, I tried interchanging eth0 and eth1 and still no luck. I
> didn't want to restrict the source yet, because I first would like to
> see that it works at all, and then start tightening security.
> /var/log/messages also says nothing. Is there any other log file which
> would be useful to check?
>

I just did a quick test. With ip_forwarding on and no restrictions, it is
sufficient to use the MASQUERADE rule, no FORWARD rule needed. If MASQUERADE
isn't working, you can also try the SNAT rule.

To see how your packets are going through iptables, you can turn on some logging:

iptables -A PREROUTING -t nat --in-interface eth1 -j LOG --log-prefix "nat: "
iptables -A FORWARD --in-interface eth1 -j LOG --log-prefix "out-fwd: "

and so on.

These logs are kernel messages, so if kernel logs aren't enabled, you can edit
the /etc/syslog.conf file and restart syslogd. For example:

kern.*                /var/log/messages


Just a thought, how is your machine B resolving DNS? I'm assuming that machine A
gets its networking values including DNS from the modem. Is it communicating
this to machine B? Maybe it's a DNS issue. For example, are you testing by
pinging "google.com" or directly via an IP address?

Regards,

Chinh

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

> sufficient to use the MASQUERADE rule, no FORWARD rule needed. If MASQUERADE
> isn't working, you can also try the SNAT rule.
>
> To see how your packets are going through iptables, you can turn on some
> logging:
>
> iptables -A PREROUTING -t nat --in-interface eth1 -j LOG --log-prefix "nat:
> "
> iptables -A FORWARD --in-interface eth1 -j LOG --log-prefix "out-fwd: "
>
> and so on.
>
> These logs are kernel messages, so if kernel logs aren't enabled, you can
> edit
> the /etc/syslog.conf file and restart syslogd. For example:
>
> kern.*                /var/log/messages
>
>
> Just a thought, how is your machine B resolving DNS? I'm assuming that
> machine A
> gets its networking values including DNS from the modem. Is it communicating
> this to machine B? Maybe it's a DNS issue. For example, are you testing by
> pinging "google.com" or directly via an IP address?
>


Hi Chinh, on machine B DNS resolution doesn't work at all because the
name servers are on the internet which it can not access. So I'm not
pinging google.com but the IP addresses.

I've turned on logging and when I try to ssh, ping, etc, from B to A
then I get these messages on both B and in the logs of A:

kernel: nat: IN=eth1 OUT= MAC=(mac address of eth1) SRC=(IP of machine
B) DEST=213.191.74.18 LEN=54 TOS=0x00 PREC=0x00 TTL=64 ............
kernel: out: IN=eth1 OUT=ppp0 SRC=(IP of machine B) DEST=213.191.74.18
 ...........

What does this supposed to mean? :)

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

Oh, I forgot to mention that I have a dynamic IP so that's why I use
masquerading and not snat.

Re: updated iptables doesn't work with old rules

[Chinh Nguyen]

Daniel Nogradi wrote:
> Hi Chinh, on machine B DNS resolution doesn't work at all because the
> name servers are on the internet which it can not access. So I'm not
> pinging google.com but the IP addresses.
> 
> I've turned on logging and when I try to ssh, ping, etc, from B to A
> then I get these messages on both B and in the logs of A:
> 
> kernel: nat: IN=eth1 OUT= MAC=(mac address of eth1) SRC=(IP of machine
> B) DEST=213.191.74.18 LEN=54 TOS=0x00 PREC=0x00 TTL=64 ............
> kernel: out: IN=eth1 OUT=ppp0 SRC=(IP of machine B) DEST=213.191.74.18
>  ...........
> 
> What does this supposed to mean? :)
> 
It mean your packet traversed the prerouting nat eth1, and so on.

I would put 3 log messages, at "prerouting nat eth1", "forward", and
"postrouting nat". If your packet is seen at postrouting then it should be
successfully forwarded.

I noticed that your packet's outbound interface is ppp0. However, I recall your
MASQUERADE rule had "--out-interface eth0". Perhaps this is the cause and your
packet is not masqueraded? Try a simple "iptables -A POSTROUTING -t nat -j
MASQUERADE" without qualifiers.

Other things to try. Use ethereal to sniff eth1, and eth0/ppp0. Is there traffic?

Chinh

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

> It mean your packet traversed the prerouting nat eth1, and so on.
>
> I would put 3 log messages, at "prerouting nat eth1", "forward", and
> "postrouting nat". If your packet is seen at postrouting then it should be
> successfully forwarded.
>
> I noticed that your packet's outbound interface is ppp0. However, I recall
> your
> MASQUERADE rule had "--out-interface eth0". Perhaps this is the cause and
> your
> packet is not masqueraded? Try a simple "iptables -A POSTROUTING -t nat -j
> MASQUERADE" without qualifiers.
>
> Other things to try. Use ethereal to sniff eth1, and eth0/ppp0. Is there
> traffic?
>
> Chinh
>

Hi Chinh, thank you very much again, I'll try your suggestions tonight.

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

Hi Chinh, logging all 3 types (prerouting, forwarding, postrouting)
shows that the packets from 'machine B' never get postrouted. When I
ping from 'machine B' anything in the outside world messages are
logged about prerouting and forwarding but not postrouting, but
pinging from 'machine A' does result in logged messages about
postrouting (indeed, 'machine A' works fine). So I guess the problem
is around here, although I don't know exactly what this means.

I tried sniffing with tethereal too and that shows that the packets
actually get through from 'machine B' to the outside world, but never
return. For example sniffing eth0 while pinging from 'machine B' to
the outside world gives

1 29.996623 (my dynamical IP) -> (the IP I ping) ICMP Echo (ping) request
...

So I guess they get out, but can't get back to 'machine B'.

And I'm also quite confused about eth0/ppp0, perhaps a related issue
is that the kernel ip table of 'machine A' is

Destination    Gateway        Genmask         Flags Metric Ref Use  Iface
213.191.89.30     *           255.255.255.255  UH   0     0  0    ppp0
192.168.10.0      *           255.255.255.0    U  0     0  0    eth1
192.168.10.0      *           255.255.255.0    U  0     0  0     eth0
169.254.0.0       *           255.255.0.0      U  0     0  0    eth0
default        213.191.89.30  0.0.0.0          UG  0     0  0   ppp0

and what might be suspicious is that there are two identical lines one
with interface eth0 and the other with eth1. I'm not at all an expert
on routing (which you probably know by now :)) so I'm not sure if this
is a problem or not, but might be related.

Any clues?

On 2/23/06, Daniel Nogradi <nogradi@gmail.com> wrote:
> > It mean your packet traversed the prerouting nat eth1, and so on.
> >
> > I would put 3 log messages, at "prerouting nat eth1", "forward", and
> > "postrouting nat". If your packet is seen at postrouting then it should
> be
> > successfully forwarded.
> >
> > I noticed that your packet's outbound interface is ppp0. However, I
> recall
> > your
> > MASQUERADE rule had "--out-interface eth0". Perhaps this is the cause and
> > your
> > packet is not masqueraded? Try a simple "iptables -A POSTROUTING -t nat
> -j
> > MASQUERADE" without qualifiers.
> >
> > Other things to try. Use ethereal to sniff eth1, and eth0/ppp0. Is there
> > traffic?
> >
> > Chinh
> >
>
> Hi Chinh, thank you very much again, I'll try your suggestions tonight.
>

RE: updated iptables doesn't work with old rules

[Rob Sterenborg]

>>> echo 0 > /proc/sys/net/ipv4/ip_forward
>>> $ipt -P FORWARD DROP
>>> $ipt -F FORWARD
>>> $ipt -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>>> $ipt -A FORWARD -m state --state NEW -i eth1 -o eth0 \
>>>   -s 192.168.11.0/24 -j ACCEPT
>>> $ipt -t nat -F POSTROUTING
>>> $ipt -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.10.101
>>> echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> 
> This set of rules didn't work either and in fact I don't understand
> why should one of the machines be named 192.168.11.x, everything
> being 192.168.10.x is not okay? 

You can only have one 192.168.10.0/24 subnet. If both your NIC's have an
IP from that range, your routing rules will point to both NIC's as
gateway. The first gateway that matches a routing rule is "accepted".

So, machine A :
eth0: 192.168.10.1 (192.168.10.0/24)
eth1: 192.168.10.2 (192.168.10.0/24)

Your kernel IP routing table will looke like :
Destination     Gateway         Genmask         Iface
192.168.10.0    192.168.10.1    255.255.255.0   eth0
192.168.10.0    192.168.10.2    255.255.255.0   eth1

Say, machine B is connected to eth1 on machine A. Machine A sends a
packet. The first rule matches so it will send that packet via eth0, not
eth1. So machine B will never see the packet.

> Anyway, what I have tried is:
> 
> # make sure we start from zero
> 
> iptables --flush
> iptables -t nat --flush
> iptables --delete-chain
> iptables -t nat --delete-chain
> 
> # set up masquerading from LAN to modem which is hook up on eth0
> 
> iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE
> 
> # allow forwarding from LAN which is hookup up on eth1
> 
> iptables -A FORWARD --in-interface eth1 -j ACCEPT
> 
> # enable ip forwarding
> 
> echo 1 > /proc/sys/net/ipv4/ip_forwarding
> 
> Just to recap, my configuration is this:
> 
> machine A - eth0 ------------------ modem ------------ internet   |
>  eth1
>   |
>   |
>   |
>  hub
>   |
>   |
> machine B
> 
> And I would like to access the internet from machine B, however the
> above rules don't work even without specifying the sources and
> allowing everything. 
> 
> Any ideas?

Yeah.
If you don't use different subnets on each NIC, I still think you have a
routing problem.

==========
> Hi Chinh, I tried interchanging eth0 and eth1 and still no luck.

No. It won't work if you only allow forwarding from eth1 to eth0 (or
vv). You *also* need the reverse rule (not *instead of*).

If you do :
$ipt -A FORWARD -i eth1 -o eth0 -j ACCEPT

And do not accept RELATED,ESTABLISHED, you also need :
$ipt -A FORWARD -i eth0 -o eth1 -j ACCEPT

But that would be less secure. It's better to accept packets that are
already accepted by another (specific) rule. So, you'd have a rule like
:
$ipt -A FORWARD -m state --state RELATED,ESTABLISHED \
  -j ACCEPT
instead of the one above this.

===== Later post =====
> And I'm also quite confused about eth0/ppp0, perhaps a related
> issue is that the kernel ip table of 'machine A' is
> 
> Destination    Gateway        Genmask         Iface
> 213.191.89.30     *           255.255.255.255 ppp0
> 192.168.10.0      *           255.255.255.0   eth1
> 192.168.10.0      *           255.255.255.0   eth0
> 169.254.0.0       *           255.255.0.0     eth0
> default        213.191.89.30  0.0.0.0         ppp0

Ah.. I never saw anything about you using a ppp0 device before... From
your diagram I thought the modem(/router ?) was doing NAT also...
In that case, yes : you need MASQUERADE.

I think that your routing table shows the routing problem I'm talking
about.
If a packet gets sent to 192.168.10.100, you don't know via which NIC
it's going out, eth0 or eth1, because there are 2 rules for the same
subnet via different interfaces.
(I'm not sure if the routing table is showing the routes in processing
order.)

===== Later post =====
>> kernel: nat: IN=eth1 OUT= MAC=(mac address of eth1) SRC=(IP of
machine
>> B) DEST=213.191.74.18 LEN=54 TOS=0x00 PREC=0x00 TTL=64 ............
>> kernel: out: IN=eth1 OUT=ppp0 SRC=(IP of machine B)
DEST=213.191.74.18
>>  ...........
>> 
>> What does this supposed to mean? :)
> 
>It mean your packet traversed the prerouting nat eth1, and so on.

That depends on where the logging rules are and what they look like.
If the "nat" line is from the FORWARD chain, and the "out" line from the
OUTPUT chain, these packets are not really related because nat-ed
packets only travel the FORWARD chain, not the OUTPUT chain. The can be
related as such, because you use a ppp device over a eth0 (I thought it
was). But for netfilter that would be "another" packet.


Gr,
Rob

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

Hi Rob, thanks a lot for the enlightening remarks.

> You can only have one 192.168.10.0/24 subnet. If both your NIC's have an
> IP from that range, your routing rules will point to both NIC's as
> gateway. The first gateway that matches a routing rule is "accepted".
>
> So, machine A :
> eth0: 192.168.10.1 (192.168.10.0/24)
> eth1: 192.168.10.2 (192.168.10.0/24)
>
> Your kernel IP routing table will looke like :
> Destination     Gateway         Genmask         Iface
> 192.168.10.0    192.168.10.1    255.255.255.0   eth0
> 192.168.10.0    192.168.10.2    255.255.255.0   eth1
>
> Say, machine B is connected to eth1 on machine A. Machine A sends a
> packet. The first rule matches so it will send that packet via eth0, not
> eth1. So machine B will never see the packet.
>

> Yeah.
> If you don't use different subnets on each NIC, I still think you have a
> routing problem.
>
> ==========
> > Hi Chinh, I tried interchanging eth0 and eth1 and still no luck.
>
> No. It won't work if you only allow forwarding from eth1 to eth0 (or
> vv). You *also* need the reverse rule (not *instead of*).
>
> If you do :
> $ipt -A FORWARD -i eth1 -o eth0 -j ACCEPT
>
> And do not accept RELATED,ESTABLISHED, you also need :
> $ipt -A FORWARD -i eth0 -o eth1 -j ACCEPT
>
> But that would be less secure. It's better to accept packets that are
> already accepted by another (specific) rule. So, you'd have a rule like
> :
> $ipt -A FORWARD -m state --state RELATED,ESTABLISHED \
>   -j ACCEPT
> instead of the one above this.


Yes I understand the security issues, but first would like to see that
it works at all (accessing the outside world from 'machine B') and
then tighten security.


> ===== Later post =====
> > And I'm also quite confused about eth0/ppp0, perhaps a related
> > issue is that the kernel ip table of 'machine A' is
> >
> > Destination    Gateway        Genmask         Iface
> > 213.191.89.30     *           255.255.255.255 ppp0
> > 192.168.10.0      *           255.255.255.0   eth1
> > 192.168.10.0      *           255.255.255.0   eth0
> > 169.254.0.0       *           255.255.0.0     eth0
> > default        213.191.89.30  0.0.0.0         ppp0
>
> Ah.. I never saw anything about you using a ppp0 device before... From
> your diagram I thought the modem(/router ?) was doing NAT also...
> In that case, yes : you need MASQUERADE.


Well, that's only because of my not understanding how things work :)


> I think that your routing table shows the routing problem I'm talking
> about.
> If a packet gets sent to 192.168.10.100, you don't know via which NIC
> it's going out, eth0 or eth1, because there are 2 rules for the same
> subnet via different interfaces.
> (I'm not sure if the routing table is showing the routes in processing
> order.)


Okay, so it's a routing problem. I guess in order to change that and
make it right is through the ifcfg-eth0, ifcfg-eth1, ifcfg-ppp0 files,
isn't it? At the moment they are (on 'machine A'):

DEVICE=eth1
BOOTPROTO=none
BROADCAST=192.168.10.255
IPADDR=192.168.10.101
NETMASK=255.255.255.0
NETWORK=192.168.10.0
ONBOOT=yes
TYPE=Ethernet
GATEWAY=192.168.10.254

DEVICE=eth0
BROADCAST=192.168.10.255
IPADDR=192.168.10.105
NETMASK=255.255.255.0
NETWORK=192.168.10.0
TYPE=Ethernet
ONBOOT=yes
GATEWAY=192.168.10.254

USERCTL=yes
BOOTPROTO=dialup
NAME=DSLppp0
DEVICE=ppp0
TYPE=xDSL
ONBOOT=yes
PIDFILE=/var/run/pppoe-adsl.pid
FIREWALL=MASQUERADE
PING=.
PPPOE_TIMEOUT=80
LCP_FAILURE=3
LCP_INTERVAL=20
CLAMPMSS=1412
CONNECT_POLL=6
CONNECT_TIMEOUT=60
DEFROUTE=yes
SYNCHRONOUS=no
ETH=eth1
PROVIDER=DSLppp0
USER=02024784362
PEERDNS=yes
DEMAND=no
PERSIST=no

So I need to modify the NETWORK and GATEWAY parameters for eth0 and/or eth1?

Re: updated iptables doesn't work with old rules

[Rob Sterenborg]

On Fri, February 24, 2006 11:14, Daniel Nogradi wrote:
> Hi Rob, thanks a lot for the enlightening remarks.

Erm, well, I hope it was and that I didn't make a mistake anywhere.. ;-)

>> > And I'm also quite confused about eth0/ppp0, perhaps a related
>> > issue is that the kernel ip table of 'machine A' is
>> >
>> > Destination    Gateway        Genmask         Iface
>> > 213.191.89.30     *           255.255.255.255 ppp0
>> > 192.168.10.0      *           255.255.255.0   eth1
>> > 192.168.10.0      *           255.255.255.0   eth0
>> > 169.254.0.0       *           255.255.0.0     eth0
>> > default        213.191.89.30  0.0.0.0         ppp0

> Okay, so it's a routing problem. I guess in order to change that and
> make it right is through the ifcfg-eth0, ifcfg-eth1, ifcfg-ppp0 files,
> isn't it? At the moment they are (on 'machine A'):

Yes.

> DEVICE=eth1
> BOOTPROTO=none
> BROADCAST=192.168.10.255
> IPADDR=192.168.10.101
> NETMASK=255.255.255.0
> NETWORK=192.168.10.0
> ONBOOT=yes
> TYPE=Ethernet
> GATEWAY=192.168.10.254

This NIC seems to be connected to your hub/switch/machine B.
I'd say, because machine A -> internet works, put this one on the
192.168.11.0/24 network and machine B also. (You don't want to change things
that are already working.)

Change :
BROADCAST=192.168.11.255
IPADDR=192.168.11.1
NETWORK=192.168.11.0
GATEWAY=192.168.11.1

> DEVICE=eth0
> BROADCAST=192.168.10.255
> IPADDR=192.168.10.105
> NETMASK=255.255.255.0
> NETWORK=192.168.10.0
> TYPE=Ethernet
> ONBOOT=yes
> GATEWAY=192.168.10.254

Because you can use the internet on machine A, I suppose the config for eth0
is correct.

> USERCTL=yes
> BOOTPROTO=dialup
> NAME=DSLppp0
> DEVICE=ppp0
> TYPE=xDSL
> ONBOOT=yes
> PIDFILE=/var/run/pppoe-adsl.pid
> FIREWALL=MASQUERADE
> PING=.
> PPPOE_TIMEOUT=80
> LCP_FAILURE=3
> LCP_INTERVAL=20
> CLAMPMSS=1412
> CONNECT_POLL=6
> CONNECT_TIMEOUT=60
> DEFROUTE=yes
> SYNCHRONOUS=no
> ETH=eth1
> PROVIDER=DSLppp0
> USER=02024784362
> PEERDNS=yes
> DEMAND=no
> PERSIST=no

You shouldn't have to do anything here. It works already.

> So I need to modify the NETWORK and GATEWAY parameters for eth0 and/or eth1?

No, only eth1 :-)
And look back at the rules that I replied with earlier. I think those should
work for you.

If this doesn't work then I would start adding a log rule at the end of the
FORWARD chain, right before packets are dropped, and see when/why packets are
dropped.


Gr,
Rob

Re: updated iptables doesn't work with old rules

[Chinh Nguyen]

Rob Sterenborg wrote:

> On Fri, February 24, 2006 11:14, Daniel Nogradi wrote:
>>DEVICE=eth1
>>BOOTPROTO=none
>>BROADCAST=192.168.10.255
>>IPADDR=192.168.10.101
>>NETMASK=255.255.255.0
>>NETWORK=192.168.10.0
>>ONBOOT=yes
>>TYPE=Ethernet
>>GATEWAY=192.168.10.254
> 
> 
> This NIC seems to be connected to your hub/switch/machine B.
> I'd say, because machine A -> internet works, put this one on the
> 192.168.11.0/24 network and machine B also. (You don't want to change things
> that are already working.)
> 
> Change :
> BROADCAST=192.168.11.255
> IPADDR=192.168.11.1
> NETWORK=192.168.11.0
> GATEWAY=192.168.11.1
> 
> 
>>DEVICE=eth0
>>BROADCAST=192.168.10.255
>>IPADDR=192.168.10.105
>>NETMASK=255.255.255.0
>>NETWORK=192.168.10.0
>>TYPE=Ethernet
>>ONBOOT=yes
>>GATEWAY=192.168.10.254
> 
> 
> Because you can use the internet on machine A, I suppose the config for eth0
> is correct.

Daniel, you should try Rob's advice and see if you can get further. Here are
some my two cents. I've never done a PPPoE/DSL in Linux but I noticed a few odd
things about your configuration.

> 
>>USERCTL=yes
>>BOOTPROTO=dialup
>>NAME=DSLppp0
>>DEVICE=ppp0
>>TYPE=xDSL
>>ONBOOT=yes
>>PIDFILE=/var/run/pppoe-adsl.pid
>>FIREWALL=MASQUERADE
>>PING=.
>>PPPOE_TIMEOUT=80
>>LCP_FAILURE=3
>>LCP_INTERVAL=20
>>CLAMPMSS=1412
>>CONNECT_POLL=6
>>CONNECT_TIMEOUT=60
>>DEFROUTE=yes
>>SYNCHRONOUS=no
>>ETH=eth1
>>PROVIDER=DSLppp0
>>USER=02024784362
>>PEERDNS=yes
>>DEMAND=no
>>PERSIST=no

The line ETH=eth1 suggests to me that your PPP connection is bound to eth1.
However, in your previous messages you state that eth1 is on the private side
(attached to machine B) and eth0 is on the public side. This seems odd.

Additionally, resources on the net regarding PPP connections (usually bound to
eth0) has a similar ppp0 configuration as yours. But the associated interface
(usually eth0) for a ppp0 connection is usually down and not configured.

DEVICE=eth0
ONBOOT=no

For example, the section "IP Address Assignment for a Direct DSL Connection" of
URL http://www.siliconvalleyccie.com/linux-hn/network-linux.htm

Re: updated iptables doesn't work with old rules

[Daniel Nogradi]

Hi Chinh and Rob,

Let me first thank you both very much for your help and explanation,
now everything works, routing was the problem as well as me not
understanding the iptables rules properly so was always setting
something not correct.


> >>DEVICE=eth1
> >>BOOTPROTO=none
> >>BROADCAST=192.168.10.255
> >>IPADDR=192.168.10.101
> >>NETMASK=255.255.255.0
> >>NETWORK=192.168.10.0
> >>ONBOOT=yes
> >>TYPE=Ethernet
> >>GATEWAY=192.168.10.254
> >
> >
> > This NIC seems to be connected to your hub/switch/machine B.
> > I'd say, because machine A -> internet works, put this one on the
> > 192.168.11.0/24 network and machine B also. (You don't want to change
> things
> > that are already working.)
> >
> > Change :
> > BROADCAST=192.168.11.255
> > IPADDR=192.168.11.1
> > NETWORK=192.168.11.0
> > GATEWAY=192.168.11.1


I changed this, now the internal net is on 192.168.11.0.


> >>DEVICE=eth0
> >>BROADCAST=192.168.10.255
> >>IPADDR=192.168.10.105
> >>NETMASK=255.255.255.0
> >>NETWORK=192.168.10.0
> >>TYPE=Ethernet
> >>ONBOOT=yes
> >>GATEWAY=192.168.10.254
> >
> >
> > Because you can use the internet on machine A, I suppose the config for
> eth0
> > is correct.


Indeed, I didn't change that and it's still working :)


> Daniel, you should try Rob's advice and see if you can get further. Here are
> some my two cents. I've never done a PPPoE/DSL in Linux but I noticed a few
> odd things about your configuration.
>
> >
> >>USERCTL=yes
> >>BOOTPROTO=dialup
> >>NAME=DSLppp0
> >>DEVICE=ppp0
> >>TYPE=xDSL
> >>ONBOOT=yes
> >>PIDFILE=/var/run/pppoe-adsl.pid
> >>FIREWALL=MASQUERADE
> >>PING=.
> >>PPPOE_TIMEOUT=80
> >>LCP_FAILURE=3
> >>LCP_INTERVAL=20
> >>CLAMPMSS=1412
> >>CONNECT_POLL=6
> >>CONNECT_TIMEOUT=60
> >>DEFROUTE=yes
> >>SYNCHRONOUS=no
> >>ETH=eth1
> >>PROVIDER=DSLppp0
> >>USER=02024784362
> >>PEERDNS=yes
> >>DEMAND=no
> >>PERSIST=no
>
> The line ETH=eth1 suggests to me that your PPP connection is bound to eth1.
> However, in your previous messages you state that eth1 is on the private
> side
> (attached to machine B) and eth0 is on the public side. This seems odd.


Now you've got me. To tell the truth in my first post I accidently
interchanged eth0 and eth1 so in all further posts I systematically
kept interchanging them in order not to mix up the conversation, so
whenever I was talking about eth1 I meant eth0 and vica versa, in
principle it's not a problem if it's systematic (this was not the real
problem as I kept track of the interchange). But as you correctly
point out in this above file, ifcfg-ppp0, I forgot to change it and
left the original in :)


> Additionally, resources on the net regarding PPP connections (usually bound
> to eth0) has a similar ppp0 configuration as yours. But the associated
> interface (usually eth0) for a ppp0 connection is usually down and not configured.
>
> DEVICE=eth0
> ONBOOT=no


Thanks for this as well, I changed it to ONBOOT=no.

At the moment my rules are:


echo 0 > /proc/sys/net/ipv4/ip_forward
iptables --flush
iptables -t nat --flush
iptables --delete-chain
iptables -t nat --delete-chain
iptables -P FORWARD DROP
iptables -F FORWARD
iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT
iptables -A FORWARD -o eth0 -i ppp0 -j ACCEPT
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

which I understand are not secure or in any way optimal, but at least
they work, so I'll start adding the suggestions of both of you to make
them what they really supposed to be.

Thanks again very much!

RE: updated iptables doesn't work with old rules

[Rob Sterenborg]

> Hi Chinh and Rob,
> 
> Let me first thank you both very much for your help and explanation,

You're welcome.

> now everything works, routing was the problem as well as me not
> understanding the iptables rules properly so was always setting
> something not correct. 

I don't know if you found it already, but I find Oscar's iptables
tutorial a good read :
http://iptables-tutorial.frozentux.net/iptables-tutorial.html

>> Additionally, resources on the net regarding PPP connections
>> (usually bound to eth0) has a similar ppp0 configuration as yours.
>> But the associated interface (usually eth0) for a ppp0 connection is
>> usually down and not configured. 
>> 
>> DEVICE=eth0
>> ONBOOT=no
> 
> Thanks for this as well, I changed it to ONBOOT=no.

Are you by any change using an Alcatel/Thomson ADSL modem (don't know if
this is going to work on other modem brands) ? In that case you may be
able to get rid of ppp0 by using SIP spoofing (which has nothing to do
with VOIP) and have the internet IP address directly on your NIC.
I find it easier to use, but the only modem/router I know of that can do
this are manufactured by Alcatel/Thomson.

> At the moment my rules are:
> 
> echo 0 > /proc/sys/net/ipv4/ip_forward
> iptables --flush
> iptables -t nat --flush
> iptables --delete-chain
> iptables -t nat --delete-chain
> iptables -P FORWARD DROP
> iptables -F FORWARD
> iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT
> iptables -A FORWARD -o eth0 -i ppp0 -j ACCEPT

This is effectively the same as having no rules in the FORWARD chain
when it's policy is ACCEPT. (Okay, not completely because you didn't
specify the eth1 device.)

For a start, make that :
iptables -A FORWARD -m state --state NEW -i eth0 -o ppp0 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

> iptables -t nat -F POSTROUTING
> iptables -t nat -A POSTROUTING -j MASQUERADE
> echo 1 > /proc/sys/net/ipv4/ip_forward


Gr,
Rob