[Firehol-support] Unsubscribe

David Welch tenfishsticks at gmail.com
Wed Jan 14 16:39:21 CET 2015


Graduate Student
Dept. of Orthopaedics and Rehabilitation
Dept. of Biomedical Engineering
University of Iowa

On Wed, Jan 14, 2015 at 3:33 AM, Phineas Gage <phineas919 at gmail.com> wrote:

> Thanks Phil for looking at this. I could do some testing on my config when
> I get the time if you put something that uses ebtables.
>
> Right now I rely on my external ADSL modem’s firewall to stop traffic from
> reaching my bridging firewall’s external interface, but it would be nice to
> lock it down more and allow traffic for some services only on the internal
> interface. I’m considering putting an ADSL adapter right on my firewall,
> instead of using the external modem, but right now I wouldn’t do that with
> the bridge config because of the limitations on what rules are possible.
>
> Phineas
>
> > On Jan 11, 2015, at 11:33 AM, Phil Whineray <phil at sanewall.org> wrote:
> >
> > Hi
> >
> > On Thu, Dec 04, 2014 at 09:51:50AM +0100, Phineas Gage wrote:
> >>> On Dec 4, 2014, at 1:11 AM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
> >>> I guess the error message says it all: using --physdev-out in the
> >>> OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not
> >>> supported anymore.
> >
> > I've been doing some research on this and now have a setup which
> > shows what is currently (not) possible.
> >
> > I have created a setup, this is a simplified view:
> >
> >            ppp0 = wan
> >             |
> >            FW1
> >             |
> > eth0 -------+------- wlan0
> >  = wired   br0        = wifi
> >            lan
> >
> > Below I've created an example firehol.conf. The 'lan2wifi' router works
> > as expected and the 'lan' interface shows up the problem originally
> > reported by Phineas.  N.B. Disable fast activation to see the actual
> > with physout matching.
> >
> > In essence, this is the situation...
> >
> > iptables alone allows us to control the following:
> >   1. route between interfaces ppp0 and br0
> >   2. bridge traversing br0 to/from physical devices eth0/wlan0
> >   3. FW1 incoming from ppp0, br0, eth0 and wlan0
> >   4. FW1 outgoing to ppp0, br0
> >
> > We cannot directly control outout to eth0 or wlan0, the bridged devices:
> >   1. routing from input ppp0 to physical output eth0 or wlan0
> >   2. packets from local host to physical output eth0 or wlan0
> >
> > This is because the information needed is not present when the decision
> > will be made. Netfilter knows that it will send to br0 but not which
> > specific interface.
> >
> > Since we are creating stateful rules, I think it might be OK to just
> > use the physin part? It is the firehol logic which reverses this to
> > create the physout but provided the original SYN is matched with physin,
> > physout is only really double-checking something that is already known.
> >
> > I have not put any rules to try to distinguish wired from wifi in the
> > 'lan2wan' router: this has the same problem. It is possible to know
> > in iptables the physin device for traffic starting on the lan, but not
> > which will be chosen on the reverse journey or for connections initiated
> > from the wan.
> >
> > We might want to disable or warn about physout on firehol interfaces
> > before the rules gets to iptables. I don't suppose we can know if the
> > device in a router is part of a bridge, so we cannot help that.
> >
> > If we want actual matching on physout, I believe we will need to involve
> > ebtables. Output traffic for the rule is MARKed, then the logic completed
> > with ebtables to combine the mark plus knowledge of the physical output
> > interface:
> >
> http://serverfault.com/questions/607224/iptables-matching-packets-for-bridged-interface
> >
> > Not sure how much time I have but I will try to put some actual code
> > ideas forward before too long: since it is my home network I have now
> > organised like this, there is an incentive to make it work...
> >
> > Cheers
> > Phil
> >
> > --- SNIP ---
> > version 6
> >
> > interface ppp+ wan
> >       protection strong
> >       policy deny
> >
> >       client all accept
> >       server ping accept
> >
> >       server ipv6error accept
> >       client ipv6neigh accept
> >       server ipv6neigh accept
> >       client ipv6router accept
> >       server ipv6router accept
> >
> >
> > interface br0 lan
> >       policy reject
> >
> >       client all accept
> >
> >       server "dhcp dns" accept
> >
> >       # Access to router only over wired
> >       server ssh accept physin eth0
> >
> >       server ipv6error accept
> >       client ipv6neigh accept
> >       server ipv6neigh accept
> >       client ipv6router accept
> >       server ipv6router accept
> >
> > router lan2wan inface eth0 outface ppp+
> >       # route all outgoing traffic
> >       route all accept
> >       route ipv6error accept
> >
> >       # client in a router is the incoming traffic
> >       client ping accept
> >
> > router wired2wifi physin eth0 physout wlan0
> >       # route all outgoing traffic
> >       # no restrictions from wired to wireless
> >       route all accept
> >       route ipv6error accept
> >
> >       # client in a router is the incoming traffic
> >       # accept limited incoming from wireless to wired
> >       client ping accept
> >       client ssh accept
> > --- SNIP ---
> > _______________________________________________
> > Firehol-support mailing list
> > Firehol-support at lists.firehol.org
> > http://lists.firehol.org/mailman/listinfo/firehol-support
>
> _______________________________________________
> Firehol-support mailing list
> Firehol-support at lists.firehol.org
> http://lists.firehol.org/mailman/listinfo/firehol-support


More information about the Firehol-support mailing list