All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net>
To: lartc@vger.kernel.org
Subject: [LARTC] brouting on interfaces without IP address
Date: Thu, 13 Oct 2005 21:55:12 +0000	[thread overview]
Message-ID: <434ED7C0.2000109@gmx.net> (raw)

Hi,

[sorry for the crosspost, I don't know whether this is a routing or 
ebtables problem]
I want to redirect all HTTP traffic passing through my bridge to a squid 
proxy on another machine. However, setting up brouting as suggested in 
the ebtables examples doesn't work and the packets get dropped on the 
floor completely.

  /\/\/\/\/\/\/\/\      +----------------------+    +-------------+
/       LAN      \-----|bridgeint    bridgeext|----|    Router   |
\ 192.168.0.0/24 /     |                      |    |(192.168.0.1)|
  \/\/\/\/\/\/\/\/      |  eth0(192.168.0.5)   |    +-------------+
         |              +----------------------+
         |                   |
         |                   |
         |            +--------------------+    +----------------+
         \------------| Proxy(192.168.0.4) |----| Another Router |
                      +--------------------+    +----------------+

Packet flow for unredirected traffic:
   LAN <-> bridgeint <-> bridgeext <-> Router <-> Internet

Packet flow (assymetric) for redirected traffic:
   LAN -> bridgeint -> eth0 -> Proxy -> Another Router -> Internet
   LAN <- Proxy <- Another Router <- Internet

However, once I insert the ebtables rule to actually do the redirection, 
all packets I want to redirect get dropped. This happens regardless of 
where I try to broute the packets. I tried DROPping them in BROUTING, 
REDIRECTing them in PREROUTING, DNATing them to the MAC of eth0 in 
PREROUTING, but each time the packets never leave eth0.

All debugging so far hasn't helped (I read the LARTC HowTo twice, read 
all ebtables/bridge/iproute2 documentation I could find), the only 
remaining possible explanation I can think of is that the kernel routing 
code drops packets entering on devices which have no IP address attached.
Is that true?


To make sure the bridge doesn't accidentally answer to packets running 
through it, the bridge device (bridge) and its enslaved ethernet 
interfaces (bridgeext and bridgeint) have no IP address assigned to 
them. The bridge has an additional ethernet interface (eth0) which 
handles all traffic going directly to the bridge.

bridge:~ # ip a l
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
     inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
     link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
     inet 192.168.0.5/24 brd 192.168.0.255 scope global eth1
        valid_lft forever preferred_lft forever
3: bridgeext: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000
     link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff
4: bridgeint: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 1000
     link/ether 00:06:07:08:09:0a brd ff:ff:ff:ff:ff:ff
5: bridge: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
     link/ether 00:01:02:03:04:05 brd ff:ff:ff:ff:ff:ff

bridge:~ # brctl show
bridge name     bridge id               STP enabled     interfaces
bridge          8000.000102030405       no              bridgeint
                                                         bridgeext

bridge:~ # ebtables -t nat -L --Lx
ebtables -t nat -N ifacefilter-int
ebtables -t nat -N proxy
ebtables -t nat -A PREROUTING -i bridgeint -j ifacefilter-int
ebtables -t nat -A ifacefilter-int -p IPv4 --ip-src 192.168.0.0/24 
--ip-proto tcp --ip-dport 80 -j proxy
ebtables -t nat -A proxy -j mark --set-mark 0x1 --mark-target CONTINUE
ebtables -t nat -A proxy -j dnat --to-dst 00:11:22:33:44:55 
--dnat-target ACCEPT

bridge:~ # ip ru l
0:      from all lookup local
32765:  from all fwmark 0x1 lookup proxy
32766:  from all lookup main
32767:  from all lookup default

bridge:~ # ip r l table proxy
default via 192.168.0.4 dev eth0

bridge:~ # cat /proc/sys/net/ipv4/ip_forward
1

bridge:~ # uname -a
Linux bridge 2.6.11.7-secpatched #3 Fri Oct 8 04:19:31 CEST 2005 x86_64 
x86_64 x86_64 GNU/Linux


Thanks for any help,
Carl-Daniel
-- 
http://www.hailfinger.org/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

                 reply	other threads:[~2005-10-13 21:55 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=434ED7C0.2000109@gmx.net \
    --to=c-d.hailfinger.devel.2005@gmx.net \
    --cc=lartc@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.