[Bug 479] New: tunnel0 and br0

[bugzilla-daemon at bugzilla.netfilter.org]

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=479

           Summary: tunnel0 and br0
           Product: iptables
           Version: 1.2.11
          Platform: i386
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: iptables
        AssignedTo: laforge at netfilter.org
        ReportedBy: tom at tomdeb.org


I have a ipsec tunnel (tunnel0) configured on top of a bridge (br0).

Everything works fine but when I try to create firewall rules base on traffic
that should go through tunnel0, the rule is not match.

I have activated LOG for this particular issue and here is how the traffic is
percieved by iptables :

IN=br0 OUT=br0 PHYSIN=eth0 PHYSOUT=eth1 SRC=10.35.8.46 DST=10.10.30.251 LEN=84
TOS=0x00 PREC=0x00 TTL=61 ID=1 DF PROTO=ICMP TYPE=8 CODE=0 ID=61218 SEQ=1
IN=br0 OUT=tunnel0 PHYSIN=eth1 SRC=10.10.30.251 DST=10.35.8.46 LEN=84 TOS=0x00
PREC=0x00 TTL=62 ID=26665 PROTO=ICMP TYPE=0 CODE=0 ID=61218 SEQ=1

traffic in is seen on tunnel0 whereas traffic out is seen on br0.

tcpdump, though, gives me the correct information : 

tunnel0:
listening on tunnel0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
14:20:30.077337 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 0
14:20:30.092054 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 0
14:20:31.081619 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 1
14:20:31.102690 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 1
14:20:32.085657 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 2
14:20:32.303333 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 2
14:20:33.089717 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 3
14:20:33.104178 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 3
14:20:34.095934 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 4
14:20:34.110300 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 4
14:20:35.097811 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 5
14:20:35.112194 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 5
 
br0 :
listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
14:20:46.331785 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 0
14:20:46.346100 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 0
14:20:47.341446 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 1
14:20:47.355848 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 1
14:20:48.342419 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 2
14:20:48.357181 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 2
14:20:49.346497 IP 10.10.30.251 > 10.35.8.46: icmp 64: echo request seq 3
14:20:49.361480 IP 10.35.8.46 > 10.10.30.251: icmp 64: echo reply seq 3

As the traffic is flowwing as it should and with the information from tcpdump, i
don't think the problem comes from openswan which is the VPN software used here.

I think the problem relies in the superposition of virtual interface : tunnel0
on top of br0.

-- 
Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.