brouting on interfaces without IP address

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux