IPv6 not working on LAN
-
Hello,
I’ve setup multiple LAN network (for computers, servers and etc…) using IPv4 but devices on the LAN cannot connect to an ipv6 address. When i try to ping ipv6 address => resolution failure.
However my pfsense router can ping iov6 address.
I don’t want my lan devices to have ipv6 implemented, i just want my they can reach ipv6 devices on WAN.
Thank you for your help
-
@regiolis said in IPv6 not working on LAN:
I don’t want my lan devices to have ipv6 implemented, i just want my they can reach ipv6 devices on WAN.
How would that work? For a device to talk to an Ipv6 address, it needs an IPv6 address.
Are you thinking you can nat an IPv4 to your pfsense wan IPv6 address?
-
On my ISP's LAN network both ipv6 and ipv4 are enabled.
But not in my Pfsense LAN network
I have set IPv6 Configuration Type to SLAAC and tried to setup DHCPv6 but still doesn't works.
-
-
@regiolis Normally your wifi router would be used as just as AP when you move to pfsense and it would be ehind pfsense.
if you want your pfsense lan devices to have IPv6, you would need to delegate a prefix from your isp router to pfsense.
Out of curiosity - what do you think IPv6 is going to get you? is there something you can not do without IPv6?
That sort of setup is not ideal.. Can you not put pfsense on the edge so it wan gets public IP from your isp?
-
@johnpoz i want to setup ipv6 because my pfsense lan devices cannot connect to servers that use ipv6. For example, on my debian server, apt update not working because it cannot connect to php repository because ipv6 resolution failed
-
@regiolis said in IPv6 not working on LAN:
on my debian server, apt update not working because it cannot connect to php repository because ipv6 resolution failed
I can tell you for a fact that you do not need IPv6 to access the debian repositories.. Not having IPv6 does not mean you can not talk to debian repositories.. So VAST amount of the planet does not have IPv6.. Your saying none of those people can update their debian boxes? Does that make any sense?
-
As mentioned above, if you want to reach IPv6 devices, you need IPv6 on the LAN side. Why don't you want IPv6? It's easy enough to enable.
-
@JKnott said in IPv6 not working on LAN:
It's easy enough to enable.
Not when your behind some isp device and pfsense is not getting a delegation for IPv6..
-
Is that what's happening? Can it be put into bridge mode?
BTW, I recently watched a video, from about 10 years ago, about T-Mobile moving their network to IPv6, as there aren't enough IPv4 addresses for their customers. One thing they mentioned, which I only learned recently, is with VoLTE (and VoNR) a phone gets a 2nd address for the phone. This means they need twice as many addresses and NAT is not an option for them. As with my carrier, they use 464XLAT to provide access to IPv4 only sites & apps.
The world is moving to IPv6 because it has to, even if only to meet the needs of mobile devices. Discouraging people from using it, is not helping anyone and only delays the inevitable. This is before we even get to IoT, which is one of the things 5G supports. While @regiolis might not need IPv6 to reach those servers, sooner or later he will need it.
-
@JKnott dude I do not want to get into the whole IPv6 users not using it slowing down adoption again.. Because your just delusional plain and simple... You could have 1 million users all turn off IPv6 and it would have zero to do with the world rate at moving towards it..
Yes many carriers have moved over to using IPv6 - why because they have billions of devices.. Has zero to do with billy bob home user needing it or not - ZERO..
Now back to the OP question, already mentioned to him that his pfsense should be on the edge and get the prefix from his ISP if he wants to use IPv6.
But his statement about his debian "needing" ipv6 talk to the repositories is not true..
Here fired up a debian VM, zero IPv6 on this network its attached too - zero issues talking to the repositories, and installing a package - and you can see it has no IPv6 other than its link local..
I am not sure what issue you are having with your debian talking to the repositories but it has zero to do if you have IPv6 or not. Here let me give it a IPv6 that is borked and not actually work talking to the internet.. Be Back in a bit.
edit.. Here so I let this VM get an IPv6, that can work - but I turned off the firewall rule that allows it.. So see it got an IPv6, but can not ping outside or talk on IPv6 because the pfsense firewall blocks it - apt still works, so its still talking to the repositories..
also see that it can resolve the AAAA for the repository its talking too
root@debian:/home/user# dig deb.debian.org AAAA +short debian.map.fastlydns.net. 2a04:4e42:44::644 root@debian:/home/user#You having a working IPv6 has zero to do with resolving AAAA, doesn't matter if you can resolve it or cant't resolve.. But clearly debian does not require a working IPv6 to get updates.. Be it has no IPv6 at all, or even an IPv6 that just doesn't work..
But if you want to use IPv6 from your isp behind pfsense - your going to need pfsense to be able to get a delegation from your ISP, it rarely going to be able to do that from behind a NATing device from your ISP. So put that device in bridge mode, so pfsense is on the actual edge and can get a prefix.. Or maybe set up a HE tunnel if you want.
Or look to what is borked in your debian setup and not worry about IPv6.. Because it clearly does not require it to update.. You using or not using IPv6 has zero impact on world adoption of IPv6.. Maybe the "Elders of the Internet" (kudos if you get that reference) will see that you turned it off - and just have to rethink the whole IPv6 thing completely..
edit: So see this little lower variation in how many people are using it to talk google via IPv6.
That is when Kevin, some random guy on the internet that read a post of mine about just turning it off if you don't need it.. And put a big damper on the ability to move forward in its growth.. ;)
See all those variations - that must be random people reading my posts and just turning it off ;) I am single handily preventing IPv6 global adoption.. We would prob be turning off IPv4 by now, if it wasn't for me - hahahaha
Or maybe we can blame Greenland - the bastards are holding us all back.. Poor guys there not able to update their Debian installs either I bet..
I found the culprit - it's Iceland.. They need to get their act together - the world is waiting on them
-
@johnpoz said in IPv6 not working on LAN:
@JKnott said in IPv6 not working on LAN:
It's easy enough to enable.
Not when your behind some isp device and pfsense is not getting a delegation for IPv6..
that's my case..... so i don't know how to do
As you can see, ipv6 resolution failed for php repo.
-
@regiolis your client can not connect to the packages.sury.org on IPv6, so failed back to IPv4, and that connection timed out..
Who says it would even work on IPv6?
here I can talk to that fqdn on IPv4, because box doing it from has no IPv6.
C:\>curl https://packages.sury.org <html> <head><title>Index of /</title></head> <body> <h1>Index of /</h1><hr><pre><a href="../">../</a> <a href="apache2/">apache2/</a> 01-Dec-2023 13:00 - <a href="bind/">bind/</a> 01-Dec-2023 13:00 - <a href="bind-dev/">bind-dev/</a> 01-Dec-2023 13:00 - <a href="bind-esv/">bind-esv/</a> 01-Dec-2023 13:00 - <a href="coccinelle/">coccinelle/</a> 13-Jun-2023 14:05 - <a href="cppcheck/">cppcheck/</a> 13-Jun-2023 14:28 - <a href="frr/">frr/</a> 15-Jun-2023 06:45 - <a href="jenkins-debian-glue/">jenkins-debian-glue/</a> 13-Jun-2023 12:26 - <a href="kea/">kea/</a> 28-Feb-2023 11:40 - <a href="lmdb/">lmdb/</a> 13-Jun-2023 13:47 - <a href="nginx/">nginx/</a> 15-Jun-2023 18:11 - <a href="nginx-mainline/">nginx-mainline/</a> 01-Dec-2023 13:00 - <a href="php/">php/</a> 01-Dec-2023 13:00 - <a href="php-qa/">php-qa/</a> 01-Dec-2023 13:00 - <a href="pool/">pool/</a> 03-Mar-2021 08:08 - <a href="qbittorrent/">qbittorrent/</a> 13-Jun-2023 13:03 - <a href="softhsm2/">softhsm2/</a> 13-Jun-2023 12:11 - <a href="wireguard/">wireguard/</a> 14-Jun-2023 10:41 - <a href="error403.html">error403.html</a> 22-Dec-2019 08:33 1083 <a href="report.html">report.html</a> 13-Jun-2023 00:00 952617 </pre><hr></body> </html>And via IPv6 as well.. Here I used a client that has IPv6 and forced ipv6 with the -6
curl -6 https://packages.sury.org -v * Trying [2400:52e0:1a00::1070:1]:443... * Connected to packages.sury.org (2400:52e0:1a00::1070:1) port 443 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: none * CApath: /etc/ssl/certs/ * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN: server accepted h2 * Server certificate: * subject: CN=packages.sury.org * start date: Oct 26 23:11:00 2023 GMT * expire date: Jan 24 23:10:59 2024 GMT * subjectAltName: host "packages.sury.org" matched cert's "packages.sury.org" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * using HTTP/2 * [HTTP/2] [1] OPENED stream for https://packages.sury.org/ * [HTTP/2] [1] [:method: GET] * [HTTP/2] [1] [:scheme: https] * [HTTP/2] [1] [:authority: packages.sury.org] * [HTTP/2] [1] [:path: /] * [HTTP/2] [1] [user-agent: curl/8.4.0] * [HTTP/2] [1] [accept: */*] > GET / HTTP/2 > Host: packages.sury.org > User-Agent: curl/8.4.0 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing < HTTP/2 200 < date: Sat, 02 Dec 2023 17:15:29 GMT < content-type: text/html < vary: Accept-Encoding < server: BunnyCDN-IL1-1070 < cdn-pullzone: 717719 < cdn-uid: a7a277f7-2828-404b-9c94-f3b9b03c0434 < cdn-requestcountrycode: US < cache-control: public, max-age=2592000 < strict-transport-security: max-age=63072000; includeSubDomains; preload < x-frame-options: DENY < x-content-type-options: nosniff < x-xss-protection: 1; mode=block < cdn-proxyver: 1.04 < cdn-requestpullsuccess: True < cdn-requestpullcode: 200 < cdn-cachedat: 12/01/2023 18:45:03 < cdn-edgestorageid: 718 < cdn-status: 200 < cdn-requestid: 793176679a3719d2ce7f8f6f6a7f0d6a < cdn-cache: HIT < <html> <head><title>Index of /</title></head> <body> <h1>Index of /</h1><hr><pre><a href="../">../</a> <a href="apache2/">apache2/</a> 01-Dec-2023 13:00 - <a href="bind/">bind/</a> 01-Dec-2023 13:00 - <a href="bind-dev/">bind-dev/</a> 01-Dec-2023 13:00 - <a href="bind-esv/">bind-esv/</a> 01-Dec-2023 13:00 - <a href="coccinelle/">coccinelle/</a> 13-Jun-2023 14:05 - <a href="cppcheck/">cppcheck/</a> 13-Jun-2023 14:28 -Notice the IPv6 I used for that fqdn is a bit different that what your getting.. Your problem is not that IPv6 isn't working your problem is that IPv4 isn't working either..
And that is just that one fqdn you can not talk too, your clearly talk to the others.. Why do you even have that one in there, clearly your talking to the main dep.debian.org repository..
Why are you trying to pull stuff from a bullseye repo? current version of debian is Bookworm (12) 11 is bulleyes..
Anywhoo - I tried talking to that IPv4 address.. and I can talk to it.
C:\>curl -k https://169.150.247.38 -v * Trying 169.150.247.38:443... * Connected to 169.150.247.38 (169.150.247.38) port 443 * schannel: disabled automatic use of client certificate * schannel: using IP address, SNI is not supported by OS. * ALPN: curl offers http/1.1 * ALPN: server accepted http/1.1 * using HTTP/1.1 > GET / HTTP/1.1 > Host: 169.150.247.38 > User-Agent: curl/8.4.0 > Accept: */* > < HTTP/1.1 200 OK < Date: Sat, 02 Dec 2023 17:24:03 GMT < Content-Type: text/html < Transfer-Encoding: chunked < Connection: keep-alive < Vary: Accept-Encoding < Server: BunnyCDN-DE1-1081 < CDN-RequestId: 256546ea17462759b6df3768e0d557a3 < <html><head> <link href="http://fonts.bunny.net/css?family=Rubik:300,400,500,700,900" rel="stylesheet" type="text/css"> <link rel="stylesheet" href="https://bunnycdn.b-cdn.net/assets/landingpage/css/unconfigured.css"> <title>BunnyCDN - Node DE1-1081</title><meta name="norton-safeweb-site-verification" content="u9xdnnrb2ficyb1mhyc82vxqed2u0s0wdnchnlyhh2hvq0oz8fp1t0pt7u7i7tt66a9vx0lgonz1flh1cnjesvb03r2loequn14svim-k13jbfdoi3hjxj4ur1q9wy3a" /></head><body> <div id="header"> <a href="https://bunny.net"><img style="vertical-align:middle;margin-top: 70px;width: 218px;margin-bottom: -12px;margin-left: 32px; image-rendering: -webkit-optimize-contrast;" src="https://bunny.net/v2/images/bunnynet-logo.svg"></a> <br></div><div id="content" style="margin-top: 0px;"><h1 style="margin-top: -15px;margin-bottom: -11px; font-size: 24px;"><b>Server Node: </b>DE1-1081</h1><br>This server is a part of a CDN service provided by <a href="https://bunny.net">bunny.net</a>.<p></p></div><div id="footer"><a href="https://support.bunny.net/hc/en-us/requests/new">Contact Support</a> | <a href="https://bunny.net/abuse">Report Abuse</a> </div></body></html> * Connection #0 to host 169.150.247.38 left intact C:\>But maybe that is no longer correct for what your trying to use it as a repo..
But again your problem is not related to you having IPv6 or not.. your problem is you can not talk to that site via IPv6 or even IPv4.. Why you think you even need to talk to that site I am not sure?
-
@johnpoz Whether it's ipv6 or ipv4, none of my servers on debian can ping packages.sury.org.
It has nothing to do with whether or not you implement ipv6 on your network. -
@regiolis said in IPv6 not working on LAN:
ping packages.sury.org.
I can ping it
C:>ping packages.sury.org
Pinging debsuryorg.b-cdn.net [169.150.236.99] with 32 bytes of data:
Reply from 169.150.236.99: bytes=32 time=10ms TTL=56
Reply from 169.150.236.99: bytes=32 time=14ms TTL=56But I am resolving slightly different IP - it is pointing to a CDN so that is quite common.
But I can also ping the IP you resolved too
C:>ping 169.150.247.38
Pinging 169.150.247.38 with 32 bytes of data:
Reply from 169.150.247.38: bytes=32 time=142ms TTL=115
Reply from 169.150.247.38: bytes=32 time=141ms TTL=115So again your problem isn't that IPv6 isn't working.. Your problem is neither IPv6 or IPv4 is working, even if you turned off IPv6.. you would still have the problem of not being able to talk to IPv4 address..
Fix your IPv4 problem would be my suggestion.. Are you blocking any IP ranges in pfsense?
-
@regiolis said in IPv6 not working on LAN:
hat's my case..... so i don't know how to do
Describe your Internet connection. For example, I'm on a cable modem, which I put into bridge mode. This allows DHCPv6-PD to reach my pfSense firewall, which will then provide IPv6 to the LAN.