Comcast Residential /64 Delegation

[JKnott]

@jpvonhemel said in Comcast Residential /64 Delegation:

I would not be able to subnet a /64

That is correct. LANs are /64. Any other value would break some things, such as SLAAC.

since I have only dealt with IPv4 and NAT since 1998

So, you have some bad habits to unlearn.

[jpvonhemel]

I think I had them setup that way. Here are some screenshots to help me go through it.
Something is odd because I see three different IPs for one adapter, one for each subnet. and three temporary v6 ips.

I am allowing IPv6 out from LAN to all, but cannot ping ipv6.google.com.

Here is the WAN

LAN Track Interface

VLAN 1 Track Interface

VLAN 2 Track Interface

Here is ipconfig /all

[JKnott]

@jpvonhemel said in Comcast Residential /64 Delegation:

Something is odd because I see three different IPs for one adapter, one for each subnet. and three temporary v6 ips.

Entirely normal. With SLAAC, you get a new temporary address every day for a week. So, you'd then have 1 consistent address, 7 temporary and a link local address, which starts with fe80.

On WAN, select Use IPv4 connectivity as parent interface.

Hmmm... I see what you mean about 3 addresses. Are those VLANs?

I don't have any experience with Comcast, so I may not know all the details.

[jpvonhemel]

@jknott This is a windows 10 pc on LAN. The IPv6 950 subnet corresponds to LAN, 951 to VLAN1, and 952, to VLAN2. I will try the Use IPv4 Connectivity as parent interface and see if it helps. Thank you for helping me out on this.

[jpvonhemel]

@jpvonhemel This may be an issue with my pc or a switch. Using my ipad, i was able to connect to Lan and both vlans and get a public ip with a subnet that matches the correct prefix for each interface.

[jpvonhemel]

I saw this strange binding of LAN, and 2 vlan IP addresses to a second PC.
Reboot and an ipconfig/release, renew seems to have resolved this and I can now successfully ping IPv6.google.com.

[bearhntr]

@jpvonhemel

Did you ever get this worked out? I seem to be stuck with one pending issue....says REVERSE LOOKUP - but I think that I have done everything correct.

I am still learning IPv6 myself - and just want to get this last notch in the belt fixed.

Looks like I finally got ICMP v6 working in the pfSense firewall - but no hostname resolution from my Server 2019 DC (with DNS and DHCP setup).

Curtis

[johnpoz]

@bearhntr you left your ipv4 listed - you ok with that, since you hide your ipv6..

I doubt comcast is going to let you update or maintain a your IPv6 PTR.. Unless you were on a business connection.

But HE allows you to control the PTRs for your IPv6 space..

[bearhntr]

@johnpoz

Thanks for responding. I saw that - but did not hide it because the IPv4 listed there is on the WAN PORT of my pfSense and it changes about every 2 days. The IPv6 (2601: ) address is what I am seeing on the computer where I ran this test. That is why I hid it.

The WAN IPv6 address is a 2001:558:xxxx:xxxx address - which is not shown on the IPv6 Test site.

I am a residential COMCAST customer, and I am pretty sure there is something on the Server_2019 DC (where I ran that test from) which is causing the 19/20 issue. I am thinking there is something with the Reverse DNS PTR record - but there is one on that server DNS with the Static v6 address I have set and it's name.

This one error/issue appears to be the only thing which is driving me nuts. I am sure that my pfSense Firewall could be better adjusted for ICMP as well. As it is pretty much wide open on the ICMP port in the firewall.

Curtis

[Bob.Dig]

@bearhntr said in Comcast Residential /64 Delegation:

I am a residential COMCAST customer, and I am pretty sure there is something on the Server_2019 DC (where I ran that test from) which is causing the 19/20 issue.

No, like John said, your ISP has to set this, if they want, not you.

[johnpoz]

@bearhntr said in Comcast Residential /64 Delegation:

pfSense Firewall could be better adjusted for ICMP as well. As it is pretty much wide open on the ICMP port in the firewall.

What about the device your actually pinging - its firewall would also have to allow for ping, etc. While you might be allowing the icmp through to your client - doesn't mean your client is going to answer.

Some local server has zero to do for a PTR of public space - while it would be possible for you to set it up so your local devices could resolve them - the public internet isn't going to be able to. Not unless you got with ARIN and pointed to your NS as the the authoritative NS for that arpa space ;)

PTRs are handled by the owner of the IP space - in your case that is comcast. Comcast is the only one that can answer or set the records for that space. HE electric allows users of the space they hand out via tunnels to control that via a web interface..

[JKnott]

@bearhntr said in Comcast Residential /64 Delegation:

Did you ever get this worked out? I seem to be stuck with one pending issue....says REVERSE LOOKUP - but I think that I have done everything correct.

Comcast wouldn't have any idea about host names on your LAN. They would likely have a host name for your WAN interface, but nothing behind it. You'd have to set up an external DNS that can be used for reverse lookup.

[johnpoz]

@jknott said in Comcast Residential /64 Delegation:

You'd have to set up an external DNS that can be used for reverse lookup.

Which comcast sure and the hell is not going to do ;) They are not going to let their residential clients set PTR records.. Or allow delegate some NS for some range. I would bet my house on that ;) Now if you have a business connection with them - they should be willing to set some specific records for you - since for example if your running some mail server off said connection. It would pretty much require a PTR to be able to send email to any of the major domains..

The arpa zones and where they point to for the NS is controlled by the owner of the IP space.. You could fire up 100 NS on the planet that all think they are authoritative for some .arpa zone for said space.. Nothing is going to ask them for their records until they are pointed to by ARIN or the RIR for that IP space..

