Guest User!

You are not Sophos Staff.

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

Why no PPPoE yet?

Ok,

I'm finally in a position where I really do need some of the features of astaro and can't get by with lesser devices.  The concept of looping through an external PPPoE termination device annoys me.  Could someone from Astaro please officially comment on why integrating PPPoE is proving to be so difficult?  If it can be implemented on every os under the sun, why is it so hard to integrate into a custom system that you control?
Thanks.


This thread was automatically locked due to age.
Parents
  • hi Myrcurial,

     
    quote:

    Could someone from Astaro please officially comment on why integrating PPPoE is proving to be so difficult? If it can be implemented on every os under the sun, why is it so hard to integrate into a custom system that you control?



    If supporting it would only mean to provide the ready-to-run binaries and an rc script, we'd have it "supported" in 20 minutes.

    When we support something, we want the feature to "fit" into the whole system (if possible). This is not trivial.

    I'll give you a few examples:

    - Dynamic IPs. Firewall and DNAT rules must be rewritten on the fly if the interface IP changes. Some services must be HUPed or restarted to notice the new interface (SOCKS is very picky here ...). Accounting may also need to "know" about the new IP address ... etc etc.

    - Disappearing Interfaces. ppp0 just went away due to "provider error". Oooops, sockd and nacctd didn't quite like that and died too. Or, even more funny, ppp0 is still there but does not carry data any more. We need to detect such cases and the middleware must act accordingly. When you are only dealing with eth interfaces, life is easy  [:)]

    - Proper WebAdmin integration. We must add an abstration scheme for interfaces, where you can have logical interfaces which are not assigned directly to any hardware. These will also include normal virtual interfaces, to support them better as it is now.

    ASL was initially designed for eth interfaces only (a "pure" firewall, without router functionality). We are commited to extend ASL on customer demand, but it's not as easy as doing a "./configure; make; make install".  

    Other "firewalls" (which are more like dialup masqerading routers with a packet filter) have it far easier ..

    /tom
  • Ok,

    I was just making sure that it was a 'real' reason and not a knee-jerk reaction.  For
    now, I think I'm going to build a sandwich
    and just deal with the configuration issues
    that will result.  Not thrilling, but I can get over it.  I agree that abstraction of interfaces is a long term goal you should be looking at - Gauntlet 6 does that very well, especially with 'meta-rules' that have variable meaning depending on which firewall they're installed on.  Possibly a configuration guide that shows how to build a router/firewall sandwich with RFC-1918 space in the crossed ether would be a good idea - yes it requires two boxes, but the other box can be something as simple as bbi-agent running on a p90 or a simple Linksys type dsl router.
Reply
  • Ok,

    I was just making sure that it was a 'real' reason and not a knee-jerk reaction.  For
    now, I think I'm going to build a sandwich
    and just deal with the configuration issues
    that will result.  Not thrilling, but I can get over it.  I agree that abstraction of interfaces is a long term goal you should be looking at - Gauntlet 6 does that very well, especially with 'meta-rules' that have variable meaning depending on which firewall they're installed on.  Possibly a configuration guide that shows how to build a router/firewall sandwich with RFC-1918 space in the crossed ether would be a good idea - yes it requires two boxes, but the other box can be something as simple as bbi-agent running on a p90 or a simple Linksys type dsl router.
Children
No Data