#291 Interface used as a destination includes IP's of VLANs

open-rejected
None
1
2011-09-19
2011-09-19
Roland Pope
No

I am using fwbuilder 5.0.0.3568 under Fedora Core 15 deploying IPtables rules to CentOS 5.6 (Iptables 1.3).
If I use an Ethernet interface as a destination in either a NAT or a filter rule, and that Ethernet has vlan sub Interfaces, the generated rule uses all the IP's off the vlans as well as the Ethernet IP's. This behaviour is wrong in my opinion as only the Ethernet Interface IP's should be showing up in the Generated rules as VLAN's are independent, and usually unrelated networks.

Discussion

  • Vadim Kurland

    Vadim Kurland - 2011-09-19
    • priority: 5 --> 1
    • assigned_to: nobody --> vkurland
    • status: open --> open-rejected
     
  • Vadim Kurland

    Vadim Kurland - 2011-09-19

    you should be using address object of the interface Ethernet in this situation instead of the interface object. Fwbuilder explicitly always uses all ip addresses of a container object by scanning all its children, be that a host/firewall or an interface. This behavior is more predictable than if it sometimes skipped some of the children objects.

     
  • Roland Pope

    Roland Pope - 2011-09-19

    I can see your point, however, the reason for dropping an Interface object into a rule set is often to reduce the number of ip address objects in the rule in the GUI, and also to allow addresses to be added added to and deleted from the interface and have them picked up automatically by any rules.
    I re-iterate what I said before, that VLAN networks are almost always completely unrelated to their parent Ethernet interface, and as a result, should not be included as part of a rule expansion. I can't think of a case where I would want the current behaviour and the reason I reported it as a bug was because it seemed unusual and unexpected.
    Maybe as a compromise if you don't want to change the current behaviour, you would consider some sort of option to control this function?

     
  • Vadim Kurland

    Vadim Kurland - 2011-09-20

    I undersand you, in this particular case children objects (vlan subinterfaces) are unrelated, but I believe behavior of the tool should be consistent. Recommended method is to place ip addresses of the interface in the rule if you do not want addresses of all subinetrfaces there.

    Configuration when parent interface has so many ip addresses that proposed workaround becomes impractical is rather unusual, a kind of a corner case, and I do not think we should optimize for it.

     
  • Roland Pope

    Roland Pope - 2011-09-20

    I understand, Can I perhaps make one other suggestion. In this case, if I could declare an untagged VLAN interface in firewall builder, I could work around the problem, as that is essentially what the parent Ethernet interface is. I could then use this untagged vlan interface object instead of the Ethernet Super-Object.
    This would be even more consistent with the overall design as in reality on a Linux machine at least, Untagged vlan interfaces are not really the Parent of VLAN's, they are just another Interface related only by the fact that they are using the same physical NIC.

     
  • Vadim Kurland

    Vadim Kurland - 2011-09-20

    this sounds good, lets explore this idea.

    What name should this untagged interface object have ? I guess what you mean is that it would become another child object under the parent Ethernet interface, but then it needs a name. One of the guiding principles in fwbuilder is that inetrface names must match real interfaces on the firewall and I'd like to keep it in this case.

    How does this configuration look like on the firewall machine ? Does the untagged interface appear to be a separate interface from the parent ethernet ?

    How do you configure this untagged interface in Linux ? Remember that fwbuilder should be able to configure interfaces so I need the command for that.

     
  • Roland Pope

    Roland Pope - 2011-09-20

    Under Linux, untagged packets are presented to the raw Ethernet interface. So in essence, an untagged VLAN interface is the same as an interface with no vlans configured.

     
  • Vadim Kurland

    Vadim Kurland - 2011-09-20

    then it is unclear how to represent this in fwbuilder using existing interface/subinterface model

     
  • Roland Pope

    Roland Pope - 2011-09-20

    Not really. What you are doing is creating a Parent interface of say "eth0", which controls the naming and inheritance of the VlAN Interfaces. If you then want to add ip addresses to an untagged VLAN interface, you create a sub interface with a vlan of zero. In essence , once you have done this it will mean that you would not declare IP's against say 'eth0' as a parent. So you create an eth0.0 vlan sub interface in firewall builder that is created purely as a raw eth0 on the host (with the vlan number dropped as it is superfluous) . What you may need to do is have a check that says "If you have a vlan0 sub interface declared then IP's need to be added to this, not the parent".

     
  • Vadim Kurland

    Vadim Kurland - 2011-09-20

    I see what you mean, vlan id "0" is reserved so certainly eth0.0 can not be a valid vlan interface. The way it is going to look in fwbuilder will be different from how it looks like on the machine, but this might work. I'll file a feature request.

     
  • Roland Pope

    Roland Pope - 2011-12-27

    I see this feature request has been rejected. May I please ask why as it would seem to me to be a good idea to have a way in firewall builder to use all of a native vlan interface's IP's, without including sub VLAN interfaces too?

     
  • Vadim Kurland

    Vadim Kurland - 2011-12-27

    I agree something needs to be done to make it possible to deal with untagged vlan interfaces but treating eth0.0 in a special way as you propose is not the best way. It makes behavior of the program rather unexpected - vlan interface eth0.0 looks just like any other vlan interface in the GUI but generated script does something different for it just because vlan number is "0".

    Note also that on Cisco untagged interface ("native vlan" in their terminology) is by default vlan 1. Fwbuilder is a multi-platform application and we try to find solutions that work for all platforms we support.

    I would prefer more explicit setting, may be a checkbox or something, that clearly marks this subinterface as an untagged vlan interface. Program behavior then should be clearly defined in this situation

     
  • Roland Pope

    Roland Pope - 2011-12-27

    Thanks for your response. I am happy with an option or explicit setting. I understand the issues around dealing with multiple platforms and you are probably the best judge of how to implement this. I guess from my side of things, I was surprised by the current behaviour and was looking for a way to avoid it. In essence I would like a way to use just the raw Ethernet interface and it's IPs in rules when it has VLAN's defined, how this is implemented would be up to you.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks