LAN server not reachable over IPv6 over time

Got a problem with Viscosity or need help? Ask here!

Qlii256

Posts: 8
Joined: Sun Jul 17, 2016 11:36 pm

Post by Qlii256 » Mon Jul 18, 2016 12:05 am
Hi there!

I'm a happy user of Viscosity, and have been using it for a while now. I've recently discovered some weird behaviour with Viscosity and my local (LAN) server. When I reset the Wi-Fi-interface and connect to my VPN-server using Viscosity, everything works fine. But after some time (not sure when or why), I cannot ping that server over IPv6 anymore, IPv4 still works fine.

I've tried pinging the server from other computers in the same LAN, and they all seem to be able to connect without any problems over IPv6 (none of these systems run Viscosity!). When disconnecting from my VPN server (which is also able to ping my servers' IPv6-address) on my system, the server is still not reachable over IPv6.

When performing a traceroute, I get the following output:
Code: Select all
traceroute6 to 0000:0000:0000:0000:0000:0000:0000:0002 (0000:0000:0000:0000:0000:0000:0000:0002) from 0000:0000:0000:0000:0000:00ff:f000:0003, 64 hops max, 12 byte packets
1  0000:0000:0000:0000:0000:00ff:f000:0003  3033.212 ms !A  3033.290 ms !A  3033.254 ms !A
NOTE! that I have changed the IPv6-addresses for privacy reasons. The address ending with 0002 is the servers' IPv6-address, the address ending with 0003 is my client (Mac OS X). The weird thing here is that the traceroute is going for the clients' own address, which should not be the case. I can see on other clients they all go directly to my server, as it's available in the LAN, and don't even need to go by the router (I think this is one of IPv6's new features?). External servers (outside the LAN) still connect to their router first and go on from there (you know what I mean).

I've taken a look at my routing rules after I disconnected from my VPN server with Viscosity still open. They look as follow:
Code: Select all
Internet6:
Destination                             Gateway                         Flags         Netif Expire
default                                 fe80::ae22:bff:fe31:3ac0%en0    UGSc            en0
::1                                     ::1                             UHL             lo0
0000:0000:0000:0000::/64                link#4                          UC              en0
0000:0000:0000:0000::1                  ac:22:b:31:3a:c0                UHLWIi          en0
0000:0000:0000:0000:0000:00ff:f000:0003               UHL             lo0
0000:0000:0000:0000:0000:0000:0000:0003               UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%en0/64                           link#4                          UCI             en0
NOTE! that I have removed and changed some of the rules for privacy reasons. As you can see there is a variation of my clients' address, which does not have 00ff:f000 at the end. This is the temporary IPv6 address, the other one is the permanent, which is assigned by IPv6 auto config. One thing I noticed is that when I ping my server, it's using the permanent address instead of the temporary, is this normal behaviour because LAN connections are not considered privacy? I know that it's using the temporary address to keep your actual permanent IPv6 address private.

I can see it has my subnet '0000:0000:0000:0000::/64' to use link#4, which I have no idea what this does. Has this something todo with keeping the local connections from going through the VPN connection? I noticed I also have this on the 192.168.1.1/32 subnet on IPv4-routing-rules.

I hope someone can help me find out what is affecting my client (Macbook Pro) from connecting to my server over IPv6, while other clients in the same LAN can, as do external clients. I don't have a firewall on the router that is blocking this client in particular for connections to that server, and it's weird that it's working when I reset the Wi-Fi interface (turning it of and on again), even when connecting to the VPN server. It's only after a short while (2 - 3 hours, or maybe when I put my Macbook Pro to sleep and wake it up again) that I start to experience this problems.

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Mon Jul 18, 2016 5:00 pm
Hi Qlii256,

I'd recommend giving the latest beta version of Viscosity a try and see if you have the same issue. It resolved an issue where the IPv6 default route could remain stuck when switching between network interfaces. While that doesn't appear to be the same as what you're reporting, I'd still recommend giving it a try:
http://www.sparklabs.com/support/kb/art ... -versions/

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

Qlii256

Posts: 8
Joined: Sun Jul 17, 2016 11:36 pm

Post by Qlii256 » Tue Jul 19, 2016 2:24 am
Thank you for the reply! I've not installed the latest beta, but even after quitting and resetting (turn off and back on) the Wi-Fi adapter on my Macbook Pro, the problem is still there. It's strange that resetting the interface fixed it before, because now it's still the same issue. Still, my other clients on the same network (all Windows pc's) including my router can ping the IPv6 address just fine.

Could this be something else that is not Viscosity related?

EDIT: Even after a compleet reboot of the system, I'm still not able to ping or traceroute the IPv6 address. I am however able to ping another IPv6 address in the same subnet, what is wrong here? It's looking more and more of an issue with the server itself? But, I have no clue what is going wrong.

EDIT2: I have no idea what is wrong. After some time, without changing anything, I'm able to ping my server from the Macbook Pro again. I have no clue what changed or why I couldn't before. I'm sure it will be back again, so I'll keep this post updated. I'm not sure if this is some sort of issue with or from Viscosity, but I'll do some more research and testing and let you guys know what I found.

