OVH dedicated cloud /56 allocation
-
I've been supplied a /56 address space from OVH for use with our hosted VMware infrastructure and am trying to figure out the most elegant way to break it up.
They provide the /56 and assign their router as a gateway at address x
x:xx00:FFFF:FFFF:FFFF:FFFFI've gotten pfSense configured on WAN using a /64 as they show in their examples, and I can route traffic fine in and out, but I'd like to assign other /64s on LAN.
Because their router doesn't understand that it should route other /64s to me and just throws them out it's interface, is prefix delegation my most elegant way to accomplish this?
If so, should I work with link local addresses on the LAN segment or assign some random /64 to that network for the mapping? -
It appears NPt won't work in this case because it IS NOT a routed subnet, I suppose I have no choice but to use IPv6 NAT in this case?
-
Normal configuration is a /64 on a network or VLAN. With pfSense, you can assign /64s to multiple networks. You just select the appropriate IPv6 Prefix ID for each interface or VLAN.
-
JKnott
I understand but in this case the provider has assigned a /56 and put their router in it. They've provided me the IP address of their router and that is it. If I break the network into /64 segments I can assign the /64 which contains their router on wan just fine.
The main issue I have is that their router doesn't understand that it needs to pass a packed destined for my LAN side /64 to my router for handling inbound traffic. It's looking for it within the /56 and I can't get them to set up any /64 for proper routing.
So I was hoping to find a way to assign the IPv6 addresses to the WAN interface via IP alias and somehow map them to internal addresses on the servers similar to the way I handle additional IPv4 addresses on a WAN interface which are assigned by this provider in a similar fashion.
-
????
Everything within that /56 should be forwarded to you, to do what you want with. Are you using their modem/router as a router? Can it be put into bridge mode? I have a router from my ISP, but I just put it into bridge mode, so my pfSense computer is the first router the packets get to. If I didn't use bridge mode, then I'd only have a /64 to work with.Please don't even think of using NAT. It's a hack to get around the IPv4 address shortage and has no place in IPv6.
So, your first order of business, if I understand your situation, is to put the modem/router into bridge mode and let pfSense take it from there.
-
If OVH did it properly they would send everything to my router for handling. Instead they've just created a subnet, and given me a gateway address.
My pfSense WAN is simply attached to the same network segment as the /56 on their side. They don't have any routes on their end that "send" the traffic to me, it is just dumped on that network segment for handling as they expect all servers to just be "in" than network segment.
The only way to use any ipv6 address from them is to assign it to the interface on the firewall, or attach my VMs with a second NIC to the WAN segment and use the address on them natively.
I'm looking into the possibility of using a second VM to sit on wan with ownership of an entire /64 to handle NPT/routing into pfSense.
-
I'm not sure you understand how routing works. If they are assigning you a /56, then that entire block is sent to 1 router, to be split as needed. As an experiment, on the LAN page, go down to IPv6 Prefix ID and change it from 0 to some other number. Now, see if your LAN prefix changes. It should. This indicates pfSense is receiving the entire /56, as it should. You now have to split off the other prefixes as needed. One way is to just assign them to other interfaces or VLANs. Another, would be to route the rest of the /56 to another router. That should be possible, but I haven't tried it.
-
This might more elegantly explain the issue I have on OVH since I'm not doing a good enough job.
The provider is not routing anything at their end to me, at all. They take their router, assign a subnet on an interface, and attach it to my network. They assign a single IP on their device, and enter no routes on their end, their router doesn't understand that other /64 networks should be sent to my router for handling. They expect my systems to just bind addresses from that pool and use them natively.
http://blog.iopsl.com/ndppd-on-vultr-to-enable-fully-routed-64-for-ipv6/
-
I ended up putting a linux VM on the WAN segment, configured it to run ntppd on debian, configured a route for the /64s I want to use internally, and enabled ipv6 forwarding. It's now acting as an ipv6 proxy router and I can use the /64s behind pfsense properly.
-
IMHO, despite the fact that OVH's delivery concept is fundamentally broken, I think it would make sense for pfSense to incorporate an NDP proxy of sorts to accommodate this type of scenario.
The GUI already has most of what it takes (Firewall->Virtual IP->Proxy ARP (add an NDP type)), and fed into the subsystem.I know there are some individuals who are staunchly against the idea of an NDP proxy in pfSense, but why not increase the use-case scenarios and appeal of pfSense by providing solutions to real-world problems? This forum is full of cases where users have run into this issue.
-
I see no reason for pfSense to implement a workaround for such a fundamentally-flawed scenario as some broken provider putting a /56 on a WAN interface. That shows a complete lack of understanding of IPv6.
I would never, ever host at OVH. The answer is not to work around it. The answer is to make them do it right or go out of business.
Are you certain that they send a neighbor discovery on that interface for every address in that /56?
Or a minimum test would be for prefix00::1 through prefixff::1 on all of the /64s in the /56. A small sampling will be enough to tell.
If they do a neighbor discovery for all those addresses their implementation is completely broken.
If they do a neighbor discovery for another address (probably on the first /64) then send the traffic to that MAC address instead then they are routing to you and you should be able to just use the /64s on inside interfaces.
FWIW AWS VPC/EC2's current IPv6 offering is also unsuitable for routing - at least it was the last time I looked at it. But at least it's only a /64. A /56 on one interface is nonsensical.
-
I agree that the provider putting /56 on an interface doesn't make much sense, but we can't deny the reality that it is happening.
Furthermore, because certain providers are configuring their infrastructure this way, people have had to come up with workaround solutions, consequently an NDP proxy was written for this purpose, but saying things like " The answer is to make them do it right or go out of business. " is just contre-intuitive. OVH and their ilk is not going to go out of business simply because their IPv6 deployment is a bit wonky. People will look for solutions to make it work.Like I said in my previous post, why not provide solutions instead of walls?!
-
Because the solution is not to jump through their hoops, but to force them to make a proper IPv6 implementation. Just dealing with their broken and poorly-thought-out setup is encouraging their bad behavior. If other hosting providers follow suit, it's only because OVH has been allowed to do it by their customers.
OVH customers have to demand, en masse, that they do it properly. Stop bending to their whims and broken designs. Organize customers to make support tickets telling them how broken it is, etc. If you pay OVH money, you deserve a properly routed IPv6 network handoff. A flat /56 is not proper by any standard.
We can't cater to everyone's flawed implementations.
-
jimp,
Your arguments make sense and are well reasoned, yet I can't help notice, although it is completely unscientific, that European users (OVH is based there too) have a pretty high proportion of IPv6 issues, at least if the IPv6 forums here are any indicator, and that these issues frequently pertain to the allocation of flat IPv6 networks without a stub network over which to route them.
It makes me wonder if someone, some academic entity, or manufacturer is disseminating advice over there that runs contrary to what we expect, and its has become a sort-of "defacto" standard.At what point, in your eyes, because whether you like it or not, a "flawed" implementation has become the norm, does it need a solution ?
-
Personally? I hope it never gets "solved". It's a ridiculous design choice that OVH and their ilk need to be forced to fix properly.
As to whether pfSense ever gains an NDP proxy, who knows. Maybe eventually. I am not fond of how the one that just showed up in ports is implemented, though.
