OpenVPN IPv6 not working
-
So I was feeling good about everything but when it came time to implement I ended up with more questions than answers. I'm feeling a bit in over my head at the moment and I know this should be pretty easy. I made up a /48 but am I supposed to enter it somewhere? I used the /48 and made up a /64 that I entered into the OpenVPN server under IPv6 Tunnel Network. That didn't make any difference so I'm obviously missing something. :-\
-
I assume the /64 was one of the 65536 /64s in your /48? When you set up the server, you put the /64 in "IPv6 Tunnel Network". Do you see an IPv6 address on the client?
-
Yeah. So I made up the /48 (ex. fd07:34ac:089d:: ) and didn't enter it anywhere. Then in the OpenVPN server I entered something like "fd07:34ac:089d:78ad::/64" under IPv6 Tunnel Network. When connected to my LAN over wifi I can startup the client OpenVPN app, connect, and get an IP of "fd07:34ac:089d:78ad::1000" along with the IPv4 Tunnel Network IP address. If I try to connect over the cellular network, OpenVPN gives me "CLIENT_IPv6_ADDRESS write UDPv6: Can't assign requested address (code=49)" errors along with "CLIENT_IPv6_ADDRESS Authenticate/Decrypt packet error: bad packet ID (may be a replay)" and then "TLS Error: incoming packet authentication failed" then it just times out.
Edit: this might be nothing but I was playing around with the OpenVPN server protocol setting and the successful connection over wifi only works with the protocol set to "UDP IPv4 and IPv6 on all interfaces (multihome)". The firewall settings only allow IPv6 to the OpenVPN port. And the openVPN client lists the protocol as IPv6 when successfully connected. Just seemed odd to me that it doesn't work on "UDP on IPv6 Only" when the other settings seem like it should.
-
If you tunnel with IPv6 and your cell phone doesn't support IPv6, then you have a problem. I have my tunnel set to use IPv4 as it's everywhere, but IPv6 is not.
-
That shouldn't be the issue. I'm on AT&T and have verified the IPv6 address that my phone gets from them is the same IPv6 address that comes up in any of the "what is my ip" services.
-
That shouldn't be the issue. I'm on AT&T and have verified the IPv6 address that my phone gets from them is the same IPv6 address that comes up in any of the "what is my ip" services.
If it works when on WiFi when you're away from home, but not when connected via the cell network, that's the likely problem. What happens if you use IPv4 for the tunnel?
-
My work only has IPv4 access through it's ISP so I can't test IPv6 connectivity over WiFi there. I'll have to hop on a buddies wifi to test. And to clarify, I've never tested it over Wifi while away from home. My "wifi testing" has been at home on the same network as my pfSense box so everything is local. If I use IPv4 for the tunnel I imagine I will have the problem that started when my ISP enabled CGNAT. That is, no connectivity as my IPv4 WAN at home is 10.10.x.x. Unless you mean testing it locally over wifi and an IPv4 tunnel…but that won't help me once I leave the house.
johnpoz, I asked my ISP if the CGNAT was using 1:1 NAT with all public IPv4 traffic going to all NATed clients. Their response was "No, the information is only sent to the client that sent traffic out. The client sends traffic out and it is NATed to a predetermined port group back to the client". So it sounds like they keep tying my hands at every turn.
-
My work only has IPv4 access through it's ISP so I can't test IPv6 connectivity over WiFi there. I'll have to hop on a buddies wifi to test. And to clarify, I've never tested it over Wifi while away from home.
You seem to have missed my point. My VPN travels over IPv4, as I know that it's available everywhere, whereas the same does not yet apply for IPv6. Regardless, it doesn't matter which is used when it comes to whether the VPN can carry IPv4 or IPv6. It will carry both equally well over IPv4 or IPv6. However, if you have a place where you can test over IPv6, then it will verify where the problem is.
-
Yeah, I don't see how that is different from what I am doing. I cannot establish a VPN connection over IPv4 (while out of the house) because my pfSense IPv4 WAN address is not public (CGNAT 10.10.x.x address) so my open port for VPN is not accessible via IPv4. My home ISP provides the /64 IPv6 address that we've discussed so my pfSense IPv6 WAN address is public and my open port for VPN is accessible over IPv6. I'm aware that a VPN tunnel can move IPv4 or IPv6 traffic equally well. With my android client (AT&T service) I can get a public IPv6 address over the cell network. Yes, AT&T is doing CGNAT on my cellular IPv4 address but that doesn't apply as it is the client, not the server. So to answer "if you have a place where you can test over IPv6", I was assuming that my cell carrier fit this bill.
I used to have my vpn travel over IPv4 but once my home ISP enabled CGNAT, it got totally hosed. Am I still missing something?
-
So to answer "if you have a place where you can test over IPv6", I was assuming that my cell carrier fit this bill.
I forgot your IPv4 is NAT. When testing, it's always best to isolate things as much as possible. For example, here I have an extra NIC on my firewall that I can test OpenVPN through. This verifies it works locally and then I test elsewhere. If it works for you elsewhere, over IPv6, but not through the cell network, then the problem is with the cell network. Are they blocking the VPN? Incidentally, if you're using SSH, you don't need a VPN. Just allow it through the firewall. You can set up SSH to use public/private keys, so that you don't need to use a password, though you still could if you want. I have been using SSH that way for years.
Even IPv4 doesn't always work. For example, I can't use OpenVPN from my local library, as they block everything other than http & https.
-
I've got a spare port on my firewall I could test OpenVPN through if needed (though I avoid it cus it's an onboard realtek. Using PCI intels for LAN and WAN). I'd rather not use SSH as I lose access to internal web pages on my home network but I suppose if it will work then I shouldn't complain because right now I have zero access. I'm using a non standard port for my VPN server. I suppose I could test it using port 80 or 443. I would think if the cell carrier was blocking the VPN that my OpenVPN server logs wouldn't show any attempted connections…unless they block the connection coming back from my server to my phone? My OpenVPN Connect app on the client hangs at "Waiting for server" and never receives any packets, even with several packets leaving the client according to the app. Sounds like I need another IPv6 network to test on...
-
One thing you can do is fire up packet capture to see if the OpenVPN packets are arriving. Try this both from your phone and another network. Why are you using a non-standard port? It's best to keep things default, at least until you get it working. Introducing too many variables makes problem resolution difficult.
-
I can do a packet capture when I get home but the OpenVPN server logs were showing errors referencing my phones cellular IPv6 address. So, to me, that says packets (or at least some packets) are arriving from AT&T. But everything on the client side is silent. A packet capture should also tell me that packets are being sent from the server, and if they aren't arriving at the client then something is happening on the wire. A quick google shows other people with similar VPN issues on AT&T so it's certainly something worth testing. I've been using the non-standard port since I originally had things setup (when my pfSense IPv4 was public). Originally changed it just for "security through obscurity". No real reason why I can't change it back.
-
Ran over to my buddies place during lunch and tested it. Verified I had an IPv6 address from his provider. Used two different client apps (just to be sure it wasn't an app issue) and it gave me the same "Waiting for server". I obviously haven't been able to check the logs on the server but what are the odds two different networks are screwing with my connection? Not that I'm ruling out user error at this point :-\
-
As I mentioned, run packet capture on your firewall to see if the OpenVPN packets are getting that far and being returned. Also, try testing with a notebook computer and run Wireshark on it, so you can see what's happening there. Then check things like IP address, DNS etc. If you can get your VPN working while connected to your home network, then it's likely configured properly.
-
Haven't had a chance to connect to the VPN from a device with wireshark yet but I did do a packet capture in pfSense. I can see the packets (UDP, addressed to my router and OpenVPN port) come in from my client (phone) using AT&T connectivity. That is literally all that happens. Looking at them in wireshark they all have the same payload. It looks like the client just keeps resending the same thing. The router never sends a response. There are no packets sent, with my phone client as the destination IP. I can try to setup the VPN on my machine with wireshark. Not sure I'll get to it tonight but it seems like the packets are flowing. My router just isn't doing anything with them. Possible firewall misconfiguration?
-
Possible firewall misconfiguration?
Good bet. When you tested locally, you might not have been passing through the firewall.
-
I've gone through so many firewall rule variations trying to troubleshoot that I barely know what is what (not being methodical doesn't lend itself to successful troubleshooting, I know). I don't see anything obvious in the firewall rules. Half tempted to just go through the OpenVPN setup wizard again but I don't know if that would even fix the problem I'm having.
![WAN Rules.JPG](/public/imported_attachments/1/WAN Rules.JPG)
![WAN Rules.JPG_thumb](/public/imported_attachments/1/WAN Rules.JPG_thumb)
-
I fired up wireshark and ran openvpn alongside it on a pc on my LAN. Not sure if I'm looking for anything in particular but I see a 54 byte packet go from the client to the server. This is pretty much the same thing that I see with a cellular client. That's the end of the similarities. The pc and router send several packets back and forth and then the OpenVPN client says "connected" The second to last line in the openVPN client is interesting:
Wed Oct 25 22:45:56 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Wed Oct 25 22:45:56 2017 add_route_ipv6(fdf7:a829:80e5:45a9::/64 -> fdf7:a829:80e5:45a9::1000 metric 0) dev Ethernet 3
Wed Oct 25 22:46:01 2017 ROUTE: route addition failed using service: The parameter is incorrect. [status=87 if_index=14]
Wed Oct 25 22:46:01 2017 Initialization Sequence CompletedNot sure if that could have any relation to the OpenVPN Server errors that occur while trying to connect over cellular. Though I checked the OpenVPN server logs with my successful LAN PC connection and everything looks perfectly happy.
I ran another packet capture on pfSense while testing my cellular client (my original capture used promiscuous mode). I was able to see the packet come in on the WAN (without using promiscuous mode). I then tested again capturing LAN traffic and didn't see the client IP (which I shouldn't as the connection happens within the router). Lastly, I tested again capturing OpenVPN Server traffic and didn't see a single line in the output. Totally empty. So the traffic seems to make it to the router and from what I can tell it doesn't seem to be getting blocked, but it also isn't finding it's way to the OpenVPN Server either.
Edit: Apparently I don't get any logs during packet capture on the OpenVPN Server interface…I did a capture while connecting from a LAN client, successfully connected, and didn't get anything logged in the packet capture.
I find it weird that the OpenVPN Server does have logs when I try to connect over cellular, granted they are error messages, but it is at least getting "something" from the client.
Any ideas? Do you think I would have better luck in the firewalling subforum?
Thanks
Edit2: Ran some more packet captures on LAN and WAN interfaces and verified what I think was already said. When establishing the VPN connection from a LAN based client, no client traffic crosses the WAN interface to establish the VPN connection. All of the VPN traffic occurs on the LAN interface.