EDIT3: I connected to my VPN server again, and after some time, it's stopped working again. My server is not reachable on IPv6 only with my Macbook Pro. I can see that the routing rule to my server is also gone.

The rule was 0000:0000:0000:0000:0000:0000:0000:0002/64 with as gateway the MAC address of the interface on my server, which is ok. Here I could still ping the server. I then connected to my VPN server and everything worked fine. Then 5 minutes later, this exact rule was gone, and I could no longer ping or reach my server over IPv6. I have no idea if it's Viscosity or the VPN server causing this rule to be removed, but it's very weird that it's only this particular IP address.

EDIT4: Sorry for all the edits, but I have some more information. When I reset all my rules and interfaces on the Macbook Pro, I can see the routing rule to my server is added correctly, as described above. I can ping my server with no problem over IPv6. When I connect to the VPN server using Viscosity, it takes about 5 minutes for the routing rule to disappear, and I can no longer reach my server. When I disconnect the VPN connection however, the routing rule reappears when trying to ping the server, except the gateway is no longer the correct corresponding MAC address of the servers' interface, but it's link#4 this time. This is what's causing the ping to fail. But what's even more strange is the fact that the routing rule gets deleted whenever I connect to the VPN (after approximately 5 mins.) and I can also no longer connect.

It has definitely something to do with the VPN connection or Viscosity, but I'm still not sure what. I hope someone can help me with this manner.

Qlii256

Posts: 8
Joined: Sun Jul 17, 2016 11:36 pm

Post by Qlii256 » Sat Jul 23, 2016 5:13 am
Sorry for bumping this thread, but I've found some interesting stuff. First, the problem only occurs when connected to the VPN server using Viscosity. However, it's stays for a long time after disconnecting and closing Viscosity until the routes somehow reset (even a reboot does not instantly help).

The problem seems to be the route Viscosity creates for my IPv6 local devices. This is the exact route:
Code: Select all
Destination                  Gateway
2a02:1811:b200:9d00::/64     link#4
As you can see this is a prefix of my IPv6 addresses on my LAN, and whenever I connect to the VPN server, it sets the gateway to link#4, which I have no idea of what it actually is or means. It has the flags UC with it. When it is working, the route is as follow:
Code: Select all
Destination                  Gateway
2a02:1811:b200:9d00::/64     ac:22:b:31:3a:c0
The gateway is the MAC-address of my router, I think this is how it's supposed to be? Now, whenever I ping on of my local devices, it creates a new route going to the exact machines' MAC-address.

Even with the link#4 as gateway, some local LAN devices are responding to my pings and are in fact getting the right routes. I have no idea why some do and some don't. It seems like some routes stay when pinging to them before connecting to the VPN server, and thereby keeping the right gateway instead of the link#4, but over time they sometimes change to the link#4 and stop working.

I hope someone can help me find out what is causing this wrong routes to be created. And what is the link#4, I can't find any good information about that other then it's some kind of link to an interface.

Thanks in advance!

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Fri Jul 29, 2016 2:19 am
Hi Qlii256,

Have you tried using the latest beta version as per the earlier post?

link#4 would appear to be your en0 interface in this case. If you're using a TAP/bridged setup you may want to consider adding a routing delay, as OpenVPN may be attempting to add your routes before the VPN network interface is ready. For example, to add a 20 second route delay:

1. Open the Preferences window and Edit your connection
2. Click on the Advanced tab
3. On a new line in the commands box enter "route-delay 20" (without the quotes)
4. Click Save and try reconnecting

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

Qlii256

Posts: 8
Joined: Sun Jul 17, 2016 11:36 pm

Post by Qlii256 » Tue Aug 02, 2016 8:19 pm
I've been using the delay for some days now and it seems to be working! I've lowered it from 20 to 10 seconds and it still seems to work. The connection time to connect to my VPN server however is a bit slow now (it's better with the 10 seconds, but it's still a delay...). I wonder how I could improve this further?

Can you explain me more detailed what exactly the problem is and why the routes take a bit longer to be set? Is this the servers or the client's fault?

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Mon Aug 15, 2016 11:45 am
Can you explain me more detailed what exactly the problem is and why the routes take a bit longer to be set? Is this the servers or the client's fault?
Adding the VPN routes before the VPN connection has an IP address will cause the routes to be pointed at the wrong network interface (as if the VPN interface doesn't have an IP address when macOS goes to add the routes no traffic is actually routable through it).

Normally this isn't a problem: either the OpenVPN server assigns an IP address to the connection near-instantly, or a DHCP server assigns an address quickly enough that it's done before OpenVPN goes to create the routes. In this case though the DHCP/IPv6-Auto-Config is slower than the time it takes for OpenVPN to get to the route creation phase. Adding a route delay tells OpenVPN to wait (to allow for extra time to get an IP address) before adding the routes.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
7 posts Page 1 of 1