Hi,
After restarting iptables:
/etc/network# iptables -t filter -L FORWARD -v -n
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
20 1032 ACCEPT 0 -- eth2 eth1 192.168.5.0/24 0.0.0.0/0
0 0 ACCEPT 0 -- *
* 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 LOG 0 -- * eth1 0.0.0.0/0 192.168.5.0/24 LOG flags 0 level 4
0 0 DROP 0 -- * eth1 0.0.0.0/0 192.168.5.0/24
0 0 LOG 0 -- *
* 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4
0 0 DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0
/etc/network#
/etc/network# iptables -t nat -L POSTROUTING -v -n
Chain POSTROUTING (policy ACCEPT 51 packets, 2847 bytes)
pkts bytes target prot opt in out source destination
16 888 MASQUERADE 0 -- *
eth1 192.168.5.0/24 0.0.0.0/0
/etc/network#
After Adding those two rulles:
General forward : IN=eth2 OUT=eth1 SRC="" DST=216.109.112.135 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=234 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=12
General forward : IN=eth2 OUT=eth1 SRC="" DST=216.109.112.135 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=235 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=13
General forward : IN=eth2 OUT=eth1 SRC="" DST=216.109.112.135 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=236 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=14
General forward : IN=eth2 OUT=eth1 SRC="" DST=216.109.112.135 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=237 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=15
So you were
right...
The rest of informations:
/etc/network# iptables --version
iptables v1.3.6
/etc/network# uname -r
2.6.18-6-amd64
About Vmware, I suppose your're thinking to vmware esx Server cause that is OS independent. I'm using vmware workstation, which is installed over Debian, but as Alex said, vmware has it's own network modules. Ping attemps from an guest OS it's working fine.
Thanks,
Mihai
----- Forwarded Message ----
From: Bonnel Christophe <mage.tophinus@free.fr>
To: chindea mihai <misubs24@yahoo.com>
Cc: debian-amd64@lists.debian.org
Sent: Wednesday, April 2, 2008 5:12:24 AM
Subject: Re: NAT and IPTABLES problem
It seems that your firewall is ok but he don't receive feedback from
what the laptop asks :
>
> Chain FORWARD (policy DROP 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
> 19 1140 ACCEPT 0 -- eth2 eth1 192.168.5.0/24
> 0.0.0.0/0
> 0 0 ACCEPT 0 -- * * 0.0.0.0/0
> 0.0.0.0/0 state RELATED,ESTABLISHED
> 0 0 LOG 0 -- * eth1 0.0.0.0/0
>
192.168.5.0/24 LOG flags 0 level 4
> 0 0 DROP 0 -- * eth1 0.0.0.0/0
> 192.168.5.0/24
> 0 0 LOG 0 -- * * 0.0.0.0/0
> 0.0.0.0/0 LOG flags 0 level 4
> 0 0 DROP 0 -- * * 0.0.0.0/0
> 0.0.0.0/0
To confirm what i say, can you relaunch your firewall (to clear the
counts), launch a ping with laptop and after the "error", re-post the
output of
iptables -t filter -L FORWARD -v -n
iptables -t nat -L POSTROUTING -v
-n
You can also add these lines and re-try a ping :
/sbin/iptables -t filter -I FORWARD 1 -j LOG --log-prefix "General
forward : " --log-tcp-sequence --log-tcp-options --log-ip-options
/sbin/iptables -t filter -I FORWARD 3 -j LOG --log-prefix "Feedback
forward : " --log-tcp-sequence --log-tcp-options --log-ip-options
now you can delete them by relauching the firewall or do :
/sbin/iptables -t filter -D FORWARD 3
/sbin/iptables -t filter -D FORWARD 1
And see with dmesg what it gives you (i think only General and no
Feedback if my assumptions are true)
That is a thing that annoy me :
>
> Chain OUTPUT (policy DROP 1 packets, 92 bytes)
> pkts bytes target prot opt in out source
> destination
> 22 10448 ACCEPT 0 -- *
lo 0.0.0.0/0
> 0.0.0.0/0
> 0 0 ACCEPT 0 -- * eth2 0.0.0.0/0
> 255.255.255.255
> 35 1399 ACCEPT 0 -- * eth2 0.0.0.0/0
> 192.168.5.0/24
> 1 107 ACCEPT !tcp -- * eth2 0.0.0.0/0
> 224.0.0.0/4
> 0 0 LOG 0 -- * eth1 0.0.0.0/0
> 192.168.5.0/24 LOG flags 0 level 4
> 0 0
DROP 0 -- * eth1 0.0.0.0/0
> 192.168.5.0/24
> 0 0 ACCEPT 0 -- * eth1 0.0.0.0/0
> 255.255.255.255
> 89 9594 ACCEPT 0 -- * eth1 xx.xx.xx.221
> 0.0.0.0/0
> 0 0 ACCEPT 0 -- * eth1 xx.xx.xx.255
> 0.0.0.0/0
> 0 0 LOG 0 -- * * 0.0.0.0/0
> 0.0.0.0/0
LOG flags 0 level 4
> 0 0 DROP 0 -- * * 0.0.0.0/0
> 0.0.0.0/0
>
The last line of OUTPUT drops all connections but the default policy
have dropped one. That is not related to your problem, but it can be a
iptables or kernel problem...
Can you post /sbin/iptables --version, uname -r ?
If I understand, when your gateway is used with VMware and not debian,
your laptop can ping with no problem ?
Christophe