Re: SRC MAC address masking for on-bridge service communications
Bart De Schuymer <[email protected]> Wed, 04 Apr 2007 21:25:08 +0200
| Newsgroups | gmane.linux.network.bridge.ebtables.user |
|---|---|
| Message-ID | <[email protected]> |
Op di, 03-04-2007 te 23:00 -0700, schreef Jonothan Kane: > On 4/1/07, Bart De Schuymer <[email protected]> wrote: > > Op za, 31-03-2007 te 11:57 -0800, schreef Jonothan Kane: > > > Greetings; > > > > > > I'm trying to setup a completely transparent brouting firewall/bridge. > > > Since I'm proxying a protocol with a userspace server, I've had to setup > > > a BRouting firewall/bridge. Much akin to a brouted squid proxy setup. > > > > > > My problem is that the Machine currently exposes it's MAC address as the > > > SRC MAC for any communication that flows through the userspace proxy service. > > > > > > 192.168.2.0/24 > > > Internal Network > > > | > > > | > > > | _____________________________________ > > > | | Bridge/Firewall Machine | > > > | | ____ Proxy ____ | > > > | | | Service | | > > > | | ________| |_______ | > > > | | | | | > > > | | | | | > > > | | / \ | > > > |_|/_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ \|__ > > > A |____________________________________|B | > > > | > > > ___________| > > > | > > > 10.0.0.0/24 > > > External Network > > > > > > Is there a way to setup the system up such that all traffic to/from > > > the machine has no MAC addresses associated with the machine? > > > ie The bridges MACs remain hidden ? > > > > I don't think that's easy to implement in ebtables purely based on the > > Ethernet header, but it's probably doable on a protocol base. > > Does the bridge have an IP address? How do you keep the IP source > > address different from the bridge's IP address? > > Can't you construct the complete packet (including Ethernet header) in > > userspace and send it out on the right interface (perhaps br0)? > > > > cheers, > > Bart > > Greetings Bart; > > I've got a network that is very sensitive to system changes. > Packets with bad checksums have been known to knock some of the device > on the network out ... thus the desire to deploy a firewall/filter > that protect against it that sort of traffic as well as filtering > higher level protocols. > > Some of the protocols on the network require user-space proxying to filter well. > As such it was suggested that I setup a transparent proxy system for filtering > that is transparent right down to the MAC layer. > > What I've got right now: > I've got a 2NIC (eth0, eth1) transparent bridge with a 3rd NIC (eth2) > for remote management; > The network I'm deploying on 192.168.2.0/24; > > System setup: > The bridge interface is up with a trivial address; 1.1.1.1. > For the protocol services that I'm user space proxying; > I'm using REDIRECT in iptables to get incomming traffic re:routed to 1.1.1.1 > I've got a service that can insert MAC SNAT in ebtables nat > POSTROUTING to try and mask the firewall's MAC address ... > > The problem: > With the re:routed traffic the proxy's traffic gets the corresponding > reverse NAT of the REDIRECT ... but this occurs after the transition > of the ebtables nat POSTROUTING chain ... While in the ebtables nat > postrouting chain ... all my proxy traffic still has address 1.1.1.1 > ... if I'd access to the reverse "Nat'ed" ip at that point (ie the > original target IP) ... I could SNAT the MAC address properly. > > Several machines running the same protocol ... and would like to > construct a proxy that can filter all of them ... Currently; my MAC > SNAT limits the proxying to one machine only. > > Analysis: > Solution1: If I can somehow match on the IP that results form the > reverseNAT of the redirect ... in the ebtables nat POSTROUTING ... I > can SNAT the MACs there. > Solution2: Move my SNAT of the MACs from ebtables to after the > reverseNAT of the redirect ... ie down the line from the iptables nat > POSTROUTING table. > > Desired result: > A firewall system that I can run a proxy filter on that does alter MAC > address or ip address settings on the network in any way. With some > of these devices keeling over when bad checksum hit them ...... > suddent MAC address changes for devices could disturb some of the > networks processes. > > I'd take suggestions ... I've almost got a workable solution ... > > I've got the C skills to code custom extensions ... extra ... just not > the knowledge of ebtables to know what's available at each table/chain > point for me to play with. You should be able to get the ebtables nat POSTROUTING chain to be traversed both before and after the iptables snatting (you can then e.g. use the mark to figure out in which chain you are). You can also disable the default ebtables nat POSTROUTING chain. Just remove the NF_BR_POST_ROUTING entry in ebt_ops_nat in net/bridge/netfilter/ebtable_nat.c. Try something like this in the kernel source to get a chain behind the iptables snatting: At the end of net/ipv4/netfilter/ip_nat_standalone.c::ip_nat_out() add a call to net/bridge/netfilter/ebtable_nat.c::ebt_nat_dst(). Use hook number NF_BR_POST_ROUTING, just ignore the okfn. Good luck, Bart ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV