WAN with /64 Delegation
-
@meluvalli said in WAN with /64 Delegation:
It can only hand out Stateless and Stateful IP addresses with a LAN Prefix already defined in the gateway. It doesn't appear to "bridge".
My guess is, that thing isn't in bridge-mode, maybe doesn't have it at all.
Anyways, if it uses the /64 for its LAN, then you can not use that /64 a second time. You only have IPv6 on your pfSense WAN-Address.
So the only thing you could do is to NAT that one IPv6-Address on your WAN the same way you already do with the IPv4-Address on WAN.
With that you will not gain any benefits you usually get with using IPv6. But if you really really want to use IPv6, you can do it like that.
For this to work, go to FirewallNATOutbound (not NPt), select Hybrid Outbound NAT and then mimic all the Automatic Rules for IPv4 with IPv6 yourself. You have to use ULAs on all your LANs. -
@Bob-Dig
Ok. That's what I was thinking. And I also attempted that once and couldn't get it to work. But, I will try that route again. I understand I wouldn't get all the benefits of IPv6, but at least my clients would be able to access a website that is strictly only IPv6 this way...So, to NAT it, I would just assign a static IP address then on the LAN side just as I would with IPv4 correct?
So for example, If I chose a prefix of fd00:0000:0000:0001, I would use Static IP of fd00:0000:0000:0001::1/64 with no gateway in pfSense on the LAN side and then all clients would have to have an IP of fd00:0000:0000:00001::/64 subnet with the gateway set as fd00:0000:0000:0001::1.
Then, as you stated, in Outbound Nat, I would create a rule on WAN interface with Source: fd00:0000:0000:0001::/64 NAT Wan Address.
Does this sound correct to you?
-
@meluvalli said in WAN with /64 Delegation:
But the WAN and LAN can't both use the same Prefix can they?
See it like this, using some twisted IPv4 analogy :
No, you can't have a LAN using 192.168.1.1 and a WAN using 192.1568.1.2 - that will break routing entirely.@meluvalli said in WAN with /64 Delegation:
So how would one ever get a /64 prefix to work if that's all that's provided by the provider?
That's the good question.
If an ISP providing just one /64 then that is actually completely wrong.@meluvalli said in WAN with /64 Delegation:
That seems strange!
Not really, its more like the same story all over again.
Like the early IPv4 days, when it became clear that "there might be not enough IPv4 for everybody".
NAT didn't existed yet. It was patched together later on by a simple guy who didn't realize that he just saved the Internet so it could serve the planet for a couple of decades more.
IPv6 was build from the ground up with a lot of knowledge already known. It's somewhat a written rule that every ISP end user should have a /56 or even a /48 (he.net does so).
Just offering a /64 is lie,; saying : just one 'LAN' network for you. This LAN network is the LAN of your ISP device, so, as usual, a user @home can now add 18446744073709551616 devices to its LAN.
If one of these devices is a router, it will need a IPv6 from this LAN and another block (prefix) of /64 of each LAN network (there can be more the one).
The thing is : this isn't implement well (understatement) by many ISP/their equipment.
Dono why ...
Maybe a simple /64 is for "home user", and if you want more, you have to sign up for a pro (?) subscription ? Something like that.No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@meluvalli They are called ULA for a reason. But technically you are not wrong.
Do it something like this:
LAN1= fd42:1966:a4fc:5941 : f866:8ab8:5f3b:1a61 /64
LAN2= fd42:1966:a4fc:5942 : f866:8ab8:5f3b:1a62 /64
LAN3= fd42:1966:a4fc:5943 : f866:8ab8:5f3b:1a63 /64
LAN4= fd42:1966:a4fc:5944 : f866:8ab8:5f3b:1a64 /64 -
@Bob-Dig
Perfect. I was able to get it up and running using NAT! All my clients can get out on the one single IPv6 address my pfSense has on the WAN side.Now for my next project... Incoming port forwarding.... I expected it to work the exact same way as IPv4 does using Firewall/NAT/Port Forwarding, but for some reason, it isn't that simple.... I guess back to the drawing board for that part :)
Either way, thank you so much @Bob-Dig for your help! I at least got my outbound IPv6 up and running!
-
@meluvalli said in WAN with /64 Delegation:
Now for my next project... Incoming port forwarding.... I expected it to work the exact same way as IPv4 does using Firewall/NAT/Port Forwarding
Actually it is. If it is not working it may be a problem with your ISP? It has been some days (years) when I ran pfSense like this though.
-
@Bob-Dig
I did a packet capture in pfSense for port 443 (It's a website) and it sees it coming in, but never gets to my server... So I know the ISP isn't blocking it... It's got to be something I have screwed up :(. I'll keep looking into it! Again, I really appreciate your help! Thanks again! -
@meluvalli said in WAN with /64 Delegation:
I expected it to work the exact same way as IPv4 does using Firewall/NAT/Port Forwarding, but for some reason
IPv6 - if implemented correctly, doesn't need NAT anymore.
Just a firewall rule on the WAN that says :
As the WAN interface will be "all the prefixes" so, a /56 or whatever
and- example here -the alias DiskSaton2IPv6 is the GUA IPv6 (an IPv6 in one of my prefixes used on one of my LANs)
this is all it needs to make it accessible.
There is no more Network Address Translation. You can of course still use Port Address Translation, like port "443" to "8443"
After all, the IPv6 my Diskstation2 is using is an IP address that is usable (addressable) world wide. -
@meluvalli said in WAN with /64 Delegation:
I did a packet capture in pfSense
I did too and it is working. Now I don't run anything on that IP, will have to look if I find something to test easily.
-
@Bob-Dig
I got it working! It was my Linux server didn't have the gateway set :) Once I inputted the gateway for IPv6 all is well!Thanks again!!!!
-
@Gertjan said in WAN with /64 Delegation:
If an ISP providing just one /64 then that is actually completely wrong.
Not completely.
If you have only one /64, it is still good for some NPtv6. Because with that there is some end-to-end reachability for outgoing.
The firewall has not to "change ports" for outbound traffic, as long as real ULAs are used.Example: Lets say we have 3 interfaces with ULAs:
fd1::123
fd2::456
fd3::789fd2::456 gets translated to 2001::456 and goes out to google.
Now the firewall has a firewall state for google and fd2::456.
When traffic comes back in from google to 2001::456 it will be translated to all three ULAs. Two will be dropped but one will pass because there is a state.At least that is how I think this works.
For unsolicited incoming traffic this is not done, maybe it is to dangerous? It will be translated only to the first ULA-Prefix in the list.
Maybe I made this up and there is a NAT-Table for NPT, although it is said that NPT is stateless.
@stephenw10 can slap me if I am wrong. But I do think that you can use one GUA-/64 and use it with several ULA-/64 in pfSense for outgoing. Would be interesting to know how that is actually working.
-
@meluvalli said in WAN with /64 Delegation:
Unfortunately, IPv6 has very limited configuration in the gateway itself.
Is it in bridge or gateway mode? You need bridge mode. ISPs use DHCPv6 to provide a prefix to a router, such as pfSense. However, gateway mode will not pass it. Your ISP should have a /64 on the WAN and hand out a prefix.
I've been using pfSense for about 8 years and it works fine with IPv6. In fact, IPv6 was the reason I switched to it, as the Linux based firewall I had been using wouldn't work with DHCPv6.
-
@meluvalli said in WAN with /64 Delegation:
I got it working! It was my Linux server didn't have the gateway set :)
The gateway should be provided automagically by pfSense, using router advertisements.
-
@JKnott said in WAN with /64 Delegation:
The gateway should be provided automagically by pfSense, using router advertisements.
That is true, you should activate Services>Router Advertisement on all interfaces with IPv6. Unmanaged probably will do.
-
@Bob-Dig
I'm using RA in Managed mode. I also have enabled DHCPv6 Relay. I have a DHCP server that hands out IPv6 addresses because I prefer to have managed IPv6 addresses so I know the IPv6 address of each client statically. I then assign IPv6 addresses based on UUID.My servers I have set for STATIC IPv6 addresses instead of DHCP.
Only problem I have seen with this setup is some devices (Like Google Display Hub) do not get an IPv6 address. I am not really sure as to why though since all my Windows/Linux devices can get an IP via my IPv6 DHCP Server.
-
@meluvalli said in WAN with /64 Delegation:
I have a DHCP server that hands out IPv6 addresses because I prefer to have managed IPv6 addresses so I know the IPv6 address of each client statically.
I only do that for my servers. But in a NAT scenario I wouldn't care.
Thanks to @JKnott everyone around here knows that Android is not supporting DHCPv6.
-
Yah. I think I remember reading that somewhere :) But, my AppleTV doesn't either (Odd considering my Macbook and iPhone both do though.). So... Google isn't alone...
-
@meluvalli said in WAN with /64 Delegation:
I have a DHCP server that hands out IPv6 addresses because I prefer to have managed IPv6 addresses so I know the IPv6 address of each client statically.
Use SLAAC. It just works. Thanks to some genius at Google, Android doesn't support DHCPv6. Also, with SLAAC, you get 1 consistent address, which can be based on the MAC address or a random number. You also get up to 7 privacy addresses, with a new one every day. The most recent is used for outgoing connections. Use the consistent address as static, as it is, unless you change the prefix.
-
@JKnott
On my network I am using dnsdist and use specific DNS servers based on source Address (local client). If I use SLAAC and the IPv6 address changes on the client, then dnsdist wouldn't be able to determine the client and would use the wrong DNS server for that client. That's why I am using DHCPv6 with assigned IPv6 addresses based on UUID. -
OT: Maybe you don't want IPv6...
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38063
