Linux Netfilter discussions
 help / color / mirror / Atom feed
From: tom@tomdeb.org
To: netfilter@lists.netfilter.org
Subject: tunnel, bridge and iptables on linux 2.6
Date: Mon, 22 May 2006 09:49:37 +0100	[thread overview]
Message-ID: <20060522084937.GA16002@snoopy> (raw)

Hi,

We ve got an IPSEC / GRE tunnel on one of our perimeter firewall and
it eventuallly worked fine after quite a lot of trial and error.

The tunnel (tunnel0) is on top of a bridge (br0). which groups internal and external
interfaces eth0 and eth1.

When trying to adapt the firewall to the new tunnel, I noticed some
inconsistencies in the packet sequencing. When I ping through the VPN,
here is how iptables sees the traffic:

| 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
 
This echo request is sent through br0 whereas the echo reply is received
through tunnel0.

tcpdump sees traffic on both virtual interfaces:
 
on 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
 
on 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

This is entirely reproducible and it prevents me from configuring my
firewall accordingly. For eample, I can't drop INVALID packets as the
replies are not considered as part of any tracked connections for
iptables.

Any help or idea would be greatly appreciated.

Tom
tom@tomdeb.org

PS: I am using Openswan 2.4.4 on linux 2.6.9-34.EL from CentOS 4.3


                 reply	other threads:[~2006-05-22  8:49 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060522084937.GA16002@snoopy \
    --to=tom@tomdeb.org \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox