[Firehol-support] message from xt_physdev when running firehol in bridge configuration

Tsaousis, Costa costa at tsaousis.gr
Thu Dec 4 00:11:22 GMT 2014


Well,

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.

This is reported by the kernel. I cannot do much about it, other than accept it.

This means you can only use physin/physout on traffic bridged (i.e.
passing from one ethernet port to another - not on traffic comming in
from a bridged interface toward the linux box, or from the linux box
to another host via a bridged interface).

If you can find an alternative way using plain iptables commands, I
could try to add support for them in firehol.

Regards,

Costa


On Wed, Dec 3, 2014 at 6:14 PM, Phineas Gage <phineas919 at gmail.com> wrote:
> Hi Costa,
>
> Just getting to testing this more (with firehol-master-6c005c3), and I’m
> trying to create servers that only accept on a certain physical interface,
> but haven’t gotten that working yet. For example, here's a simplified
> version of an interface to try to accept the openvpn service on the external
> interface, and a few services on the internal interface (following the
> example on
> http://firehol.org/firehol-manual/firehol-params/#firehol-params5):
>
> interface46 br0 bridge
>     server openvpn accept physin eth1
>     server "dns ssh icmp" accept physin eth0
>     client all accept
>     server all reject
>
> But I get error messages like this (similar ones follow for other services):
>
> ERROR   : # 1.
> WHAT    : A runtime command failed to execute (returned error 1).
> SOURCE  : line 56 of /etc/firehol/firehol.conf
> COMMAND : /sbin/iptables -t filter -A out_bridge_openvpn_s4 -m physdev
> --physdev-is-out --physdev-out eth1 -p tcp --sport 1194 --dport 1024:65535
> -m conntrack --ctstate ESTABLISHED -j ACCEPT
> OUTPUT  :
>
> iptables: Invalid argument. Run `dmesg' for more information.
>
> And the dmesg output:
>
> xt_physdev: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING
> chains for non-bridged traffic is not supported anymore.
>
> I suppose this should work for servers, and clients as well?
>
> thanks,
> Phineas
>
> On Nov 19, 2014, at 11:47 AM, Phineas Gage <phineas919 at gmail.com> wrote:
>
> Thanks Costa, that does stop the warning messages for me. Now I’m verifying
> everything works as expected, but I’m still trying to figure out the right
> way to specify rules for bridges. My setup is:
>
> eth0 <> br0 <> eth1
>
> My questions are:
>
> 1) In this case, I should not need interface definitions for eth0 and eth1
> right? Neither has an IP address, since they’re bridged, and adding
> interface definitions for them doesn't seem to do anything.
>
> 2) For interface definitions for bridges, when I have:
>
> interface46 br0 bridge
>   # Rules for clients and servers in and out of br0 go here, and are
> working, but how do I add rules that should ONLY work on eth1 or eth0?
>   # Do I specify two interfaces, for example: "interface46 br0 bridgeout
> physin eth0 physout eth1” and "interface46 br0 bridgein physin eth1 physout
> eth0”?
>   # And in that case do I still need “interface46 br0 bridge”? I locked
> myself out of my firewall a couple of times so it might be easier to ask
> what’s right.
>
> Phineas
>
> On Nov 19, 2014, at 1:01 AM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
>
> Hi all,
>
> I just pushed a version of firehol that adds these:
>
> --physdev-is-bridged in routers
> --physdev-is-in at the input of interfaces
> --physdev-is-out at the output of interfaces
>
> I verified it generates the proper statements for both interfaces and
> routers.
> I can't check if it works though. Please check it and let us know.
>
> There is one issue with helpers (NAT, marks, etc). In that case, it
> will assume --physdev-is-bridged only if both physin and physout are
> given to the firehol statement. Otherwise, it will use --physdev-is-in
> for physin and --physdev-is-out for physout. I am not sure if this has
> any implications. This might be an issue in rare cases (example:
> marking packets routed, using just physin), but I can't think of an
> easy fix now. So, if you need physin/physout in helpers (statements
> before interfaces and routers), please report a few use cases to help
> us figure out how to solve it.
>
> Thanks.
>
> Costa
>
>
> On Wed, Nov 19, 2014 at 1:24 AM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
>
> Hi JT.
>
> Thanks for the tip.
> New options available:
>
> physdev match options:
> [!] --physdev-in inputname[+]          bridge port name ([+] for wildcard)
> [!] --physdev-out outputname[+]        bridge port name ([+] for wildcard)
> [!] --physdev-is-in                    arrived on a bridge device
> [!] --physdev-is-out                   will leave on a bridge device
> [!] --physdev-is-bridged               it's a bridged packet
>
> In your example you have used --physdev-is-bridged
> As I understand it, we have to use:
>
> --physdev-is-bridged in routers
> --physdev-is-in at the input of interfaces
> --physdev-is-out at the output of interfaces
>
> Since I cannot test it, I need your help to figure this out.
> Do you agree?
>
> Costa
>
>
>
> On Tue, Nov 18, 2014 at 9:26 PM, JT <admin at jtlabs.net> wrote:
>
> I'm having the same problem using bridged traffic. My resolution has
> been to write my own manual iptables entries in firehol.conf.
>
> vif+  <> br0 <> br1<> eth1
>         /\
>         \/
>        eth0
>
> br0 and br1 have physical address associated with them (eth0/vif+ and
> eth1 respectively). Whenever I try to route or create interface rules
> with a physout/physin I get the syslog message (even though it is
> bridged traffic). Please let me know if it's user error.
>
> For example, firehol.conf has:
> router vm2inet inface vif+ outface br0 physout eth0
>   route all               accept
>
> which generates:
> "xt_physdev: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING
> chains for non-bridged traffic is not supported anymore."
>
> instead I use:
> iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in vif+
> --physdev-out eth0 -j ACCEPT
>
> So far any combination of inface/outface/physin/physout generates the
> message. Let me know what other information I can provide.
>
> Thanks,
>
> JT
>
> On 11/18/2014 9:12 AM, Tsaousis, Costa wrote:
>
> Hi Phineas,
>
> Can you trace it down?  Are you using physin/out on non-bridged traffic
> only?
> Try to run a few commands by hand to check which ones complain.
>
> Regards,
>
> Costa
>
>
>
> On Tue, Nov 18, 2014 at 3:59 PM, Phineas Gage <phineas919 at gmail.com> wrote:
>
> Hi,
>
> I’m getting this message many times in my syslog when running firehol:
>
> xt_physdev: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING
> chains for non-bridged traffic is not supported anymore.
>
> This happens only when I use either the ‘physin’ or ‘physout’ keywords on
> either my router definitions or route subcommands for the br0 (bridge)
> interface. If I omit those keywords it doesn’t happen. Can I still use
> ‘physin’ and ‘physout’ with my bridge somehow? They’re useful for knowing
> which direction the traffic is going through the bridge...
>
> Phineas
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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