IPv6 via IPSec
-
Hi,
I'd like to enable IPv6 for my IPSec tunnel (IPv4 is already working fine).
I added a virtual address pool for IPv6: fd00:1:1:2::/64
I chose ULAs because my public IPv6 prefix changes with every reconnect form the provider.My IPSec clients are now able to get an IPv4 and IPv6 address as desired. But what's still not working: If I'm trying to ping6 either the public internet or any host in my homenetwork (all clients got GUAs via the DHCPv6 and SLAAC) the IPSec clients seem to be unable to find a route to the hosts.
I see two possible solutions but unfortunately I'm unable to configure any of those:
- use DHCPv6 also for IPSec so that the clients get GUAs --> I'm pretty sure, that this is not possible with changing prefixes
- setup a static route for the IPv6 IPSec clients --> tried but failed. Is this possible? If yes, how?
Thanks!
Chris -
@b_chris Where IPv6 is a fully routed protocol, ULA can only be used for local communications, nothing will go external. IPv6 does not have NAT functionality like IPv4 does. For local connected networks, if your ISP supports it, you could use Prefix Delegation, but I am not aware of a way to do it with IPSec.
-
@mmapplebeck @b_chris You could select a /64 out of your ULA /48 and use NPt (Firewall > NAT, NPt) to translate a dedicated /64 out of the GUA prefix that is routed to you.
If that routed prefix is dynamic it will have to be updated when/if it changes. Any good ISP will honor your DUID in DHCP6 and give you the same prefix each time. Be sure you save the DUID in your configuration at System > Advanced, Networking. If my prefix changed every time with a proper DUID I would make them fix it.
Also, see RFC4193 for ways to select a globally-unique ULA prefix for each site so you can avoid collisions in the future if you VPN, etc. There are sites like this one that aid in generation.
-
D Derelict moved this topic from IPsec on
-
@b_chris said in IPv6 via IPSec:
I'd like to enable IPv6 for my IPSec tunnel (IPv4 is already working fine).
I added a virtual address pool for IPv6: fd00:1:1:2::/64I haven't set up IPSec on pfsense, but with OpenVPN one tunnel can carry both IPv4 and IPv6. Does that work with IPSec too?
BTW, those ULA are like RFC1918 addresses on IPv4. They don't work across the Internet. As for your prefix changing, have to checked Do not allow PD/Address release on the WAN page? Also, does your WAN address change? That's what you should be using for the VPN end point, if you can.
-
@mmapplebeck said in IPv6 via IPSec:
ULA can only be used for local communications, nothing will go external
It cannot go over the public Internet. Beyond that, it can go anywhere over private networks, just like RFC1918 addresses on IPv4.
IPv6 does not have NAT functionality like IPv4 does
Fortunately. Actually, it may be possible, but it's still a bad idea.
-
@derelict
Thanks for your suggestions.
First: My DUID is configured to "Raw DUID" and I don't have RAM disk activated (also the pfSense-Box doesn't restart between those reconnects), therefore as far as I understand my config should lead to the same prefix. I already had contact with my provider, but their interpretation is: This is a "feature". I should go with a business contract to keep the prefix..Back to topic: May I ask, how the NPt settings need to be configured in detail? I assume the following:
Interface: IPSec
Internal IPv6 prefix: not checked
Address: fd00:1:1:2::/64 (the ULA prefix for IPSec)
Destination IPv6 prefix: not checked
Address: That's probably my current WAN prefix.Unfortunately that doesn't work. When trying to ping from an IPSec client to e.g. pfSense via ping6 I get an timeout. Firewall rules (very basic) should allow the ping.
Thanks
-
General clarification: You all are right, direct communication from an "ULA-client" to the public internet ist of cause not possible.
My main use case would be to communicate via IPv6 with devices within my network that are IPv6-only. -
@b_chris Just a note about using ULA addresses... RFC 4193 recommends that you use a more randomized prefix for a ULA network, because if you were to VPN to another network that uses IPv6 ULA and the prefix happened to be the same, you could have connectivity issues.
The recommended way to generate your ULA prefix is to use the current timestamp + a MAC address, hash it with SHA1 and use the lower 40 bits of the result for your prefix. Here's a link to a page that will ask for a MAC address, then do the rest of the work for you.
https://cd34.com/rfc4193/
Here's another that just randomly generates one (this one also generates a subnet ID, though if you have multiple networks, they should all use the same global ID and different subnet IDs)...
https://simpledns.plus/private-ipv6
This way the likelihood of you using the same ULA address range as someone else is highly unlikely.
The S in IOT stands for Security
-
@b_chris said in IPv6 via IPSec:
My main use case would be to communicate via IPv6 with devices within my network that are IPv6-only.
You can use ULA through the tunnel, just as you can use RFC1918 addresses on IPv4.
-
I use "ps aux|shasum" and pull off then required number of digits. I also go to www.grc.com and use the Perfect Passwords to generate a 63 random character string.
-
@mikev7896 My understanding is that ULA is not 100% like RFC1918 - there is actually another range of IPv6 addresses for that.
If pfSense follows the RFC for ULA to the letter, will it then route the VPN client with a ULA adress to a LAN client that only has a GUA and Link Local?
I thought the point of ULA was that you would need to -also - give all your internal clients a ULA address to be able to speak to a ULA only VPN client.I might be wrong, but thats how I though ULA is RFC’ed
-
@keyser said in IPv6 via IPSec:
My understanding is that ULA is not 100% like RFC1918 - there is actually another range of IPv6 addresses for that.
Not that I'm aware of. ULA is the same as RFC1918 in that it's routeable, but not allowed on the Internet. However, you can't have a VPN over the Internet that uses ULA on either end. VPNs can certainly carry ULA though, just as they can RFC1918.
