Package: iptables
Version: 1.4.2-6
Severity: normal
This bug didn't seem to get through the first time I filed it; trying
again with a different (valid) email address and including more information.
I had a firewall/router configuration that was working fine. After lenny
upgrade, the internal LAN clients can ping outside hosts, but not
connect to them.
I believe this might be the same as Ubuntu Bug #320899 -- at least the
symptoms are the same:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/320899
I have a simple home router setup. The router runs Debian Lenny; the
client runs Ubuntu. The router has two NICs; one connects to the ISP,
the other to an internal switch.
The router box has no network issues with the Internet. I can ping, surf
websites, etc..
The client box has no problems talking to the router. I can ssh to the
router, mount NFS shares, etc..
Before the Lenny upgrade, the router box was forwarding Internet traffic
from the client to the Internet without trouble.
After the Lenny upgrade, I can no longer make any connection from the
client to the Internet that transmits more than few bytes. I can ping
from the client, do DNS lookups, and even get a short error message from
an external website by telnetting from the client to port 80 on the
external website and sending an invalid requst. If I send a *valid*
request, however (e.g. GET /index.html HTTP/1.0), I get no response. The
connection just times out.
/proc/net/ip_conntrack shows all the relevant connections in CLOSE_WAIT
or TIME_WAIT status.
sysctl is properly configured:
net.ipv4.conf.all.forwarding = 1
I have ip_masquerading enabled.
I don't think this is a problem with the forwarding setup, since I am
able to ping and make an initial HTTP connection. It's only when more
than a few bytes are supposed to come back that it times out.
Finally, just as an experiment, I tried reducing the MTU packet size on
the client, but it made no difference.
Nothing relevant appears in syslog or kernel logs. I tried logging
packets in invalid state; no luck.
Here is a tcpdump of an attempted HTTP connection from an internal
client to the Ubuntu website:
First, looking at the inward (LAN) facing NIC:
# tcpdump host 91.189.94.156
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
18:24:22.312327 IP adam-laptop.local.32813 > vostok.canonical.com.www: F
369271110:369271110(0) ack 2135471707 win 183 <nop,nop,sack 1 {645:646}>
18:24:22.607962 IP adam-laptop.local.32813 > vostok.canonical.com.www: F
0:0(0) ack 1 win 183 <nop,nop,sack 1 {645:646}>
18:24:23.096016 IP adam-laptop.local.33080 > vostok.canonical.com.www: S
1741147798:1741147798(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 5>
18:24:23.181761 IP vostok.canonical.com.www > adam-laptop.local.33080: S
3499878451:3499878451(0) ack 1741147799 win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 7>
18:24:23.182918 IP adam-laptop.local.33080 > vostok.canonical.com.www: .
ack 1 win 183
18:24:23.183338 IP adam-laptop.local.33080 > vostok.canonical.com.www: P
1:191(190) ack 1 win 183
18:24:23.207938 IP adam-laptop.local.32813 > vostok.canonical.com.www: F
0:0(0) ack 1 win 183 <nop,nop,sack 1 {645:646}>
18:24:23.272335 IP vostok.canonical.com.www > adam-laptop.local.33080: .
ack 191 win 54
18:24:23.273074 IP vostok.canonical.com.www > adam-laptop.local.33080: F
645:645(0) ack 191 win 54
18:24:23.274460 IP adam-laptop.local.33080 > vostok.canonical.com.www: .
ack 1 win 183 <nop,nop,sack 1 {645:646}>
18:24:24.408312 IP adam-laptop.local.32813 > vostok.canonical.com.www: F
0:0(0) ack 1 win 183 <nop,nop,sack 1 {645:646}>
18:24:26.807891 IP adam-laptop.local.32813 > vostok.canonical.com.www: F
0:0(0) ack 1 win 183 <nop,nop,sack 1 {645:646}>
18:24:31.607770 IP adam-laptop.local.32813 > vostok.canonical.com.www: F
0:0(0) ack 1 win 183 <nop,nop,sack 1 {645:646}>
18:24:41.207531 IP adam-laptop.local.32813 > vostok.canonical.com.www: F
0:0(0) ack 1 win 183 <nop,nop,sack 1 {645:646}>
So it just seems to hang there after the first couple of return packets.
Then looking at the outward Internet facing NIC (replaced my public IP
address with X's):
# tcpdump -i eth2 host 91.189.94.156
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
18:25:08.096555 IP c-xx-xx-xxx-xxx.hsd1.ma.comcast.net.33081 >
vostok.canonical.com.www: S 2430423974:2430423974(0) win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 5>
18:25:08.181948 IP vostok.canonical.com.www >
c-xx-xx-xxx-xxx.hsd1.ma.comcast.net.33081: S 4206892525:4206892525(0)
ack 2430423975 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7>
18:25:08.183390 IP c-xx-xx-xxx-xxx.hsd1.ma.comcast.net.33081 >
vostok.canonical.com.www: . ack 1 win 183
18:25:08.183810 IP c-xx-xx-xxx-xxx.hsd1.ma.comcast.net.33081 >
vostok.canonical.com.www: P 1:191(190) ack 1 win 183
18:25:08.273741 IP vostok.canonical.com.www >
c-xx-xx-xxx-xxx.hsd1.ma.comcast.net.33081: . ack 191 win 54
18:25:08.274002 IP vostok.canonical.com.www >
c-xx-xx-xxx-xxx.hsd1.ma.comcast.net.33081: F 645:645(0) ack 191 win 54
18:25:08.275368 IP c-xx-xx-xxx-xxx.hsd1.ma.comcast.net.33081 >
vostok.canonical.com.www: . ack 1 win 183 <nop,nop,sack 1 {645:646}>
18:25:38.806249 IP adam-laptop.local.32813 > vostok.canonical.com.www: F
369271110:369271110(0) ack 2135471707 win 183 <nop,nop,sack 1 {645:646}>
And then it just hangs.
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (700, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages iptables depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
iptables recommends no packages.
iptables suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
