Setup Dual Stack with NAT on v4
-
Hi,
i have problems with setting up IPv6 and IPv4 in parallel.
I have this setup :
On the wan side i have one Public IPv4 Adress and a Public /64 IPv6 Subnet (by provider).
Then I have my PFSense with two interfaces. One for lan and one for wan.I now have setup a private Subnet (10.0.0.0/8) on the lan side.
In the lan setup i am running some VMs.
I now want the vms to a a private v4/32 adress and be nat-ed and a public v6/128 adressIPv6/64 IPv6/64 IPv6/128
IPv4/32 wan –- pfsense --- lan --- 10.0.0.0/8 --- IPv4/32 vmIPv4 already works fine.
But how to setup IPv6.
For this to work the pfsense hase to be a IPv6 Bridge ? i assume ?
Or how to set this up correctly ?And YES each VM should just have one IPv6 adress !
-
The usual way for an ISP to provide IPv6 to consumers is with DHCPv6-PD, which provides a prefix or block of addresses for the local LAN. My ISP gives me a /56 prefix which is 2^72 addresses. You have to configure pfSense to use DHCPv6-PD.
-
As this setup is in a datacenter i only get one static /64 subnet !
I know this sounds odd, but i can't change this.
So there is no DHCP and i have to do anything on my own and static -
How is that /64 provided? Commercial customers will generally have their assigned blocks routed to them, so their own router can connect to the LAN. If they're just giving you a /64 directly, then you don't need to route it locally. Perhaps pfSense can be configured that way, but I haven't tried. You'd still need NAT for IPv4.
-
I would ask them to route you a /48 in addition to the WAN interface /64.
They shouldn't have any issue with that.
-
But /64 should also be more than enough.
I just want /128 per VMSo this will also work with /64 subnet
-
That is fine but it is not how IPv6 works.
Every interface gets a /64.
At a minimum they should put a /64 on the interface and route a /64 to you over that so you can put it on the inside interface for use on inside hosts.
Don't get mired in IPv4 depletion practices when deploying IPv6. They are completely different things. There is no scarcity in IPv6.
-
That is fine but it is not how IPv6 works.
He mentioned he's in a data centre. Perhaps they just gave him a flat /64, expecting devices to use it directly with SLAAC or DHCPv6. In that case, pfSense would need to filter, but not route IPv6. Is that possible?
-
Doesn't really matter where he is. IPv6 is IPv6. If they will only give a single /64 it is the wrong product for the use case.
Not that I know of. Best case would probably be NPt with a ULA/64 on the inside interface. You would have to set up VIPs on the WAN which doesn't scale because you need something out there to respond to neighbor discovery.
A routed /64, /56, or /48 is what you want. Did you ask if that was available?
-
Doesn't really matter where he is. IPv6 is IPv6. If they will only give a single /64 it is the wrong product for the use case.
I'm thinking they might have just split a larger prefix among customers and just routed a single /64 to him. However, we really don't know what's available there and, like you, I haven't seen enough info to know. In the data centre work I've done recently, the customer brought in their own Internet connection via fibre from a carrier, instead of using the data centre's connection.
-
Depends on the sort of DC.. If it is a managed DC where customers services are managed for them.. Customer would have zero control over what the IPs or any sort of firewalls. They might be included in the sort of rules they want between different services of theirs, etc. Bu they would not actually control the IPs or the firewall rules in the DC.. They could request say port X open from this zone or IP to that zone or IP, etc.
If it a colo where customer just gets rack and connection and they do their own thing - then whatever ipv6 you would give them could be directly attached with multiple segments if they did not want to run their own firewall/routers… Or for sure the DC should be able to assign them their own block say /48 or 56 or 60 and let them do their own thing with this.. Any sort of connection other than a directly attached 64 would/should be routed to them.
A /48 might be a bit large to give to someone with a bit of colo space ;) But sure why not.. If they are just using colo space - why not just have their own IPv6 space routed to the DC? They can for sure request their own space from their RIR..
-
A /48 is the minimum allocation for such a thing. If someone in a datacenter asks for it, they should immediately get it. Maybe he's subdividing it into /56s over VPN. There are only 256 of those. There is zero reason for the ISP to care. A "X-Small" ISP allocation is a /32, or 64K /48s.
Again, if it is "here's a /64 for your VPS web server. Have fun," then it is the wrong product for the use case.
There is zero reason not to do it.
It is only 64K interfaces.
 -
I asked the datacenter provider.
I can get oen /56 IPv6 Subnet. But not more.
So how would I need to setup the pfsense to get public v6 to my VMs.
Because there is no DHCP I need to do this static -
I can get oen /56 IPv6 Subnet. But not more.
How they're handing out IPv6 address space is borked.
https://www.ripe.net/support/training/material/lir-training-course/LIR-Training-Handbook-Appendices/IPv6Chart_2015.pdf
-
While they should prob just give a /48 a /56 will work just fine - as long as it is actually ROUTED to you and not just putting the /56 on their interface connected to you… Have seen that a lot around here..
You should get a /64 that you use as transit.. That you would put on your wan interface of pfsense, then just break that /56 into /64's that you put on your interfaces/vlans for your networks behind pfsense.
-
You should get a /64 that you use as transit.
On IPv6, the "transit" network is normally link local. The global is used to access the router WAN interface for management, but nothing else. If you don't enable remote management via the WAN interface, that address serves no useful purpose. Unlike IPv4, link local addresses are normally used for routing on IPv6.
-
While I agree that sure you can use link local for your transit.. I don't agree with that being a good option. There is ZERO reason not to make it a actual viable address. For starters so that your traceroute is valid.
I can use rfc1918 as my transit to route public IPv4 as well - doesn't make it a good idea.
-
On IPv6 a link-local gateway address is what you get more often than not and it's completely valid and according to the specifications.
This is on my Mac:
route -n get -inet6 default route to: :: destination: :: mask: default gateway: fe80::21b:21ff:fea6:4244%en0 interface: en0 flags: <up,gateway,done,prcloning>recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0</up,gateway,done,prcloning>That's configured with plain SLAAC.
-
Again I hear you… So? Read https://tools.ietf.org/html/rfc7404
It clearly goes over the advantages and disadvantages to doing it that way.. There are many ways to skin a cat, I don't like skinning the cat that way because it has issues that I would rather not deal with...
Its not like you have to worry about running out of space by using up a /64 for your transit..
-
While I agree that sure you can use link local for your transit.. I don't agree with that being a good option.
Take a look at your routing table. You'll see it uses link local, not routeable addresses In fact, on point to point links, you don't even need an IP address at all, just the link. On IPv6, routing via link local addresses is the default, not an option.
