[Announce] Prelimenary IPv6 Support in pfSense

[databeestje]

Hi,

Just as a pointer to people that are interested in using IPv6 with pfSense in correspondence with the HE.net tunnelbroker.

It's now possible to use a experimental git repo with pfSense 2.0 BETA 4 so that you can terminate the ipv6 tunnel and succesfully firewall incoming and outgoing ipv6 traffic. All is explained in the forum post I've made on the pfSense forum.
http://forum.pfsense.org/index.php/topic,26469.0.html

The support is rough around the edges as it touches everything inside and out of pfSense, hence the reason it isn't on the 2.0 roadmap. But it is the 1st feature of the 2.1 roadmap.

It's arguably taken way too long to get the support this far. The good news is that basic connectivity at this point should work just fine. It does for me atleast. I too am at this point baffled by the lack of support from the large internet providers, including my own.

This might just be the 1st step in getting there.

Regards,
Seth
pfSense developer

[jimb]

Good news.  'bout time.  :P

[lukec]

Above you include:

I too am at this point baffled by the lack of support from the large internet providers, including my own.

I believe the answer simply to be "Comercial viability"... Costs alot to implement, and until the question "how will this improve my revenue figures?" gets answered uptake will be slow. Content providers benefit significantly more than ISPs, although the mechanisms between the two are changing...

It is getting better - and certain "carrier/ISP"s implement mechanisms for revenue generation that weren't implemented in IPv4 peering...
Or someone comes up with the next "killer app" that only runs on v6
regards
lukec

[coltexbv]

Here is a howto to help in setting up a IPv6 tunnel with the Hurricane Electric tunnelbroker on the experimental pfSense 2.0 branch.
http://iserv.nl/files/pfsense/ipv6/

Regards

[databeestje]

I have slowly been building out support in pfSense, it can do CARP with ipv6 addresses for redundancy now and a test cluster I've built has been working fine for over a month now. That cluster is providing connectivity for a Nameserver, webserver and mailserver. Basic firewalling and routing is working as it should.

I have also been working on the Multiwan support for IPv6, this appears to be biting a number of small business networks or home users that have more then 1 internet connection.

For this I have implemented "Network Prefix translation" (NPt previously NAT66) support. The way this works is that you can use a ULA range on the LAN networks (I registered my ULA range on sixxs.net). The network prefix translation then replaces the left 64 bits of the network prefix with the global unicast range when traffic goes out onto the internet. It performs the reverse step for traffic directed to the global unicast address which is then mapped the correct ULA address.

In my test setup I have 3 WAN networks, each with their own global unicast range. Using this method all LAN devices have just 1 address and the pfSense firewall will perform all policy routing, this takes away all the need for intelligence on the LAN devices. This also makes all LAN devices directly reachable over either of the 3 internet connections. As long as I make firewall rules that permit the traffic ofcourse.

This is, in my opinion, a huge step forward for management of the network.

Never ever needing to change the local LAN addressing is a huge step in right direction.

[jimb]

Hehe.  There's going to be some people annoyed at you for promoting NAT under IPv6.  :P

I might have to look into pfsense though.  Been running iptables forever though.

[databeestje]

I wouldn't say promoting, but the internet and networking is a complex thing. One approach to everything doesn't always fit.

Also note that Network Prefix translation is not the same as the NAT we do on ipv4. In IPv4 we put an entire LAN behind a single public address.

What happens with network prefix translation is that you can still use the various /64 networks on or more of your lans and map them to a corresponding /64 from the global range. It basically behaves like a giant 1:1 mapping.

You can find the draft for it here. http://tools.ietf.org/html/draft-mrw-nat66-06
They are now recognizing that it just is not feasible for all organizations to get a IPv6 PI space, or BGP on (all) their connections.

In this case I can map my LAN onto 3 different WAN connections and still maintain my single point of management of the traffic before it leaves and enters the network. It needs to stay manageable. I can't have all machines making random use of internet connections. That's madness.

[jimb]

Yep understood.  But it will still rankle some ppl.  Post about it on the NANOG list, and be prepared for a 100 post thread.    ;)