netdev - ebtables on a stick

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 27 Nov 2011 09:10:08 -0600
From:	"Greg Scott" <GregScott@...rasupport.com>
To:	<netdev@...r.kernel.org>
Subject: ebtables on a stick

I have a situation that needs to route mostly and bridge only a little bit.  

I have a private internal LAN, 192.168.10.nnn.  But one host in the internal side needs a real public IP Address, call it 1.2.115.157.  Everything except that public IP host needs to route.  The public host needs to bridge so it can interact with the world.  But it also needs to interact with the internal LAN.  

I have a Linux brouter set up with eth0 facing the Internet, eth1 facing the LAN as follows:

ifconfig eth0 1.2.115.146 mask 255.255.255.240
ifconfig eth1 192.168.10.1 mask 255.255.255.0
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ebtables -t broute -A BROUTING -p IPv4 --ip-source 1.2.115.157 -j ACCEPT
ebtables -t broute -A BROUTING -p IPv4 --ip-destination 1.2.115.157 -j ACCEPT
ebtables -t broute -A BROUTING -p arp --arp-ip-src 1.2.115.157 -j ACCEPT
ebtables -t broute -A BROUTING -p arp --arp-ip-dst 1.2.115.157 -j ACCEPT
ebtables -t broute -A BROUTING -j redirect --redirect-target DROP

This mostly works, except I am having trouble communicating with hosts in the private LAN.  I can communicate anywhere else on the Internet, just not in the private LAN.   After studying ebtables examples and tons of trial and error, I still don’t get it.  

When my public IP host pings the internal LAN, the internal LAN host replies, but the replies never get past the brouter.  Watching tcpdump from the firewall, I can see the echo request come in and go out on both br0 and eth1 and I see the echo reply come back on eth1.  But then the reply dies and I never send it back out eth1 over the wire.   And when a private host pings the public host, the echo request dies at the brouter.  So public --> private works, but private --> public including ICMP echo replies die at the brouter.  

I've tried various solutions such as "ip route add 1.2.115.157/32 via br0" without success.  What am I missing?

Thanks

- Greg Scott