Here is some space I control with arin.. And how I can point specific space to specific NameServers.

You can lookup the NS listed for any arpa zone with simple dig for the arpa zone asking for NS.

;; QUESTION SECTION:
;80.252.69.in-addr.arpa.                IN      NS

;; ANSWER SECTION:
80.252.69.in-addr.arpa. 7200    IN      NS      dns104.comcast.net.
80.252.69.in-addr.arpa. 7200    IN      NS      dns105.comcast.net.
80.252.69.in-addr.arpa. 7200    IN      NS      dns101.comcast.net.
80.252.69.in-addr.arpa. 7200    IN      NS      dns102.comcast.net.
80.252.69.in-addr.arpa. 7200    IN      NS      dns103.comcast.net.

It works exactly the same way for IPv6 space..

Sure in a perfect world with IPv6 - the ISP if they assigned you specific space, like with HE an the /48 they give you - they could set it up so you could edit your own zones records, or even sure if we are making wishes allow you to delegate to your own NS for your arpa zone..

Now with IPv4 many an ISP do setup a PTR, even if it just points to generic sort of record with the IP in it. But this is something they have not really done for IPv6 - because well there are quadrillions of address, so records that would need to be setup, or system to create the response on the fly depending on what was queried for..

here is for example my isp NS for the zone my IP falls into.

[bearhntr]

@johnpoz

In windows when you enable FILE AND PRINTER SHARING and ALLOW NETWORK DISCOVERY - it enables these:

[bearhntr]

@johnpoz

I have looked into ARIN - been reading their stuff for a while.

So in the grand scheme - should I change anything on my firewall to make IPv6 more secure? I can see why that IPv6-Test site sees my COMCAST Public IP Address - but still strange why it does not see the IPv6 address that Comcast gave me - instead it shows the IPv6 of the Static address (I made it up) on my Domain Controller.

The WAN IPv6 was given by COMCAST - as it is set to DHCPv6 - The LAN - I set as static address after making up an address and testing it with an online CIDR tester.

As you can see below - this is from Windows Network properties (the address showing in IPv6 Test) is the address I have STATIC on my Windows computer:

This is from the https://ipv6-test.com/ site:

Curtis

[johnpoz]

@bearhntr said in Comcast Residential /64 Delegation:

So in the grand scheme - should I change anything on my firewall to make IPv6 more secure?

I sure wouldn't do any any rule like you have ;) even for icmp

And have zero idea why you think you need to allow 547 and 546.. That is just a pointless rule..

Here is my ipv6 rules I allow inbound..

When it comes to a firewall, inbound - min required for stuff work is what should be allowed. I allow to ping my ntp server for ipv6, I allow to ping my tunnel IP for ipv6. I allow to ping my box for ipv6 (ping only).. I allow ntp to my ntp server, I allow traceroute to my ntp server - just because I like to see the it work.. Not really a requirement for anything..

[JKnott]

@bearhntr said in Comcast Residential /64 Delegation:

but still strange why it does not see the IPv6 address that Comcast gave me

You're not using the WAN address when you go to out onto the Internet. You're using an address within your prefix. In fact, you could likely do without that WAN address, as it isn't used for anything other than identifying the interface. Even routing is normally done using the link local address.

[bearhntr]

@johnpoz

This where the 547 and 546 came from:

https://homenetworkguy.com/how-to/configure-ipv6-opnsense-with-isp-such-as-comcast-xfinity/

Granted it is for OPNSense and not pfSense - but as I am reading OPNSense and pfSense are very similar.

Curtis

[johnpoz]

@bearhntr The rules needed to allow your wan to get dhcpv6 are there already - and would assume so in that other distro that will not be named.

More like the guy writing that just doesn't have a clue..

Once you set your wan to dhcpv6 - these rules are auto added..

https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html

# allow our DHCPv6 client out to the WAN
pass in  quick on $WAN proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 tracker 1000000563 label "allow dhcpv6 client in WAN"
pass in  quick on $WAN proto udp from any port = 547 to any port = 546 tracker 1000000564 label "allow dhcpv6 client in WAN"

"using the “Track interface” setting, a firewall rule needs to be created to allow the DHCPv6 traffic from your ISP to assign IPv6 addresses to your local devices."

Oh yeah - as I thought not a freaking clue!!!

That is not even close to how it works! <rolleyes>

When using track interface, pfsense will assign a /64 prefix from prefix delegated to it from the ISP, ie your /56 or /60, etc.. This prefix on your lan side interface is the prefix used and clients on this network will get their IPv6 from this prefix from how you have it configured on pfsense to hand out IPv6 addresses in the prefix.. Sure and the hell not coming from your ISP dhcp server.. And how would that even work? The dhcpv6 is multicast, that isn't going to be sent out to your isp even with those rules.. Its sent to ff02::1:2, why would pfsense seeing this traffic on your lan side interface forward this multicast to your isp??

edit: Lets say it some how worked even remotely like that.. which it doesn't - how would pfsense even see this multicast traffic on the lan side? Your rules there for ipv6 are lan net.. The dhcpv6 coming from the client is going to come form link-local, ie a fe80 IP, which is NOT lan net.. So you have no rules there on your lan interface that would even allow pfsense to see this dhcpv6 traffic and forward it on - which it wouldn't because its multicast.

Good thing pfsense creates the hidden rules for IPv6 to work for dhcpv6 if you enable that on the lan, or the other methods of ipv6 clients from getting their IPs SLAAC

[bearhntr]

@johnpoz

I disabled those 2 rules....

Then ran the IPv6-TEST again -- and now I am back to 17/20:

Curtis