Can't connect to IPv4 addresses

Questions about WIFI networks and devices
Forum rules
Before you post please read how to get help
Post Reply
coolreader18
Level 1
Level 1
Posts: 6
Joined: Thu Jul 05, 2018 11:19 pm

Can't connect to IPv4 addresses

Post by coolreader18 » Thu Nov 08, 2018 8:56 pm

I've been having this issue for about a week, and it came completely out of the blue. I can't connect to IPv4 addresses at all, and I'm 99% sure that's the definite issue. With the settings I had prior to this problem, I could ping/browse google.com and a few other sites, but nothing else. After a bit and browsing some stackexchange posts I realized that they all had IPv6 addresses, and the sites I couldn't connect to were all IPv4. So after some searching I set up DNS64 and NAT64, but the issue with those is that they are slow. Google's speed test, which uses its own IPv6, gives me ~50 Mb/s download, while speedtest.net, which only has IPv4 and has to route through DNS64, gets around 2 Mb/s. I don't have this issue when connected via ethernet. In NetworkManager, I have IPv4 disabled for my network, and using TREX's DNS64 server for the IPv6 tab's DNS (google's DNS64 doesn't work).

ifconfig output:

Code: Select all

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        ether 02:42:5c:19:b9:55  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp2s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether f8:32:e4:2d:d7:b3  txqueuelen 1000  (Ethernet)
        RX packets 216213  bytes 289789373 (289.7 MB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 122519  bytes 22892240 (22.8 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 25534  bytes 3419198 (3.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25534  bytes 3419198 (3.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 2600:1700:5650:6f60::5a2  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::abcb:9f97:e9ba:ecf7  prefixlen 64  scopeid 0x20<link>
        inet6 2600:1700:5650:6f60:33b1:4262:abf0:faef  prefixlen 64  scopeid 0x0<global>
        ether 28:c2:dd:58:9d:6d  txqueuelen 1000  (Ethernet)
        RX packets 2304880  bytes 2664525118 (2.6 GB)
        RX errors 0  dropped 67632  overruns 0  frame 0
        TX packets 1586169  bytes 202516924 (202.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

User avatar
trytip
Level 9
Level 9
Posts: 2518
Joined: Tue Jul 05, 2016 1:20 pm

Re: Can't connect to IPv4 addresses

Post by trytip » Thu Nov 08, 2018 9:03 pm

what's your ipv4 DNS? i don't see an ipv4 dns in the link
Image

coolreader18
Level 1
Level 1
Posts: 6
Joined: Thu Jul 05, 2018 11:19 pm

Re: Can't connect to IPv4 addresses

Post by coolreader18 » Thu Nov 08, 2018 9:55 pm

It's not a DNS issue, host was showing the correct IPv4 addresses for a hostname and I just couldn't connect to those (even directly), but I was using 1.1.1.1 and 8.8.8.8 and their fallbacks.

User avatar
trytip
Level 9
Level 9
Posts: 2518
Joined: Tue Jul 05, 2016 1:20 pm

Re: Can't connect to IPv4 addresses

Post by trytip » Sun Nov 11, 2018 10:44 am

host was showing the correct IPv4 addresses for a hostname
i don't see that here, or don't quite understand what this means
Image

coolreader18
Level 1
Level 1
Posts: 6
Joined: Thu Jul 05, 2018 11:19 pm

Re: Can't connect to IPv4 addresses

Post by coolreader18 » Sun Nov 11, 2018 2:48 pm

I'd type in host reddit.com or something into the command line and it'd give me the list of IPv4 addresses for it, but browsing to/pinging those addresses directly still didn't work.

User avatar
trytip
Level 9
Level 9
Posts: 2518
Joined: Tue Jul 05, 2016 1:20 pm

Re: Can't connect to IPv4 addresses

Post by trytip » Sun Nov 11, 2018 3:09 pm

the simplest way to test if this is an ISP issue is boot a live mint and try to get to these site there.
Image

redlined
Level 4
Level 4
Posts: 406
Joined: Wed Jun 06, 2018 8:12 pm
Location: Mile High, Green State (Denver, CO:)

Re: Can't connect to IPv4 addresses

Post by redlined » Sun Nov 11, 2018 7:17 pm

coolreader18 wrote:
Thu Nov 08, 2018 8:56 pm
I've been having this issue for about a week, and it came completely out of the blue. I can't connect to IPv4 addresses at all, and I'm 99% sure that's the definite issue. With the settings I had prior to this problem, I could ping/browse google.com and a few other sites, but nothing else. After a bit and browsing some stackexchange posts I realized that they all had IPv6 addresses, and the sites I couldn't connect to were all IPv4. So after some searching I set up DNS64 and NAT64, but the issue with those is that they are slow. Google's speed test, which uses its own IPv6, gives me ~50 Mb/s download, while speedtest.net, which only has IPv4 and has to route through DNS64, gets around 2 Mb/s. I don't have this issue when connected via ethernet. In NetworkManager, I have IPv4 disabled for my network, and using TREX's DNS64 server for the IPv6 tab's DNS (google's DNS64 doesn't work).
something 6 to 4 appears to be working for you... I'd look at fully undoing any local NAT64/DNS64 then try other remote options (besides TREX) since their policy, as read from your link above, states:
TREX policy: Acceptable Usage wrote:The servers are made available as is. Their main intended userbase is Finland. We reserve the right to deny this service if we uncover abuse or malicious activities. We may also limit the NAT64 traffic to less than 100Mbps for the same reason. The maximum acceptable rate of queries to the recursive name servers from a single network is one thousand queries per second or 1000q/s.
unlikely you would have been flagged abusive (although...single network?), however, they may have implemented geo-blocks/restrictions recently that drop your requests if you are not:
TREX policy: About wrote:...Finnish end users as part of a research project in association with the Finnish Future Internet programme and Internet Testbed Finland.
Like trytip's inital response (and having read your replies) I still believe this is a DNS (or more specifically a NAT64 DNS) issue. Please bear with me, Ima Linux noob so offer food for thought, not advice. I also agree with trytip's most recent reply on attempting to do what you do using LM live session to help rule out ISP and remote DNS issues.

Wrapping my head around all this I found this helpful from cloudflare blog:
Translation requires technologies such as NAT64 and DNS64. NAT64 allow IPv6 hosts to communicate with IPv4 servers by creating a NAT-mapping between the IPv6 and the IPv4 address. DNS64 will synthesize AAAA records from A records. DNS64 has some known issues like DNSSEC validation failure (because the DNS server doing the translation is not the owner’s domain server). For service providers, supporting IPv4/IPv6 translation means providing separate IPv4 and IPv6 connectivity thus incurring additional complexity as well as additional operational and administrative costs.

my first step would be to make sure DNSSEC is disabled if you find you require DNS64 (which you "shouldn't" if the DNS server is IPv6, leaving NAT64 still a potential problem), those validation failures may be causing issue.

then I'd remove TREX from the equation, at least to test things are working at your PC. try Cloudflare IPv6 DNS for that.
(their DNS address info from that page since IPv4 resolving is not working :|

Code: Select all

The addresses of 1.1.1.1 are:
    1.1.1.1
    1.0.0.1
    2606:4700:4700::1111
    2606:4700:4700::1001
if that doesn't change anything then I'd consider blocking IPv4 "system wide", to rule out resolve timeouts due to something weird going on between IPv4&6 on your PC. A good discussion on that can be found here: Security flaw found in systemd (translate disabling IPv6 methods into IPv4 info you want)

other thoughts:

what is docker0 first device listed in the ifconfig output? is this a docker.com app created virtual adapter that you run DNS64 or something else from?

Also curious about where you mentioned putting the cloudflare and google IPv4 DNS entries on a disabled IPv4 system?

(as well I do not think your assessment of host command in terminal returning appropriate IPv4 address demonstrates DNS works for your system by showing you an IPv4 result. Although I could be wrong, as I block IPv6 everywhere I can, system wide, and always get error from host lookup, as seen here:

Code: Select all

~$ host google.com
google.com has address 172.217.1.206
google.com host information "AAAA queries have been locally blocked by dnscrypt-proxy" "Set block_ipv6 to false to disable this feature"
however, I can open google.com via IP address direct 172.217.1.206 in browser address bar. I cannot ping in terminal nor directly open IPv6 addresses in browser as entire system is IPv6 disabled.

When I run test at test-ipv6 anything regarding IPv6 results show Fail and I would expect yours to return all as good and especially IPv6 info (NAT64 I believe will respond to test with IPv4 info?). It may be worth your while to reenable IPv4 to run this test fully, they provide a lot of details and information on the tests, even formatting the FAQs to include your info.

(edit 1 for typos and clarification
(edit 2 to add APNIC NAT64 check HTH!
Moem kōan 42: Should tool manufacturers be required to fix their products so that you cannot use their saws to cut the tree branch that you're sitting on?

(The answer to the ultimate question of life, the universe and everything is... 42!!;)

coolreader18
Level 1
Level 1
Posts: 6
Joined: Thu Jul 05, 2018 11:19 pm

Re: Can't connect to IPv4 addresses

Post by coolreader18 » Sun Nov 11, 2018 10:06 pm

It's all fixed now, I don't really know why. I reenabled IPv4, because I figured it wasn't going to break anything just by being enabled, and it was working again.
(as well I do not think your assessment of host command in terminal returning appropriate IPv4 address demonstrates DNS works for your system by showing you an IPv4 result.
Basically what I was trying to say before is that I was sure that DNS resolution was working, but I just couldn't navigate to the IPv4 addresses that it returned.
try Cloudflare IPv6 DNS for that.
Cloudflare does not have DNS64 for 1.1.1.1, all it does is resolve like this:

Code: Select all

➜ host one.one.one.one
one.one.one.one has address 1.1.1.1
one.one.one.one has address 1.0.0.1
one.one.one.one has IPv6 address 2606:4700:4700::1001
one.one.one.one has IPv6 address 2606:4700:4700::1111
➜ host forums.linuxmint.com
forums.linuxmint.com has address 192.124.249.8
➜ host github.com                   
github.com has address 192.30.253.113
github.com has address 192.30.253.112
What DNS64 does, as I understand it, is prepend an IPv6 prefix 64:ff9b::/96 to each IPv4 address that gets resolved, and then when the client queries that, the IPv4 address gets revealed through some sorta TCP header or something...? I don't think TCP headers exist and I'm not quite sure exactly how it works, but it's something like that.

redlined
Level 4
Level 4
Posts: 406
Joined: Wed Jun 06, 2018 8:12 pm
Location: Mile High, Green State (Denver, CO:)

Re: Can't connect to IPv4 addresses

Post by redlined » Sun Nov 11, 2018 10:38 pm

coolreader18 wrote:
Sun Nov 11, 2018 10:06 pm
It's all fixed now, I don't really know why. I reenabled IPv4, because I figured it wasn't going to break anything just by being enabled, and it was working again.
try Cloudflare IPv6 DNS for that.
Cloudflare does not have DNS64 for 1.1.1.1, all it does is resolve like this:

Code: Select all

➜ host one.one.one.one
one.one.one.one has address 1.1.1.1
one.one.one.one has address 1.0.0.1
one.one.one.one has IPv6 address 2606:4700:4700::1001
one.one.one.one has IPv6 address 2606:4700:4700::1111
➜ host forums.linuxmint.com
forums.linuxmint.com has address 192.124.249.8
➜ host github.com                   
github.com has address 192.30.253.113
github.com has address 192.30.253.112
What DNS64 does, as I understand it, is prepend an IPv6 prefix 64:ff9b::/96 to each IPv4 address that gets resolved, and then when the client queries that, the IPv4 address gets revealed through some sorta TCP header or something...? I don't think TCP headers exist and I'm not quite sure exactly how it works, but it's something like that.
We got something working! lol (now to continue with IPv6 only client system or not is the question:)

heh, yah, TCP packets have headers but all of it does not need to be rocket science for us users. The whole DNS64 and NAT64 is really 2011/12 tech, when we started running out of IPv4 addresses globally. Although adopted rapidly IPv6 needed translation more often than not- that has slowly changed since and I do not know that they apply today as before, especially if you are ok with IPv4 enabled on system.

Cloudflare deployed DNS/NAT64 back in 2012 (from their blog) for their users, and I believe their Public DNS offerings are the same, i.e. do not require changes/special software client side..

If leaving IPv4 enabled is no issue for you (compared to my adamantly not allowing anything IPv6, for near/mid future concerns) then yes, leave IPv4 enabled. If you want IPv6 only then continue to test disabling IPv4 and see if manual input of Cloudflares IPv6 DNS server addresses help get you what you want- then there is no compromise to desire: win-win

also check those two IPv6 tests I linked to. This should help confirm if IPv6 is actually working fine (DNS queries over IPv6 too) and your system is not doing a fail-over to DNS via IPv4 (which I what I suspected earlier- and mention of timeouts)

https://test-ipv6.com/

https://blog.apnic.net/2017/08/23/intro ... 4-checker/

(note, both sites require javascript, if you have NoScript or similar on browser you may need to give temp permissions to site more than once for their different script sources to load, the test-ipv6 site mentions this specifically- 2x allow in noscript. and if you wish to share results (look carefull for links on the test-ipv6, there is a couple different reports you can view with varying details and results on all the tests they performed as well they link to an auto-magically customized FAQs page that integrates those results for a more personalized question and answer conversation.
Moem kōan 42: Should tool manufacturers be required to fix their products so that you cannot use their saws to cut the tree branch that you're sitting on?

(The answer to the ultimate question of life, the universe and everything is... 42!!;)

Post Reply

Return to “Wireless”