Bug 161793

Summary: ip_conntrack fails in dom0 when xend starts and creates bridge
Product: [Fedora] Fedora Reporter: jonny.fahrenheit451
Component: xenAssignee: Rik van Riel <riel>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-18 14:43:00 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description jonny.fahrenheit451 2005-06-27 09:41:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
Problem:-
New install of fedora core 4 with xen kernel running. Iptables rules that under
the regular kernel work fine stop working when in bridge mode under xen in dom0.
This stops the conntrack system working on the xen host machine and i can't then
log in via ssh.
It seems that the conntrack system is failing to match already accepted
connections. The initial packet seems to get accepted by the INPUT rule, then
the reply packet slips past the ESTABLISHED,RELATED rule and gets logged then
dropped by the default policy.
The ip_conntrack, state modules and all the other modules are loaded.

This is the packet that gets logged:-
xen kernel: OUTPUT IN= OUT=xen-br0 PHYSOUT=eth0 SRC=192.168.0.45
DST=192.168.0.39 LEN=48 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22
DPT=1152 WINDOW=5840 RES=0x00 ACK SYN URGP=0

This happens whether i start a guest os up or not.
This was reproduced on another machine at work with a Fedora Core 4 install.

xen host machine address:192.168.0.45
ssh client address:192.168.0.39

rules:-
Chain FORWARD (policy DROP 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
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0  
        LOG flags 0 level 4 prefix `FORWARD '

Chain INPUT (policy DROP 54 packets, 7483 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  304 21532 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0  
        state RELATED,ESTABLISHED
    1    48 ACCEPT     tcp  --  *      *       192.168.0.39         192.168.0.45
      tcp spts:1024:65535 dpt:22 state NEW
   54  7483 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0  
        LOG flags 0 level 4 prefix `INPUT '

Chain OUTPUT (policy DROP 8 packets, 384 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0  
        state RELATED,ESTABLISHED
    0     0 ACCEPT     udp  --  *      *       192.168.0.45         192.168.0.19
      udp spts:1024:65535 dpt:53
    0     0 ACCEPT     tcp  --  *      *       192.168.0.45         0.0.0.0/0  
        tcp spts:1024:65535 dpt:80
    0     0 ACCEPT     icmp --  *      *       192.168.0.45         0.0.0.0/0
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0  
        LOG flags 0 level 4 prefix `OUTPUT '

interfaces:-
eth0      Link encap:Ethernet  HWaddr 00:08:74:EE:50:ED
          inet addr:192.168.0.45  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24684 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4406 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1992235 (1.8 MiB)  TX bytes:631910 (617.0 KiB)
          Base address:0xecc0 Memory:ff8e0000-ff900000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  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:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

xen-br0   Link encap:Ethernet  HWaddr 00:08:74:EE:50:ED
          inet addr:192.168.0.45  Bcast:192.168.0.255  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24682 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4451 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1538495 (1.4 MiB)  TX bytes:618890 (604.3 KiB)

routes:-
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 xen-br0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 xen-br0
0.0.0.0         192.168.0.250   0.0.0.0         UG    0      0        0 xen-br0

operating system:-
Fedora Core 4

kernel version:-
2.6.11-1.1369_FC4xen0

iptables version:-
iptables v1.3.0

xen version:-
xen-2-20050522

network driver:-
e1000

Had everything working under fedora core 3 before with iptables and 5 virtual
machines.

Version-Release number of selected component (if applicable):
xen-2-20050522

How reproducible:
Always

Steps to Reproduce:
1.Install base fedora core 4 system
2.Install xen programs and kernels, disable any unneeded services:-
portmap
pcmcia
nfslock
rpcgssd
rpcsvcgssd
rpcidmapd
gpm
cups
3.Set up custom firewall with a default policy of drop and let only the traffic i want through in...which works fine until xend is started and the bridge created. Then ip_conntrack stops recognising packets that are ESTABLISHED,RELATED.

Actual Results:  The state machine of the firewall stops tracking(or recognising).

Expected Results:  It should have recognised the packet as related to an already accepted SYN packet and let it through the OUTPUT chain.

Additional info:
Comment 1 Paul Jakma 2005-06-27 12:46:55 EDT
This bug and #161792 duplicate each other.

We'd discussed this on xen-users, seems we both went of and opened the FC bug at
almost exact same time ;).
Comment 2 jonny.fahrenheit451 2005-08-18 14:43:00 EDT
(In reply to comment #1)
> This bug and #161792 duplicate each other.
> 
> We'd discussed this on xen-users, seems we both went of and opened the FC bug at
> almost exact same time ;).
> 
I'm going to flag this problem for me as solved. Sorry I haven't replied before
now but my workload has been heavy lately!
   I found that the 2.6.12-1.1398_FC4xen0 kernel sorted out my problems as far
as matching related/established traffic. After that update everything went
swimmingly. I'll post a comment on bug 161792 as well.