Joined: 24 Feb 2013 Posts: 1634 Location: Belgrade
Posted: Fri May 05, 2023 7:31 Post subject:
well, sadly for you this confirms that problem is not on ddwrt side... all needed ports are opened. Probably something changed on Comcast side at the same time when ddwrt worked on firewall improvements... PaulGo tested old builds and even they don't work anymore with Comcast...
It is sure that Comcast doesn't follow world wide standards and RFC and ddwrt has to take care of security of all users not just Comcast... I cannot help so I will not comment anymore... I suggest you not to lower your network security and change ISP...
Joined: 01 Dec 2021 Posts: 289 Location: Maryland, United States
Posted: Fri May 05, 2023 16:10 Post subject:
silvarios wrote:
I have the same problem actually. And I was the one who found the possible solution in an old bug report on the DD-WRT bug tracker. We could have simply continued the thread in the last one but it was locked for some reason...
It is okay if there is not a global DD-WRT patch if it's a Comcast flaw on their end, but are we saying if that is indeed the solution to get IPv6 working with Comcast, that every other modern router on the US market is similarly misconfigured, since they tend to work out of the box? That seems alarming if true. Not necessarily surprising, but alarming none the less.
AS silvarios and I stated, it seems inconceivable that all the router manufactures would have firmware that would have an IPv6 security risk. On my Netgear RAX54S router I have no problems getting IPv6 from Comcast without any modifications. I also have looked the DSL Reports forum Comcast thread and currently no one has reported any problems with Comcast IPv6.
Also, Comcast has about 35 million internet subscribers in the US, many of them have no or a limited choice in choosing another provider. I think it is essential that DD-WRT comes up with a safe solution for Comcast IPv6 compatibility.
I suggest you not to lower your network security and change ISP...
I have no other ISP choices. I suppose I could tether my cell phone? I would get 50GB of data a month per line, but that's silly.
Also, older builds do work for me, something changed in DD-WRT around December or January of 2022/2023. I posted about the problem previously and it was mostly ignored in all honesty.
Quote:
On r51040, I have a WAN IPv6 address from Comcast without doing anything other than enabling IPv6, enabling prefix delegation (64), and I ended up disabling radvd and instead enabling those Dnsmasq settings also suggested by the OP (I think once I enabled static DNS for IPv6 something got funky so I switched to using the Dnsmasq advanced settings).
From the prior thread. So I literally had things working without any firewall rules and only changes in Dnsmasq because of DNS preferences largely. That post was made March 13 of this year so pretty sure it's not a Comcast problem. I can take my whole network down again to test the older build but it gets frustrating to simply receive back, "Not our problem," when older builds work and newer ones don't.
To clarify, I appreciate the help provided by anyone and everyone willing to take time out of their busy day, I do not mean to sound ungrateful. I just wanted to clarify, since the only firmware/device tested not functioning correctly right now seems to be the DD-WRT builds post 2022.12.17, I think there's something funky for whatever reason with Comcast's IPv6 and DD-WRT's firewall settings.
My question would be, is it better to downgrade to that build for the time being than using more recent builds with the potentially unsafe Firewall setting?
Edit: To answer my own question, probably safer to be able to move forward given the security concern for the firewall rule tweak is the same one that was formerly present in older DD-WRT builds. As such, rolling back to avoid the problem might open one up to general security or bug issues as time goes on and the newer builds can simply be configured to recognize the potentially unsafer firewall rule. Probably best to move forward and add firewall rule. If DD-WRT wants to err on the side of security, I don't blame them and accept we just need to document the issue somewhere so Comcast users don't have to bang their head on the wall figuring out "what's wrong".
Last edited by silvarios on Sun May 07, 2023 0:40; edited 1 time in total
Posted: Sat May 06, 2023 21:11 Post subject: v3.0-r51040 std works!
Rolled back to build DD-WRT v3.0-r51040 std (12/17/22). Enabled IPv6, if I leave native on, because I was curious what would happen, my clients get an IPv6 address but it doesn't route because the router doesn't receive one. Which makes sense I think. Again, simply wanted to check all possibilities.
If I select prefix delegation, I get IPv6 addresses on client and router and everything works. No other changes made, no Dnsmasq Infrastructure->Additional Options configured and radvd remains enabled. As I said, I can switch over to Dnsmasq for IPv6 and disable radvd, but I wanted to show how literally the old build just works for me and newer builds don't work. How should we proceed? Should I compare the firewall rules on this build and we can see what changed?
When the new builds stop being broken, I can try the most recent build, but at this moment, I'm not sure what counts as the most recent builds given the last two weeks or so haven't had any that function properly.
Edit: Not complaining about the buggy builds in recent weeks, it's simply an acknowledgement I'm not sure how to test latest builds as generally requested for troubleshooting given the current build problems. I can resume testing once a working build is uploaded of course.
Last edited by silvarios on Sun May 07, 2023 0:42; edited 2 times in total
Joined: 01 Dec 2021 Posts: 289 Location: Maryland, United States
Posted: Sat May 06, 2023 23:35 Post subject:
This is puzzling since if you need firewall additions for new builds because Comcast has security problems with IPV6. Yet old builds accept the security problems. This just not make any sense. Also as you and I stated all router manufacturer firmware work with Comcast.
This is puzzling since if you need firewall additions for new builds because Comcast has security problems with IPV6. Yet old builds accept the security problems. This just not make any sense. Also as you and I stated all router manufacturer firmware work with Comcast.
The answer after checking all the ip6tables rules in build v3.0-r51040 std (12/17/22):
Code:
ip6tables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p ipv6-icmp -m limit --limit 30/min -j ACCEPT
-A INPUT -s fe80::/64 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A INPUT -s ::1/128 ! -i lo0 -j DROP
-A INPUT -i lo0 -j ACCEPT
-A INPUT -p udp -m udp --dport 546 -j ACCEPT
-A INPUT -j DROP
-A INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o vlan2 -j ACCEPT
-A FORWARD -p ipv6-icmp -m limit --limit 30/min -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
-A OUTPUT -s ::1/128 -j DROP
-A OUTPUT -o lo0 -j ACCEPT
Notice the part in bold, it's the rule we insert into the firewall on current builds to get things working. If you check the newer builds, they switched to the settings mentioned in this thread (or something close since I obviously have not tested every build since December 17, 2022):
ip6tables -A INPUT -s fe80::/10 -d fe80::/10 -p udp -m udp --sport 547 --dport 546 -m conntrack --ctstate NEW -j ACCEPT
I'd say we Comcast users can go ahead and just add the old Firewall rule back since DD-WRT themselves shipped this same config for quite a while (months at least). While I respect the change DD-WRT made for better security going forward, probably unnecessary to chastise users for using unsafe settings. I think a simple explanation of the change would have sufficed. I do appreciate everyone's help in unraveling this mystery.
Paul, I'll do some more testing later when I once again reconfigure my network with a newer build and see if it's better to go the "delete current rule causing the problem" and "append our rule back" instead of "inserting the rule earlier in the chain" as we currently have things configured.
If the firewall rule change fixes this for users, that would be my recommendation.
Also, some folks asked what changed on the Comcast network. We have a new "10G" network design rolling out right now. This adds a few things:
- Support in the digital node for 10 Gbps EPON FTTH as well as DOCSIS 4.0 full duplex with 10 Gbps capacity
- Implements a distributed access network design that pulls the CMTS from the far edge into bigger datacenters and onto a virtual CMTS platform
- In near term, 100s of Mbps upstream following new mid-split spectrum changes in the DOCSIS network (e.g. more spectrum for upstream)
- Lays the groundwork for symmetric multi-gig to the home over FTTH or HFC as well as ultra low latency networking (aka IETF L4S)
So in the short term if a firewall change can fix the issue that is great. We've not really seen this on other platforms than DD-WRT but have ticketed it with the vCMTS dev team to investigate further and consider any potential config changes on our network (TBD).
Joined: 01 Dec 2021 Posts: 289 Location: Maryland, United States
Posted: Mon May 08, 2023 16:09 Post subject:
I just received this from the Comcast engineer I have been communicating with:
With regard to the DD-WRT’s ACL, while the majority of other gateways on our network are accepting DHCPv6 RENEW replies, we understand the changes DD-WRT’s has made and the intent of their new default DHCPv6 ACL.
Our vCMTS team is aware of the issue and investigating vCMTS improvements that could allow vCMTS to fit the stricter DD-WRT ACL.
While I cannot offer you an immediate solution or timeline, I can propose a temporary ACL that sits between the former more permissive ACL and the new strict ACL.
As I understand the DD-WRT discussion, DD-WRT changed IPTables syntax from:
-A INPUT -p udp -m udp --dport 546 -j ACCEPT
To:
-A INPUT -s fe80::/10 -d fe80::/10 -p udp -m udp --sport 547 --dport 546 -m conntrack --ctstate NEW -j ACCEPT
The proposed temporary rule would be:
-A INPUT -s 2001:558:4000::/36 -d fe80::/10 -p udp -m udp --sport 547 --dport 546 -m conntrack --ctstate NEW -j ACCEPT
This rule would be added after DD-WRT’s new default rule but before the subsequent DROP and REJECT statements.
It would apply the same security posture as the DD-WRT new default rule but would allow packets from the vCMTS to be accepted.
Joined: 01 Dec 2021 Posts: 289 Location: Maryland, United States
Posted: Tue May 09, 2023 14:02 Post subject:
I would like to thank jlivingood and Kris (the engineer I have been working with at Comcast) for the help they have supplied in resolving the DD-WRT IPv6 issues with Comcast. The slogan "Comcast Cares" truly applies!
-A INPUT -s 2001:558:4000::/36 -d fe80::/10 -p udp -m udp --sport 547 --dport 546 -m conntrack --ctstate NEW -j ACCEPT
This is GREAT that there is finally being progress made on this situation! Even cooler that you've been in touch with Comcast engineers directly!
So is this something that needs to be applied on the backend, or something we the users need to do? As it stands, right now I am still using the firewall patch that was suggested in the last thread, and I'm not really sure what to do from here.
