IPv6 Support 400 Euros / $545
-
I'm quite surprised that none of the features listed are supported already. It can only be a matter of time until IPv6 is going to be required rather than someones hobby.
I think a comment from one of the developers is needed here to make sure no one goes off reinventing the wheel.If you're going to spend $500 on your hobby this seems like a great way to do it. ;D
Steve
-
Hi,
I worked on IPv6 in the old pfSense-HEAD. I'll be glad to use the lessons that I've learned to put this feature to the "new" pfSense-HEAD. =)
[ simon.cpu ]
I forgot to mention two minor requirements:
- configuration instructions for the new features. I will provide any desired details about the current network and IP addresses to make this easier.
- WebEx session, not to exceed 30 min, to sanity-check my final config as deployed. I will set up the WebEx.
So, does this mean we have a formal taker for this bounty in simon.cpu and that we should kick off the escrow process?
-
For reference, I have used SimonCPU to do pfSense development work for me before and I highly recommend him. The quality of his work was always very satisfactory.
-
I pinged SimonCPU a couple of times, but so far things aren't really moving forward. Perhaps he is busy. I am still looking for takers for this bounty!
-
There has been quite a lot of activity on the IPv6 build as of the past few weeks.
I was wondering if the build that SimonCPU had started on was going to be merged with Databeestjes' build.
This message pretty much sums it up. -
No idea how that works. Sounds a bit odd. I assume I can skip the ipv4 parts of this config.
I want:
-
all of the above, plus:
-
ability for my external boxes to connect out to the Internet and be
connected to from the Internet using static IPv6 in addition to the
static IPv4 addresses they already have.
If your isp hands you a v6 /64 netblock for the wan interface and routes you a /56 or /48 v6 networkr for behind pfSense you are good to go. This is more dependent on what the ISP will give you. If they are scrooges you get a /64 for behind pfSense.
- ability for my internal boxes to connect out to the Internet from
behind the NAT using both IPv4 and IPv6.
Didn't you get the memo that IPv6 has no NAT?
- prevent any connections from the Internet to the internal boxes, be
that via IPv4 (a function of the NAT) or IPv6.
Same as it always is, unless you create rules on the WAN to allow traffic in, LAN hosts wouldn't be reachable.
- local DNS for both IPv4 and IPv6 provided by pfSense.
Dnsmasq already works fine on v4 and v6 just fine?
- must work with Hurricane Electric IPv6 tunnels. Should work with similar IPv6 tunnels from other providers.
Currently only works with Hurrican Electric tunnels. See my howto at http://iserv.nl/files/pfsense/ipv6/
Deliverables:
- 4GB flash image that does ALL of the above.
- submission of your patches to the pfSense maintainers.
Although I don't build any images, there is no reason why gitsyncing my v6 branch over an existing install wouldn't work. Changes have been made so that you can gitsync on NanoBSD images now as well.
At some point the code tree will be folded and part of the snapshots as usual.
-
-
Here are few clarifications that came out of various off-line discussions:
My ADSL ISP provides me with 8 static IPv4 addresses, but does not offer native IPv6 on the WAN interface. My ISP is willing to provide me with with an IPv6 tunnel similar to those provided by HE. databeestje has seen the configuration instructions for the IPv6 tunnel and believes that his HE tunnel code will work with my ISPs IPv6 tunnels. (It it doesn't, I am fine with that as long as it works with an HE tunnel. Sure, having the IPv6 tunnel provided by my ISP is preferable, since that gives me one number to call if something goes wrong).
While implied by the description of my home network in my original post, let me make it explicit that the traffic to my external IPv4 boxes does not currently run though pfSense. Today, pfSense only provides for local DNS/DHCP/NAT for my internal systems. My external boxes and pfSense are presently connected to a switch that in turn is connected to the ADSL modem. Since the external boxes should receive IPv6 connectivity through pfSense, the likely implication is that the external boxes would need to be connected to the DMZ port of pfSense with pfSense simply passing through the existing external IPv4 addresses while adding IPv6 connectivity.
I am happy to provide a copy of the existing XML config file and, if needed, remote access to the developer.
I am happy to designate CMB as the escrow agent and ultimate arbiter if the requirements have been met. We will of course have to agree on a date by which my home network is either up and running with the requirements in this bounty or the escrowed funds will be returned to me. I am sure we can work out a reasonable time frame.
-
I fully understand that the current v4 traffic for the external network does not flow through your pfSense router.
For properly developing and fixing issues I will need webui access to your pfSense install to debug and fix issues. So that's good. A copy of your XML is very handy for testing and configuring in my lab. This way I can also pre-configure the entire install.- Setting up a bridged DMZ to WAN interfacemakes it possible to move the external hosts without modifying their configuration. There is a big issue with that. See below.
- Setting up IPv6 on a interface that is part of a bridge with WAN will most likely not work correctly and end up causing issues down the road. This means that 2 IPv6 networks would live on the same broadcast domain, this causes issues with router advertisements breaking a lot of things. Although you currently use only v4 on the WAN interface that could become a issue in the future when the ISP turns on it's native IPv6 access on the WAN interface. With a tunnel broker the actual IPv6 configuration is tied to a gif interface and thus should not conflict.
Switching the external hosts to a DMZ interface with private v4 addresses and 1:1 NAT to the external network address will work the same functionally. This is done by setting up either a IP alias, proxy arp or Carp address on the WAN for the 1:1 NAT. This method supports dual stacking the DMZ interface with ipv6 support. This is the recommended configuration.
Please let me know which setup you prefer.
Depending on the other issues that might pop up and the rather significant amount of code involved I believe I can get initial IPv6 working by the end of the month atleast. Considering the amount of code in pfSense I can probably fulfill other requirements by the end of april.
Just to be clear on this, I can not finish an entire IPv6 port of pfSense before the end of April. It is only reasonable that I facilitate the required operational functionality by then. Work on IPv6 in pfSense will continue regardless of the end date of this bounty.
-
[…]
- Setting up a bridged DMZ to WAN interfacemakes it possible to move the external hosts without modifying their configuration. There is a big issue with that. See below.
- Setting up IPv6 on a interface that is part of a bridge with WAN will most likely not work correctly and end up causing issues down the road. This means that 2 IPv6 networks would live on the same broadcast domain, this causes issues with router advertisements breaking a lot of things. Although you currently use only v4 on the WAN interface that could become a issue in the future when the ISP turns on it's native IPv6 access on the WAN interface. With a tunnel broker the actual IPv6 configuration is tied to a gif interface and thus should not conflict.
Switching the external hosts to a DMZ interface with private v4 addresses and 1:1 NAT to the external network address will work the same functionally. This is done by setting up either a IP alias, proxy arp or Carp address on the WAN for the 1:1 NAT. This method supports dual stacking the DMZ interface with ipv6 support. This is the recommended configuration.
Please let me know which setup you prefer.
If I understand your post correctly, Option #1 will only become a problem if my ISP starts offering native IPv6 on the WAN interface. (If there might be other problems with Option #1, please do let me know). My ISP has assured me that there is no chance of them offering native IPv6 on the WAN interface since they cannot replace the DSLAM hardware at the particular location that serves my premises. And that their current hardware is physically incapable of providing native IPv6. Also, if my ISP were to offer native IPv6 on the WAN, I would just switch to using their native IPv6 and therefore would no longer need the ability to serve IPv6 from pfSense to the boxes on the WAN. So I think we are safe here. I also like the fact that with Option #1 I can still use the external boxes without configuration changes should my pfSense box have a hardware failure. I asked my ISP and they are assuring me that no harm will come to the other users that share the /24 since broadcasts are filtered between customers sharing a /24. Then again, I suspect I may be the first customer that is placing a radvd on the WAN interface…
Option #2 sounds slick, but involves a variety of features that I have heard of, but never had a reason to use and therefore am not familiar with. Sounds like it might potentially be a pain for me to debug if something goes wrong down the road.
Therefore, I believe my choice would be Option #1 if the only downside of Option #1 is that I will have to make changes should my ISP ever offer native IPv6 on the WAN. If I am not correctly understanding the situation, please do educate me.
Thanks!
--Lucky -
Option #2 sounds slick, but involves a variety of features that I have heard of, but never had a reason to use and therefore am not familiar with. Sounds like it might potentially be a pain for me to debug if something goes wrong down the road.
It is by far the most complicated option, yes. And it can involve a lot of other issues with FTP and the like.
Therefore, I believe my choice would be Option #1 if the only downside of Option #1 is that I will have to make changes should my ISP ever offer native IPv6 on the WAN. If I am not correctly understanding the situation, please do educate me.
You are correct. with #1 you can feel free to either put the external hosts on a pfSense interface "DMZ" which is bridged or straight on the external network switch. Just make sure that the DMZ switch is not directly connected to the WAN switch ;D
With #1 you can safely provide routed IPv6 on the DMZ and bridge v4 on the DMZ, hopefully I can prevent the v6 advertisements from ending up on your WAN interface by applying a simple firewall rule. That would make it easier as the machines on the WAN switch would never see the broadcast either and attempt to configure a address. I'll have to test such a config ofcourse, but a simple tcpdump should tell me.
Also, with IPv6 the link-local address of the actual interface is part of the router advertisements which should prevent issues.
Let's go with that.
-
To put this thread on pause for the time being, databeestje has begun work on this bounty. Per the FAQ for this forum I placed the amount of the bounty into escrow with CMB, who confirmed receipt of the funds from me.
databeestje already made significant progress towards this bounty in the last few days. If he keeps up this progress (and I have no reason to believe at the moment that he won't), it seems very likely that databeestje will be the one receiving the bounty by completing all the items in the bounty. Keep up the good work!
-
databeestje has delivered on all the items in this bounty and I instructed CMB (the escrow agent) to release the reward.
I am very impressed with databeestje's work and overall helpfulness and patience answering my many questions. Great job!
pfSense 2.1 should have some mighty fine IPv6 support once you folks move to that branch.
