Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 2917 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

source/destination interfaces in packet filter rules

jfitzell
Hi all,

We're using ASL v5 and there doesn't seem to be any way to specify firewall rules in terms of source or destination interfaces.

This means that there is no way of saying "Allow all traffic from my internal networks to the internet".  The best I can do is "Allow ALL from INTERNAL_NETWORKS to ALL" which gives all the internal machines access to everything in the DMZ as well.

Now, I can get around this by adding rules saying "DENY ALL from INTERNAL_NETWORKS to DMZ" but then the placement of that rule becomes critical as I can no longer rely on the default drop policy (I can otherwise rely entirely on ALLOW rules in my ruleset) and the whole ruleset becomes more fragile as a result.

Am I just missing the way you would define such a rule?  Or has this feature been added in v6?  Or is it planned?  I use it quite a bit when writing iptables rulesets directly.

Thanks,

Julian


This thread was automatically locked due to age.
  • 0
    ...in v6 you can use policy based routing where you can choose source interface and define next hop

    ASL Knowledgebase #166241 -> http://portal.knowledgebase.net/article.asp?article=166241&p=5956

    cu
     Claus
  • 0 in reply to ClausP
    Hm... I don't quite see how that solves the issue at and, though it does seem useful.

    Say I want to allow HTTP traffic from my internal interface to any destination on the internet.  I also want to allow HTTP from my admin subnet (on the internal interface) to a particular box in my DMZ.

    If I was using IPTABLES directly, I could define one rule allowing all traffic on port 80 from eth1 to eth0.  Then I could allow all traffic on port 80 from my admin subnet to whatever IP I wanted open in the DMZ.

    As it currently stands, I have to define the outgoing rule in terms of all my internal subnets. I also have to add another rule denying traffic on port 80  from the internal subnets to the DMZ subnet and make sure the rules are all in the right order.  Not the end of the world, perhaps, but IPTABLES already provides a way for me to express my rules exactly as I would describe them in english - ASL just isn't providing the interface to that, which is a shame.

    Reading over that KB article, I can't quite see that it solves the problem, does it?  I mean, the default routes are already going to know how to find each of the destination machines, right? ... the only issue is whether the packets should be allowed to get there.

    Julian
  • 0 in reply to jfitzell
    Are you coming from BSD Firewall? ;-)

    Yes IPTables can use the interface command in filter. But for usability you hardly use them. 
    If you have multiple networks then you normaly have 3 blocks of filters.

    1. block:  Allow those who have a fixed source and target (not any)
    2. block: Deny all internal (from internal_networks to internal_networks drop)
    3. block: Allow all those services, with unknown destinations (target any)
  • 0 in reply to NimmdirKeks
    Are you coming from BSD Firewall? ;-)


    [:D]  No... just linux firewalls without these fanshy shmantsy GUI frontends on them...

    Yes IPTables can use the interface command in filter. But for usability you hardly use them. 
    If you have multiple networks then you normaly have 3 blocks of filters.

    1. block:  Allow those who have a fixed source and target (not any)
    2. block: Deny all internal (from internal_networks to internal_networks drop)
    3. block: Allow all those services, with unknown destinations (target any)


    Ok, that's certainly another way of looking at it, I suppose.  I don't see why that's preferable to having the default DROP rule drop everything I don't want to specifically allow though.  I mean why is it better to define all the places that people can't go and then tell them they can go anywhere else.  Why not just tell them where they can go?  (I guess I've got enough BSD in my to shudder when I see the words ALLOW and ALL and DESTINATION in the same firewall rule [:)] )

    Julian
  • 0 in reply to jfitzell
    Hm... I don't quite see how that solves the issue at and, though it does seem useful.

    Say I want to allow HTTP traffic from my internal interface to any destination on the internet.  I also want to allow HTTP from my admin subnet (on the internal interface) to a particular box in my DMZ.
    ....


    Sure it would solve this issue. :-)

    1st policy route: admin subnet on internal if -> nexthop internal if
    2nd policy route: anything else on internal if -> nexthop external if

    ...and no more blocking rule.

    cu
      Claus
  • 0 in reply to ClausP
    Assuming the admin network never has to access anything on the internet (or at least nothing on the individual service ports you route through).  And assuming that the internal network doesn't have to get at port 80 (in this case) on some other box in the DMZ.

    And if I have to add two routing rules in addition to my ALLOW rules, that's not a whole lot better than having to add the DENY rules in terms of management.

    I feel like I'm still missing something... are you actually suggesting this is /better/ in some way than being able to use the interfaces in the packet filter rules or just that, in your opinion, there are several work-arounds that are good enough?

    Julian