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.
Subscribe to:
Post Comments (Atom)
Deliveries from China
I have PCBs made in China (well Hong Kong). This is all my many small PCB projects (not FireBrick). I would rather use UK suppliers but I am...
-
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us... -
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo... -
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
Firewall? Which version? Which commands?
ReplyDeleteAFAICR acls do not affect router originated packets. Maybe it's rx packets being affected,
It is the reply, from a different IP and possibly even different port which does not get passed the firewall.
ReplyDeleteThe 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.
ReplyDeleteOf 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).
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.
ReplyDeleteAll the more reason for it to be at the PPP layer.
Hmm.
ReplyDeleteI'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).
This is a new set of configuration. The recent CISCO firmware and IOS upgrades have new configurations trunk lines.
ReplyDeletepolycom ip 550