OpenVPN IPv6 not working
-
Hi,
I had OpenVPN setup and working over IPv4 between my PfSense box (custom build) and my android phone after exporting the correct file. Long story short, my ISP enable carrier grade NAT (CGNAT) which broke the OpenVPN setup. After a few months they finally enabled IPv6 so I figured I could change my OpenVPN settings from TCP/UDP to TCP6/UDP6 and change the other places that IPv4 is used and that would fix my connectivity issues. I must be missing something because I can't get it working for the life of me. I'm exporting new client files for the new setup. Using the OpenVPN app on my phone and running PfSense 2.3.4. I heard that PfSense 2.4 has some updates to OpenVPN and IPv6 support but idk if my issues are related to that and I'm not sure if I want to update to the 2.4RC although I imagine it is pretty stable. I'm not doing anything too fancy. Home use with some traffic shaping and pfBlockerNG. I have a solid understanding of IPv4 but my IPv6 understanding/use is pretty limited. When attempting to connect to OpenVPN I have my phone wifi disabled and it pulls both an IPv4 (NAT) and IPv6 from AT&T. I have a dynamic DNS domain that is updated with the IPv6 address for the WAN port of PfSense. Not sure if that is right or wrong. At this point I have to imagine I set something incorrectly but I don't know what. Any ideas about what might be causing issues? Common gotchas? Any help is appreciated. Thanks.
-
Do you see anything in the OpenVPN log when your client tries to connect? What about in the firewall log?
If your ISP does CGNAT then it's also possible they are blocking inbound connections to you on IPv6, but you'd have to run some tests to figure that out.
-
Thanks for the response. I will have to take a look at the logs tonight and do some more testing. It's a small regional ISP so I would be surprised if they are doing anything too fancy with blocks and whatnot. Just to clarify, only my IPv4 is behind NAT (I can't imagine IPv6 behind NAT but suppose anything is possible). For the record, my IPv6 address is public and pingable but I know that is not exactly the same as "establishing a connection". I'm using a non-standard port for OpenVPN but I doubt that should make a difference. Thanks again.
-
Do you see anything in the OpenVPN log when your client tries to connect? What about in the firewall log?
If your ISP does CGNAT then it's also possible they are blocking inbound connections to you on IPv6, but you'd have to run some tests to figure that out.
I got home and attempted to connect over cellular to the VPN. It connected right away which was not expected but I'll take it. I didn't have any internet access but it was connected to the OpenVPN server. The OpenVPN logs looked fine but I did notice OpenVPN IPv4 connections being blocked in the firewall. I changed the OpenVPN firewall rule for Protocol from IPv6 to IPv4+IPv6 and things started to work.
I can successfully access local network resources at their IPv4 addresses but I noticed using WhatIsMyIP type tools that my public IP is correct for IPv4 (showing the WAN IP of the OpenVPN server) but my IPv6 address comes up as the IPv6 address that my phone is getting from AT&T.
Shouldn't the IPv6 address be inside the /64 range that my home ISP is handing out? I know with IPv6 everything can have it's own IP address but I was expecting the IPv6 addresses of my home network to be handed to my phone over the VPN as it does with IPv4.
The only thing I can think of is that my Tunnel Settings for IPv4 is 10.0.23.0/24 and for IPv6 is fe80::/64. Should I be entering something other than a link-local address for IPv6 Tunnel Network? Like some part of the range of my IPv6 /64 from my ISP? This is where I start to feel slightly in over my head but I'm happy to learn. Again, any help is greatly appreciated. Thanks.
-
Had some more issues with connecting to the OpenVPN setup. Decided to scrap all of my OpenVPN settings and certs and start fresh. I can connect successfully to the VPN while I am on the LAN side of the network. As soon as my connection is coming from the WAN side, it fails to establish a connection. The firewall logs (System Logs>Firewall) say the block is due to block/1000000105 "Default Deny IPv6 rule". Looking into this, all of my IPv6 connections are being blocked by this rule. IPv6 used to work fine so it must be some change I made. Under System>Advanced>Networking "Allow IPv6" is still checked. Under Firewall > Rules > LAN, I have an allow IPv6 rule above all the other IPv6 rules. See attached screenshot.
The only other stuff I was playing around with at the time was Suricata. In trying to get to the bottom of this I have disabled Suricata, Snort, pfBlockerNG, and a Squid transparent proxy.
Posted here as it is kind of a follow-up but may be better in a different subforum?
Thanks
Edit: about 2 hours later with no other changes made and IPv6 seems to be mostly back to normal. The router IPv6 address has changed a few times over the last few hours so my ISP (a small startup) could've been "tinkering". Still struggling to get OpenVPN to connect from outside the network as my remote device is having it's IP caught in the default deny IPv6 rule.
-
Shouldn't the IPv6 address be inside the /64 range that my home ISP is handing out? I know with IPv6 everything can have it's own IP address but I was expecting the IPv6 addresses of my home network to be handed to my phone over the VPN as it does with IPv4.
With a VPN in tunnel mode, you want different network addresses for the remote, not on the home network. With IPv6, you often get multiple /64s. Use a different one from at home.
-
Thanks JKnott. My understanding is that in order to have multiple /64s that my ISP would have to hand out something like a /56 to each customer. I previously verified with my ISP that each customer is just getting a /64. So I'm not sure what I can do about that.
As far as the blocked remote client, all solicited IPv6 traffic seems to pass. I'm thinking since the VPN initialization is unsolicited, that is why it is being blocked but the firewall rule from the OpenVPN wizard should've fixed that by opening the correct port. At this point, it feels like I must have made a stupid mistake somewhere along the line.
-
"I previously verified with my ISP that each customer is just getting a /64. So I'm not sure what I can do about that."
Just get a /48 from HE and not give 2 shits what your isp is doing with or not with ipv6 ;) Or how bad they are dicking it up, etc. etc..
That they would think users should only get a /64 is just beyond stupid.. Should be allowed to get atleast a /60… That would give you 16 /64 to work with... Which should cover most homes with room to play and segment their wifi networks, etc. etc.
Shoot even the lamest of the lamest wifi routers these days allow for a "guest" wifi network - which would need its own /64 so even billy what is network user would have valid use of 2 /64s..
-
Thanks JKnott. My understanding is that in order to have multiple /64s that my ISP would have to hand out something like a /56 to each customer. I previously verified with my ISP that each customer is just getting a /64. So I'm not sure what I can do about that.
My ISP provides only a single /64, if you use their gateway. However, if it's placed in bridge mode and used with a separate router, up to a /56 is available. Does the same apply to your ISP? Since you're using pfSense, you want to be using bridge mode.
Also, i find first level support often does not really understand what they're talking about.
-
johnpoz, I could certainly attempt to set that up but at this point I think there should be a way for me to get this working without using any HE services, as nice as they are.
JKnott, I just set my WAN to a /56 and the router and my other devices would no longer grab an IPv6 address. I switched it back to /64 and everything came back. So I'm thinking /64 is all I've got. My ISP uses fiber so the closest thing I have to a modem is their media converter from fiber to ethernet. They don't supply a router (which is good as far as I'm concerned) so there is nothing to bridge.
Looking through the firewall logs, the "deny IPv6" I was seeing of my VPN client was a port 53 request. I had setup the OpenVPN server to use my router for DNS. Once I changed the OpenVPN server to use a public DNS provider I'm no longer seeing packets from my client hitting the firewall and being blocked.
JKnott, looking at the OpenVPN logs you might be on to something with the IPv6 address issue.
Here are the OpenVPN server logs with my IP redacted:
Oct 21 12:31:40
openvpn
30854
CLIENT_IPv6_ADDRESS write UDPv6: Can't assign requested address (code=49)Oct 21 12:31:42
openvpn
30854
CLIENT_IPv6_ADDRESS Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1508603499) Sat Oct 21 12:31:39 2017 ] – see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warningsOct 21 12:31:42
openvpn
30854
CLIENT_IPv6_ADDRESS TLS Error: incoming packet authentication failed from [AF_INET6]CLIENT_IPv6_ADDRESS:40549 (via SERVER_IPv6_ADDRESS%em0)Oct 21 12:31:42
openvpn
30854
CLIENT_IPv6_ADDRESS write UDPv6: Can't assign requested address (code=49)Oct 21 12:31:44
openvpn
30854
CLIENT_IPv6_ADDRESS Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1 / time = (1508603499) Sat Oct 21 12:31:39 2017 ] – see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warningsOct 21 12:31:44
openvpn
30854
CLIENT_IPv6_ADDRESS TLS Error: incoming packet authentication failed from [AF_INET6]CLIENT_IPv6_ADDRESS:40549 (via SERVER_IPv6_ADDRESS%em0) -
JKnott, I just set my WAN to a /56 and the router and my other devices would no longer grab an IPv6 address. I switched it back to /64 and everything came back. So I'm thinking /64 is all I've got. My ISP uses fiber so the closest thing I have to a modem is their media converter from fiber to ethernet. They don't supply a router (which is good as far as I'm concerned) so there is nothing to bridge.
Do you have other devices connected directly to the media converter? Or are they behind pfSense? When you change to /56, does your WAN interface still get an IPv6 address?
Also, a quick search shows AT&T providing bigger prefixes than just a /64. Perhaps someone else here has experience with them.
-
There are no other devices connected to the media converter. It only has one ethernet jack and that goes straight to the WAN port of pfSense. All of my devices are behind pfSense. My ISP is a small regional one so all I know is what they tell me (for better or worse). Forgive my lack of knowledge with IPv6. pfSense reports my WAN address something like 2001:0db8:0a0b:12f0:: for example, when I have selected a /64. It reports my LAN address something similar to 2001:0db8:3731:65fe:0e2a:2357:4ac4:0732 where the first two "groups" match the WAN address and the last six numbers/digits match the last six of the LAN MAC address. When I switch to a /56, the WAN address stays the same but the LAN address only lists an IPv4 address. I tested this with setting the prefix size to a /48 and none, and they all reacted the same with no LAN IPv6. Only the /64 gave a LAN IPv6 address.
-
"When I switch to a /56"
It doesn't work that way!!! You can not just switch the mask..
You would request a prefix delegation from your ISP for the size of network you need.. Or they need to give you the info on what it is static… There is NO scenario ever that you would change the mask on an interface to /56..
-
You can select a different prefix size on the WAN interface page. This is done in the DHCPv6 Prefix Delegation size box.
-
I said I lacked IPv6 knowledge…guess it shows haha. Anyway, when I "switch to a /56" I am going to the WAN interface and selecting the "DHCP Prefix Delegation size" box and changing that value.
Johnpoz, it sounds like you are saying the Prefix size should only be changed after I verify with my ISP the size that they are giving me or request a different size and set my Prefix size to match?
JKnott, my assumption was that changing the Prefix size would somehow request that Prefix size from my ISP. It sounds like that isn't the case according to johnpoz.
Thanks for the help guys. Apologies for being a newb.
-
"verified with my ISP that each customer is just getting a /64."
If they are not going to to delegate a /X to you then nothing you can do is going to change that. Be it you request a /56 or /60 or whatever.
Like I said before - if your isp ipv6 deployment is borked.. Why dick with it when it takes all of 1 minute to have a /48 that you can do with as you will.. And just forget your stupid ISP until such time they get their act together.. Which I highly doubt they will for years to come.. Since the vast majority of users are idiot users that just plug in their soho router and see if facebook.com loads on their devices.
The other advantage is this /48 you get from HE is yours - it not going to change.. Even if you have your isp delegate you a /60 or /56, etc. That could change to some other IP block at the drop of hat.. It's not like this /X has been assigned to you and only you like you get with a HE delegation.. HE even allows you setup PTR records on this space - your isp going to allow you to do that?
Your talking about dicking with a borked setup for at best shaving off a few extra ms the tunnel to HE is going to add.
I just do not understand the point of dicking with such a setup when it takes all of 1 minute to have a working setup that gives you complete control.
Another advantage of HE tunnel - is you can move ISPs and not care if they support IPv6 or not, etc. You can move your /48 to any isp you wish to use for connectivity. I have had the same IPv6 space from HE since Jun 20, 2013..
-
JKnott, my assumption was that changing the Prefix size would somehow request that Prefix size from my ISP. It sounds like that isn't the case according to johnpoz.
I suspect he means you can't ask for something that isn't offered. With my ISP, I can request any size prefix up to /56. So, if I only wanted a /60, I could configure pfSense to request that. On the other hand, requesting a /48 would not work, as my ISP doesn't provide that. I have pfSense configured to request a /56.
-
Johnpoz, at this point I agree. It's not a simple fix for me on the ISP side. Just want to clarify you are talking about their tunnel broker service. Do you know right off hand if it'll work with me having CGNAT'ed IPv4 and a /64 IPv6? I'm assuming you wouldn't recommend it if it wouldn't work for me. I'll prolly just Google some setup tutorials unless you can recommend one. Thanks for all the help.
-
JKnott, thanks for the clarification.
-
If you are behind a carrier grade nat for your IPv4. Then you could have some problems with a tunnel.. Is it a 1:1 nat where all traffic is sent to your rfc1918 IPv4?
My bad!! I did not catch the CGNat part… Sorry.. But depends on how the CGnat is being done.
Off the top a way around your shitty ISP.. They put you behind a nat for ipv4 and only give you 1 /64.. Would be to change ISP ;) That is not always an options though..
You could just get a VPS somewhere... There are many that offer /48 with your vps.. Then create a tunnel to this VPS where your the initiator.. Say openvpn tunnel.. Then tunnel the ipv6 through this tunnel.. Its a bit of a hack.. But there are many ways to work around the incompetence of some of these so called ISPs..
-
I can't say for sure that it is a 1:1 nat. I'm happy to test it, if there is a way I can. All I know is that I have a 10.x.x.x address behind a public IP. It's fiber internet so I do see some broadcast traffic from neighbors that share the fiber splitter.
Not to go off topic but as far as my "shitty ISP" goes, they are the only real competition in town. They offer gigabit and the next fastest competitor maxes out at 60mbits from the cable company (Granted the cable company offers public IPv4 and IPv6 addresses). With my ISP the upload speeds are much better too. I would rather deal with these guys than the cable company. The customer service is a lot better. They originally were handing out public IPv4 addresses when I signed up but ran out of them shortly thereafter and started NATing. I don't like it either but I'll deal.
Not looking to sign up for a vps. If I have to spend money, I'll just setup something like teamviewer and deal. I'd rather not, but works in a pinch for my needs (mostly just local access to my machines)
-
Stupid question…I'm making some assumptions based on what I know of IPv4 that probably don't translate to IPv6 but here it goes...I am only using the VPN to access remote machines at home. I don't "need" a public IPv6 handed to my client from the OpenVPN server (assuming that is even right to say), I just need access to a couple machines at the house. Is there any way to accomplish that? When I had OpenVPN setup before my IPv4 address was put behind CGNAT I just used a 10.x.x.x address for the OpenVPN clients while my actual network used 192.168.x.x addresses. Does IPv6 have anything like this? A non-routable address that I could hand out to the client just to provide some connectivity across OpenVPN.
Like I said, I'm probably missing something. I know the fundamental idea behind IPv6 is to NOT need non-routable IP's. Hoping someone can correct any of my misconceptions.
Thanks
-
^^^^
You could use Unique Local Addresses, which are the IPv6 version of the IPv4 RFC 1918 addresses. -
Thanks for the quick reply. I'll try it out tonight. Looks like something in the fc00::/7 block is what I need to use?
Thanks again
-
If all you want is ipv6 access into your local network from your vpn clients then yes you could use a ULA prefixes. But these remote clients will not be able to get access to internet from this ULA address. But you could then NPt that to your /64 you get from isp.. But off the top of my head not sure if possible to nat multiple ULA to a single /64 prefix via NPt? (network prefix translation).. JKnott would know..
What exactly is your end game with IPv6? What are you hoping to accomplish with it?
-
Thanks for the quick reply. I'll try it out tonight. Looks like something in the fc00::/7 block is what I need to use?
Thanks again
While the entire fc::/7 block is ULA, officially, fc:: /8 is supposed to be assigned from a central server and fd::/8 is used with a random 40 bit number you can choose, to create a /48 prefix.
-
If all you want is ipv6 access into your local network from your vpn clients then yes you could use a ULA prefixes. But these remote clients will not be able to get access to internet from this ULA address. But you could then NPt that to your /64 you get from isp.. But off the top of my head not sure if possible to nat multiple ULA to a single /64 prefix via NPt? (network prefix translation).. JKnott would know..
I've never used it, as I'm allergic to NAT. ;)
However, I believe NAT is possible, but not recommended. Regardless, I believe the OP only wanted access to his own network and not the Internet, so ULA, without NAT would be fine
-
End game is secure access to my home network from my devices when out of the house. This basically boils down to SSH access from my android phone to multiple devices on my network. OpenVPN was the easiest way to accomplish this in my mind (at the time) so that I only needed one port open instead of a different port for each SSH server and managing all of that. Originally I had a public IPv4 and all was well. Then my ISP NATed my IPv4 and I was screwed. Then a few months later they enabled IPv6 (/64) and that's where I'm at now. My only need for IPv6 is that my pfSense box now has a public IP. When my VPN was working I would access devices using IPv4 addresses anyway. So my only real need for IPv6 is the fact that it is the only public IP address my router (OpenVPN server) has.
Edit: Beyond SSH access, would also like access to some locally hosted web pages and the pfSense web GUI :D
-
End game is secure access to my home network from my devices when out of the house.
Then ULA will do fine. As I said, pick a 40 bit number to append to fd, to create a /48 prefix. Then assign 1 of the /64 prefixes, from the /48 to OpenVPN. PfSense should be able to route appropriately.
Incidentally, the reason for the 40 bit random number is to avoid the collisions that often happened with the limited RFC 1918 space on IPv4. It's highly unlikely that 2 people would choose the same number. One way to create a "random" number is to go to www.grc.com to the Perfect Passwords page, where you'll find one box that has 64 random hex digits. Select any 10 for your 40 bit random number.
-
Ok cool. I'm familiar with grc.com so I will head over there. Sorry for not leading off with the "end game"…would've saved everyone some time. We will see how this all goes.
Thanks again JKnott and johnpoz for the help.
-
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.