Feature #7746
closed
Proxy NDP
Added by Adam Thompson over 7 years ago. Updated over 1 year ago.
0%
Description
We have "Proxy ARP" VIPs, now we need "Proxy NDP" VIPs to allow pfSense to function with service providers such as OVH who provide an entire /56 but refuse to route any of it, and require NDP adjacency for any and all of it to work.
Files
| ndproxy.ko (18.4 KB) ndproxy.ko | ndproxy.ko built on fbsd 11.2 | Firstname Surname, 03/17/2019 12:13 PM |
Updated by Adam Thompson over 7 years ago
I can't find any evidence anywhere (including tcpdump) that "Proxy ARP" VIPs support NDP. I'm assuming they don't, since I also can't find any evidence that FreeBSD does proxy NDP.
Updated by Jim Pingle over 7 years ago
- Status changed from New to Rejected
There isn't any such daemon. We've had it come up before and it's not possible at this time, possibly ever. It would also enable really bad networking practices that go against the purpose and design of IPv6.
Please discuss these things on the forum, mailing list, reddit, etc, before opening tickets.
Updated by Adam Thompson over 7 years ago
I agree that it's horrible. But I still have a valid use case for such a feature because of someone else's preexisting really bad networking practices. I don't expect it to magically appear tomorrow, I file the FR so the fact that I need a way to handle this is now on your radar. That's what a FR is for: "hey, I need a way to do XYZ".
Rejecting the FR outright is basically saying "You will never be able to use pfSense to handle IPv6 traffic at hosting providers that don't do IPv6 well". The hosting provider in question is the largest private-cloud provider in the world, exactly the scenario where I want to use pfSense because the VMware NSX firewall they provide is even worse at handling IPv6 than OVH themselves.
That's also a pretty remarkable change in policy... maybe having a public bugtracker isn't right for the project anymore? I'm not opening tickets because it's fun!
Just because I'm seeing wrong behaviour that's environment-specific doesn't mean it's not a bug.
Yes, I'm opening bug reports without all the detailed information because that's how my workflow goes here right now - I have to come back and add the details later in the day.
Updated by Jim Pingle over 7 years ago
You can already use other types of VIPs to use additional addresses (IP Alias and CARP) just not for giant blocks of addresses.
I'd rather reject this now and not get your hopes up that it will ever materialize. I can certainly leave it open and let it sit to rot, but I'd rather be realistic.
Discussion before opening a ticket avoids many problems, including:
- It may be a solved problem that you don't know the solution for
- Avoids duplicating existing tickets that may be hard to find
- Making sure it's a sound idea that is (or could be) possible
Making sure we've talked them over first also makes sure we have a better understanding of the problem without cluttering Redmine with the back-and-forth discussion that is much better suited to discussion platforms such as the forum, list, reddit, etc.
It also helps us keep things easy to digest for developers, having to go through a dozen ticket updates to get a handle on the problem is not a good use of anyone's time.
Updated by Richard van Dijk over 7 years ago
It looks like now there is a possible solution of decent quality that can be further built upon to integrate in pfSense! This week the ndproxy kernel module has been added to the official FreeBSD ports tree: https://github.com/AlexandreFenyo/ndproxy
Could you consider reopening this feature request?
Updated by Jim Pingle over 7 years ago
Looking at how that package operates as a KLD and using pfil, I don't see it making it into base. Someone can write up an add-on package for it if they like, assuming it is functional alongside pf/pfSense.
Updated by Firstname Surname over 6 years ago
Ran into the exact same issue (provider only issues a /64 and I give away a chunk of that to mobile VPN clients). If the ndproxy route fails, I intend to write a dummy ICMP6 NS/NA responder. Basically: receive icmpv6, if it's an NS for a defined subnet, reply with the MAC of the interface it runs on.
Updated by Firstname Surname over 5 years ago
- File ndproxy.ko ndproxy.ko added
Richard van Dijk wrote:
It looks like now there is a possible solution of decent quality that can be further built upon to integrate in pfSense! This week the ndproxy kernel module has been added to the official FreeBSD ports tree: https://github.com/AlexandreFenyo/ndproxy
Could you consider reopening this feature request?
I've built ndproxy.ko on a separate FreeBSD machine and have been using it in pfsense since, works like a charm. I have attached the module file, just put it in /boot/modules/
Here's a shellcmd script I call on boot (vtnet0 is the provider uplink):
#!/bin/sh
# load ndproxy
kldload ndproxy
# never checked if this is actually required, but may well be
ifconfig vtnet0 promisc
# define uplink interface
sysctl net.inet6.ndproxyconf_uplink_interface=vtnet0
# grab the hw addr of your side of the link to place in responses
sysctl net.inet6.ndproxyconf_downlink_mac_address=`ifconfig vtnet0 ether | grep ether | awk '{print $2;}'`
# your default ipv6 route
sysctl net.inet6.ndproxyconf_uplink_ipv6_addresses=`route -n6 show :: | grep gateway: | sed 's/%vtnet0//g' | awk '{print $2;}'`
Updated by Yuki Hiramatsu over 1 year ago
Hi, All.
I have again asked for an ND Proxy implementation in Feature #14032.
Does anyone agree with me?