| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <5069E0E1.7030906@googlemail.com>
Date: Mon, 01 Oct 2012 19:28:49 +0100
From: Chris Clayton <chris2553@...glemail.com>
To: Eric Dumazet <eric.dumazet@...il.com>
CC: David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
gpiez@....de
Subject: Re: Possible networking regression in 3.6.0
On 10/01/12 17:37, Eric Dumazet wrote:
> On Mon, 2012-10-01 at 17:19 +0100, Chris Clayton wrote:
>>
>> On 10/01/12 16:31, Eric Dumazet wrote:
>>> On Mon, 2012-10-01 at 16:13 +0100, Chris Clayton wrote:
>>>>
>>>> On 10/01/12 10:15, Eric Dumazet wrote:
>>>>> On Mon, 2012-10-01 at 09:36 +0100, Chris Clayton wrote:
>>>>>>
>>>>>
>>>>>> 0 ICMP messages received
>>>>>> 0 input ICMP message failed.
>>>>>> ICMP input histogram:
>>>>>> 0 ICMP messages sent
>>>>>> 0 ICMP messages failed
>>>>>> ICMP output histogram:
>>>>>
>>>>>>
>>>>>> After:
>>>>>>
>>>>>> $ netstat -s
>>>>>> Icmp:
>>>>>> 4 ICMP messages received
>>>>>> 4 input ICMP message failed.
>>>>>> ICMP input histogram:
>>>>>> echo replies: 4
>>>>>
>>>>> So icmp replies come back and are delivered to host instead of being
>>>>> forwarded.
>>>>>
>>>>> I wonder if MASQUERADE broke...
>>>>>
>>>>> Could you send
>>>>>
>>>>> iptables -t -nat -nvL
>>>>
>>>> $ iptables -t -nat -nvL
>>>> iptables v1.4.15: can't initialize iptables table `-nat': Table does not
>>>> exist (do you need to insmod?)
>>>> Perhaps iptables or your kernel needs to be upgraded.
>>>>
>>>>> conntrack -L # while ping is running from guest
>>>>
>>>> $ conntrack -L
>>>> conntrack v1.2.2 (conntrack-tools): Operation failed: invalid parameters
>>>>
>>>
>>> Thats not expected, you described you used MASQUERADE target, so
>>> "iptables -t nat -nvL" should display something.
>>>
>>
>> To check this I've booted a 3.5.4 kernel. I get the same response to the
>> two commands. I also double checked that, with a 3.5.4 kernel, pinging
>> the router and browsing the internet from the client work and they do.
>>
>> Except for the packets and bytes columns, the command iptables -nvL
>> gives the following output under both 3.5.4 and 3.6.0 kernels:
>>
>> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>> pkts bytes target prot opt in out source destination
>> 3757 3240K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
>> state RELATED,ESTABLISHED
>> 14 840 ACCEPT all -- * * 127.0.0.1 127.0.0.1
>> 41 4362 ACCEPT all -- * * 192.168.0.0/24 0.0.0.0/0
>> 90 12780 ACCEPT all -- * * 192.168.200.0/24 0.0.0.0/0
>> 0 0 ACCEPT all -- * * 192.168.201.0/24 0.0.0.0/0
>> 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
>>
>> Chain FORWARD (policy ACCEPT 4470 packets, 3065K bytes)
>> pkts bytes target prot opt in out source destination
>>
>> Chain OUTPUT (policy ACCEPT 3243 packets, 349K bytes)
>> pkts bytes target prot opt in out source destination
>> 64 8344 ACCEPT all -- * * 0.0.0.0/0 192.168.200.0/24
>> 0 0 ACCEPT all -- * * 0.0.0.0/0 192.168.201.0/24
>
> I am lost, since n your first mail you said :
> -----------------------------------------------------------------------------
> # Load the connection-sharing for qemu/kvm guests
> echo 1 > /proc/sys/net/ipv4/ip_forward
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> ...
> # allow traffic to and from the qemu/kvm virtual networks
> NETS="200 201"
> for net in $NETS; do
> iptables -A INPUT -s 192.168.$net.0/24 -j ACCEPT
> iptables -A OUTPUT -d 192.168.$net.0/24 -j ACCEPT
> done
> ...
>
> The network-related modules that are loaded are:
>
> $ lsmod
> Module Size Used by
> tun 12412 0
> xt_state 891 1
> iptable_filter 852 1
> ipt_MASQUERADE 1222 1
> iptable_nat 3087 1
> nf_nat 10901 2 ipt_MASQUERADE,iptable_nat
> nf_conntrack_ipv4 4942 4 nf_nat,iptable_nat
> nf_defrag_ipv4 815 1 nf_conntrack_ipv4
> nf_conntrack 37644 5
> ipt_MASQUERADE,nf_nat,xt_state,iptable_nat,nf_conntrack_ipv4
> ...
> r8169 47159 0
>
>
> -----------------------------------------------
>
> Now you say you dont have nat ?
>
> Something is wrong.
>
Here's the complete script that starts up my firewall. I can't recall
having changed this at all for two or three years, other than when a
replacement router changed the network from 192.168.1.x or I add (or
remove) other networks to (from) the $NETS list for other KVM clients
$ cat /etc/rc.d/rc.firewall
#! /bin/sh
case "$1" in
stop)
echo 0 > /proc/sys/net/ipv4/ip_forward
# clear out the current settings
iptables -F
iptables -X
iptables -Z
;;
start)
# Load the connection-sharing for qemu/kvm guests
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allow anything internal to this machine (i.e. localhost)
# is this really necessary?
iptables -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
# Allow any traffic from nodes on home network
iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT
# and traffic to and from the qemu/kvm virtual networks
NETS="200 201"
for net in $NETS; do
iptables -A INPUT -s 192.168.$net.0/24 -j ACCEPT
iptables -A OUTPUT -d 192.168.$net.0/24 -j ACCEPT
done
# drop everything else
# iptables -A INPUT -j LOG --log-level 4 --log-prefix "FIREWALL: "
iptables -A INPUT -j DROP
;;
restart|reload)
$0 stop
$0 start
;;
status)
iptables -L
;;
*)
echo "Usage: $0 {start|stop|restart|reload|status}"
exit 1
;;
esac
>
eth0 is set up by calling /sbin/ifup from udev on the add event for eth0
(wlan0 is disabled on the laptop, so that won't be getting in the way).
Here's the script (the SSID is not really XXXXX:
$ cat /sbin/ifup
#!/bin/sh
PATH="/usr/bin:/usr/sbin:/sbin:/bin"
export PATH
SSID=XXXXX
#logger "$0 called with arguments $@"
if [ "$1" = "wlan0" ]; then
# Bring the interface up before the iwconfig stuff below
# assign ip address later else association with AP fails when using WPA
ifconfig wlan0 up
# Configure the wireless adapter
iw wlan0 connect $SSID
# start wpa_supplicant
if [ -z `pgrep wpa_supplicant` ]; then
wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf
-iwlan0 -Dwext -B -f/var/log/wpa_supplicant.log
fi
# wait until associated with the AP - can take a while with WPA
secs=0
until iw wlan0 link | grep -q "SSID: $SSID"; do
let secs++
if [ $secs -ge 20 ]; then
logger -p user.err -t IFUP "Failed to associate with AP
within 20 seconds"
exit -1
fi
sleep 1
done
# set the regulatory domain (kernel >= 2.6.28)
iw reg set GB
ifconfig wlan0 192.168.0.140 netmask 255.255.255.0 up
route add default gw 192.168.0.1 netmask 0.0.0.0 metric 1
exit 0
fi
if [ "$1" = "eth0" ] ; then
# load the module if necessary
if ! grep -q eth0 /proc/net/dev; then
modprobe r8169
fi
# wait up to 5 seconds for eth0 to appear
secs=0
until grep -q eth0 /proc/net/dev; do
let secs++
if [ $secs -ge 5 ]; then
logger -p user.err -t IFUP "eth0 failed to appear within 5
seconds"
exit -1
fi
sleep 1
done
ifconfig eth0 192.168.0.40 netmask 255.255.255.0 up
route add default gw 192.168.0.1 netmask 0.0.0.0 metric 1
exit 0
fi
When the KVM client is running the routing on the host is:
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
default router.local.la 0.0.0.0 UG 1 0 0 eth0
Unix * 255.0.0.0 U 0 0 0 lo
local.lan * 255.255.255.0 U 0 0 0 eth0
192.168.200.0 * 255.255.255.0 U 0 0 0 tap0
Like I say, the set up has been like this for ages and has worked. It's
only since I started using 3.6 kernels that I've had a problem. I don't
recall anything from the nat table ever having been listed by iptables -L.
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists