Saturday, 29 January 2011

DHCPv6 and CISCO 877W

OK, lots of attempts got nowhere with this.

Finally, turning off fire-walls on the router, again, and it works.

This just highlights yet another reason DHCPv6 is wrong!
PPP is not subject to firewall rules!

We also have highlighted in the testing that DHCPv6 does prefix delegation with timings and not attached to the life of the PPP session (or at least till the next session starts). Another brokenness with using DHCPv6 rather than PPP IPV6CP...

P.S. Interesting - someone else using DHCPv6 (on linux) also hitting fire-walling rules meaning it did not work... Fundamental flaw here I think.

P.P.S Apparently DHCPv6 is not enough for the 877W - it does not set the gateway. It looks scarily like we may have to do RA as well. We'll test. Thankfully the consumer routers we have been looking at don't seem to need that. Extra mad.

6 comments:

  1. Firewall? Which version? Which commands?

    AFAICR acls do not affect router originated packets. Maybe it's rx packets being affected,

    ReplyDelete
  2. It is the reply, from a different IP and possibly even different port which does not get passed the firewall.

    ReplyDelete
  3. The only reason i didn't hit that is because the box I was running on is a simple router which runs nothing normally, hence no actual firewall.

    Of course if the reply could come from a different machine entirely you *can't* firewall it, and you're also somewhat open to external attack (although whether anyone could achieve anything more useful than a DoS that way is doubtful).

    ReplyDelete
  4. In the same way as DHCP (IPv4) works, the request is to a general address, and the reply from the specific machine that replies. So no, session tracking does not work. It makes it very hard to firewall, if not impossible.

    All the more reason for it to be at the PPP layer.

    ReplyDelete
  5. Hmm.

    I've currently got an 827, which I hope to replace with a 877 (non W) soon. But I'm not sure if this would actually be classed as a bug. I can see a way to argue it as such, and a way to argue it as not. i.e. the issue would seem to revolve around the question of if the firewall should act as configured, or if a pinhole should be automatically added.

    However I use manual config (not DHCP), since I can't see any way to delegate a /48 and then sensibly allocate it amongst the various internal subnets. But then, I have to admit to not investigating all of the command possibilites. I guess one come up with some means of indicating 'append this to the delegated prefix'. i.e. I've thought of prefix delegation as particularly useless except for the /64 scenario.

    I also run my ADSL router as a non firewall one, my firewall being at a subsequent router.

    I guess for the Firewall (cbac) case, one might have to add an pinhole to its associated input ACL specifically for a reply to the originating port (and possibly address).

    ReplyDelete
  6. This is a new set of configuration. The recent CISCO firmware and IOS upgrades have new configurations trunk lines.
    polycom ip 550

    ReplyDelete