Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LiMe networks trick clients into thinking IPv6 is available #95

Open
nordurljosahvida opened this issue Nov 27, 2018 · 6 comments
Open

Comments

@nordurljosahvida
Copy link

nordurljosahvida commented Nov 27, 2018

Every since I started using LiMe, any client on the lan thinks the network is IPv6 enabled, even though the only gateway in the network is IPv4 only. This happens across every LiMe deployment I have.

root@ubuntu:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1350 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:92:14:5a brd ff:ff:ff:ff:ff:ff
    inet 10.42.127.114/16 brd 10.42.255.255 scope global dynamic noprefixroute ens33
       valid_lft 2898sec preferred_lft 2898sec
    inet6 2a00:1508:a42:2400:65a1:d08b:f4f0:c0b0/64 scope global temporary dynamic 
       valid_lft 85694sec preferred_lft 85268sec
    inet6 2a00:1508:a42:2400:a74c:b3c1:31c7:10cd/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 85694sec preferred_lft 85694sec
    inet6 fe80::31f8:75e3:9044:a458/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Therefore anytime a hostname has an IPv6 record associated in DNS, some clients, such as android devices, try using the IPv6 address, and of course connections fail.

I've noticed that an IPv6 range is generated in lime-defaults, why do those look like global addresses?

Thanks

@nicopace
Copy link
Contributor

nicopace commented Nov 27, 2018 via email

@ilario
Copy link
Member

ilario commented Nov 27, 2018

It also happened to me, annoying, please check this: libremesh/lime-packages#236

@nordurljosahvida
Copy link
Author

Thank you for the super fast reply.

Here it is:

root@ubuntu:~# ip -6 r
2a00:1508:a42:2400::/64 dev ens33 proto ra metric 100 pref medium
fe80::/64 dev ens33 proto kernel metric 100 pref medium
fe80::/64 dev ens33 proto kernel metric 256 pref medium
default via fe80::a8aa:aaff:fe42:24aa dev ens33 proto ra metric 100 pref medium

This is a VM running on my pc, but I'm using connection sharing rather than a bridge. However this issue happens on all devices I have, and on android devices especially, many apps do this. I think it also depends on how the ns resolution is performed. To give you a very specific example, the conversations XMPP client will try connecting to our server [ae.os.vu] and will always fail from any LiMe network. This is the result of a host query for this hostname:

root@ubuntu:~# host ae.os.vu
ae.os.vu has address 80.211.10.102
ae.os.vu has address 89.46.73.154
ae.os.vu has address 217.61.60.150
ae.os.vu has IPv6 address 2a00:6d40:72:7966::1
ae.os.vu has IPv6 address 2a00:6d41:10:109a::1

Thanks again

@nicopace
Copy link
Contributor

nicopace commented Nov 27, 2018 via email

@nordurljosahvida
Copy link
Author

Cool thanks. I hope we can figure this out. Let me know if any further data is needed.

@G10h4ck
Copy link
Member

G10h4ck commented Nov 29, 2018

Nexthop should answer with an ICMP unreachable packet, if the client have no strange firewall rules it should be unnoticeable the delay caused by having the IPv6 default route

@ilario ilario added the bug label Jan 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants