IPv6 testing

danne

Is there anything I can do to help? Have you defined the tasks to complete for IPv6 support?

wallabybob

@wallabybob:

The failure of the web GUI after this point makes the configuration of the IPv6 tunnel something of a challenge.

Is there a quick patch I can make (to define an IPv6 local hostname?) or a particular snapshot build known to work?

Theres some IPv6 stuff in /var/etc/lighty-webConfigurator.conf around line 128, if you remove that the web-UI will start.

For anyone else who might stumble upon this problem:
After changing /var/etc/lighty-webConfigurator.conf the web server needs to be restarted by /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf

Restarting the system (or web configurator from the console menu) erases changes to /var/etc/lighty-webConfigurator.conf

ariel

What can be done to make those changes permanent ?

FisherKing

This solution might have some negative side effects, but you could set the file so that it is read-only.

chmod 444 /var/etc/lighty-webConfigurator.conf

I see the potential for this to prevent other (good/necessary) changes from pfSense though.

databeestje

it appears that both apinger and lighttpd are still not built with ipv6 support which is causing this issue.
I will investigate.

I will investigate the options

Inferno

Just a notice I got it all to work with my HE net tunnel

Excellent work! (Top gedaan ;) )

xieliwei

@wallabybob:

For anyone else who might stumble upon this problem:
After changing /var/etc/lighty-webConfigurator.conf the web server needs to be restarted by /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf

Restarting the system (or web configurator from the console menu) erases changes to /var/etc/lighty-webConfigurator.conf

For those who want the change to be permanent, you can modify the template script used to generate the configuration in /etc/inc/system.inc . Just do a search for "::" (No quotes). There should be three instances (two of which are for the captiveportal). Comment out the lines taking note of and compensating for the open braces you are commenting out as well.

–-----------------------

I had a problem with how the default routes are set up, it appears to be a copy-and-pasting error in the system_routing_configure() function in system.inc. There were instances where the "v6" portion of the variable names were left out causing a mixing of v4 and v6 configuration; route was not happy.

For those who can successfully ping a v6 host from pfSense but not from LAN, do add a "allow" "IPv6" from "LAN net" to "any" firewall rule.

I'm not sure if an exception had to be made, but when following the instructions from http://iserv.nl/files/pfsense/ipv6/ , I had to change the subnet mask to 126 in the WANIPV6 static address configuration or else the gateway is not accepted by the ui (since it insists that the gateway has to be in the same subnet as the WANIPV6).

Sorry about being so vague, I made these changes without actually noting them down, but I hope it helps someone.

Inferno

@xieliwei:

@wallabybob:

For anyone else who might stumble upon this problem:
After changing /var/etc/lighty-webConfigurator.conf the web server needs to be restarted by /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf

Restarting the system (or web configurator from the console menu) erases changes to /var/etc/lighty-webConfigurator.conf

For those who want the change to be permanent, you can modify the template script used to generate the configuration in /etc/inc/system.inc . Just do a search for "::" (No quotes). There should be three instances (two of which are for the captiveportal). Comment out the lines taking note of and compensating for the open braces you are commenting out as well.

This worked for me as well

Zeon

Just on this section, I had emailed Chris a while ago about this and a possible bounty. I'm really keen to get moving with it and possibly a bounty will speed things up. Any thoughts?

BlueMatt

As version 2 is already in Beta, I highly doubt the team is willing to make such huge architectural changes in version 2. However, according to the bug tracker, Chris Buechler added a feature request and marked it as 2.1 (or next version after 2).
See http://redmine.pfsense.org/issues/177

pfsense_fan009

Do I need to use playback gitsync http://rcs.pfsense.org/projects/pfsense/repos/pfSense-smos
or playback gitsync http://gitweb.pfsense.org/pfsense/pfSense-smos.git
?

@databeestje:

Ok, with the commit I just made to my own (public) repo I can now use ipv6 on my LAN.

A quick howto for getting started, this is by no means comprehensive. And most communication will work as it should, just rough around the edges.

Install a 2.0 BETA4 from the 26th or later, this has a changed apinger binary that supports ipv6 better (at all).
Get to the shell, run option 12, playback gitsync, use the alternate http:// url provided above.
reboot. All the IPv4 connectivity should still work as before.

Create a account with www.tunnelbroker.net for a free /64 account. This works best on a a static or semi permanent ipv4 WAN address.
Make sure that a icmp allow rule is existing on the WAN interface for tunnel assignment by he.net to work.

on pfSense go to assign, create a new gif interface, fill in the correct remote ipv4 remote address and ipv6 local and remote addresses.

Go to assign, press +, you should now have a new OPT interface listed. Call this what you want.
Go to the newly created OPT interface, enable it using config "none".
Go to routing, create new gateway on the new OPT interface, add the remote ipv6 here, check default (this is the 1st ipv6 default gateway). After enabling this the gateway status should list it as green, as well as the dashboard.

You can now create a icmp allow rule on the OPT ipv6 interface to verify that a remote ipv6 host can ping it. http://lg.he.net is helpful here.

Go to interfaces LAN and change the type from ipv4 to ipv4 + ipv6. You can now enter the routed /64 address range given to you by he.net. I just used 2001:470:prefixhere::1 for the lan address, and 64 bits for the subnetmask.

I created a new ICMP rule on the OPT ipv6 interface to allow ipv6 icmp traffic to the LAN IP address. It works!
Next up is generating a rtadvd config for enabling stateless autoconfig on the LAN. After that dhcpd v6.

pfsense_fan009

Is it possible that it's just not compatible with pfsense2.0beta5 ?
When I take url.git and answer master brache:yes, custum:yes I get errors (not reachable)

pfsense_fan009

What do I enter after this last line? (after ulr)

m4rcu5

Hit enter, answer the question about what location it is, and hit enter again.
It will sync, en i think i needs a reboot after that.

-marcus

BlueMatt

The smos repo hasn't been updated in quite a while, and there have been many changes since then. I would recommend you set up proto 41 passthrough and set up an IPv6 router on a separate machine so that you can get the latest updates. You could also apply the commits since smos last updated the IPv6 repo you are using.

databeestje

Merged up with current 2.0 mainline. Still have not resolved the ipv6 support in the binaries from the snapshot builder

Zeon

We have just got 2x /48 subnets setup. One for our rack at one of the datacenters here in NZ (the DC is probably one of the 10 largest in the country and has less than 100 racks lol). The other for our office fibre connction. I will start the experiments!

databeestje

I've added a fix in 2.0 mainline so that it will not remove the default route when you update to a newer snapshot but have a ipv6 pfsense config. With basic connectivity still working it's a lot easier to re-sync against the git repo.

I have not managed to track down the builder issue where binaries are built without ipv6 support.

Cino

I was able to install your git with no issues using 2.0-BETA5 (i386) built on Thu Jan 20 05:02:05 EST 2011 but when I rebooted the box dhcpd wouldn't start. In the log it only gave Exit 1 as its error code. Any ideas?

databeestje

I'll have to check that dhcp issue out, I've successfully had simultaneous dhcp v4 and dhcpv6 active, not sure what broke. Could be a silly user or group thing.

Here is another bit of update.

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.