IPv6 testing
-
was getting the same error on firewall page in logs, your change fixed it for me as well - thanks.
-
I found a small bug. When trying to add an easy rule from the firewall log regarding a denied IMCPv6 request, the rule gets added, but it creates an error since IMCPv6 is not known as a protocol whereas it should be IPv6 with protocol IMCP.
Error:
php: : The command '/sbin/pfctl -o basic -f /tmp/rules.debug' returned exit code '1', the output was '/tmp/rules.debug:193: unknown protocol icmpv6 pfctl: Syntax error in config file: pf rules not loaded'
php: : New alert found: There were error(s) loading the rules: /tmp/rules.debug:193: unknown protocol icmpv6 pfctl: Syntax error in config file: pf rules not loaded The line in question reads [193]: pass in quick on $WANIPV6 inet6 proto icmpv6 from 2001:470:xxx:xxx::1 to 2001:470:xxx:xxx::2 keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View"
php: : There were error(s) loading the rules: /tmp/rules.debug:193: unknown protocol icmpv6 pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [193]: pass in quick on $WANIPV6 inet6 proto icmpv6 from 2001:470:xxx:xxx::1 to 2001:470:xxx:xxx::2 keep state label "USER_RULE: Easy Rule: Passed from Firewall Log View" -
that should have read something like this.
pass quick inet6 proto ipv6-icmp from any to any icmp6-type {1,2,135,136} keep state
where type is echoreq.
-
From the DHCP sys logs:
Mar 15 16:46:27 dhcpd: Unable to pick client address: no addresses available Mar 15 16:46:27 dhcpd: Solicit message from fe80::d136:xxxx:xxxx:b3b7 port 546, transaction ID 0x6F3DF900 Mar 15 16:46:22 dhcpd: Sending Advertise to fe80::xxxx:xxxx:xxxx:50fd port 546 Mar 15 16:46:22 dhcpd: Unable to pick client address: no addresses available Mar 15 16:46:22 dhcpd: Solicit message from fe80::xxxx:xxxx:xxxx:50fd port 546, transaction ID 0xF8444500 Mar 15 16:46:18 dhcpd: Sending Advertise to fe80::xxxx:xxxx:xxxx:50fd port 546 Mar 15 16:46:16 dhcpd: Unable to pick client address: no addresses available Mar 15 16:46:16 dhcpd: Solicit message from fe80::xxxx:xxxx:xxxx:50fd port 546, transaction ID 0xF8444500 Mar 15 16:46:15 dhcpd: Sending Advertise to fe80::xxxx:xxxx:xxxx:50fd port 546 Mar 15 16:46:15 dhcpd: DHCPACK on 10.xx.xx.80 to 5c:xx:xx:xx:xx:fd via em1 Mar 15 16:46:15 dhcpd: DHCPREQUEST for 10.xx.xx.80 from 5c:xx:xx:xx:xx:fd via em1
Still seeing link local addresses in the logs.
I haven't yet identified these devices on my network, but I do know that the 5 machines that are within arms reach are all grabbing IPv6 addys. (lord knows there are enough available)
Is this still just a by product of the in progress dhcp6 status page?
Not really sure what to do about these right now… just disregard? -
Hi,
I found a small error on this page: services_dhcpv6.php?if=lan
If I fill the DNS servers entry on this page, the setting is saved correctly.
But when I want the edit again, the setting does nog show up and is blank again. The input-field is not correctly filled with the setting. -
same problem here, despite no error message in the logs.
another small problem : on the status:dhpv6 leases, I have a line with lease type "active" but IPv6 address, MAC address, Hostname are empty.
in fact, I can't get dhcpv6 to work, everything seems ok on pfsense, but my test computer never gets its ipv6 parameters (address, gateway and dns)
tested on 2.0-RC1-IPv6 (i386) built on Thu Mar 17 07:55:22 EDT 2011
-
another small problem : on the status:dhpv6 leases, I have a line with lease type "active" but IPv6 address, MAC address, Hostname are empty.
Databeestje has posted previously that he has added the DHCPv6 Leases status page, but it is not yet populating data.
You can run ndp -a from terminal or on the Diag -> command prompt page to see your neighbors list.DHCPv6 is working fine here.
Do you see your IPv6 address when you go here?
http://ipv6.he.net/ -
Databeestje, has posted previously that he has added the DHCPv6 Leases status page, but it is not yet populating data.
OK, didn't see his message.
on www.ip6test.com, I see 2001:470:5:492:70f6:95d8:c6b3:863c as my IP address, which is an autogenerated address and not part of my dhcpv6 range.
ipconfig on my windows test box gives fe80::209:3dff:fe11:9176%11 as my gateway
-
Hmm, I'm not finding that post either… might have been a comment on the git page actually... anyhow, that 2001:470:::: is in fact an IPv6 addy you're seeing!
You wouldn't see that there if you didn't arrive with IPv6... you would have seen your IPv4 address.the fe80:: is your link local address.
can you browse to http://ipv6.google.com ? if yes, then you absolutely have IPv6 up and running!
-
yes my ipv6 connectivity is working well, I can browse ipv6 sites, I'm not complaining about that :)
the problem is that my test box works with autodiscovered parameters and not with dhcpv6 assigned parameters
the fe80:… address I wrote on my message is the gateway address shown by ipconfig. My box link local address is another address beginning with fe80:
-
yes my ipv6 connectivity is working well, I can browse ipv6 sites, I'm not complaining about that :)
I think I miss understood your question, my bad.
the fe80:… address I wrote on my message is the gateway address shown by ipconfig. My box link local address is another address beginning with fe80:
Right, sorry… just saw the fe80:... didnt look far enough.
-Sorry about all the edits, I'm on my iPhone and seem to be having issues posting-
-
Regis, somehow I'm glad I'm not the only one having problems getting DHCPv6 to work. Was starting to doubt myself ;) I'm experiencing the same as you do.. DHCPv6 seems to be working.. no errors are reported, but my client never gets a lease. An auto configured IPv6 address works fine. I really have no clue anymore what I can be doing different why it does work with some people, but not with me. If you discover something, please do share in this topic.
-
The manual databeestje provided at his website must contain an error somewhere. It kind of jumps from the left to the right with missing the step in the middle. For example when configuring the WANIPv6 interface he all of a sudden already has a gateway while adding that is dealt with after configuring the interface. And configuring the gateway gives the address not within range error like others already have reported here. Can't believe it did work for some people. They must have done something different. I'm wondering what.
My setup indeed lacked a default route. I already tried adding it manually, but to no avail. I also saw a difference between the assigned IPv6 tunnel addresses between my hacked pfSense 1.2.3 setup and this pfSense 2.0b5 setup. Before I could add the default IPv6 route on the command line, I needed to assign the IPv6 tunnel addresses to my GIF0 at the command line first. What I did:
ifconfig gif0 inet6 2001:470:1f14:xxx::2 2001:470:1f14:xxx::1prefixlen 128
after that, I could manually add the default route for IPv6 using:
route -n add -inet6 default 2001:470:1f14:xxx::1
Just wanted to add I just installed 2.0-RC1 last night, then did the gitsync today.
I ran into the exact same issue after following the instructions - my gif0 was screwy (mask of /64 instead of /128) and no default route.
The errors in the pfsense log were:
php: /system_gateways.php: The command '/sbin/ifconfig gif0 inet6 2001:470:1f06:XXX::2 2001:470:1f06:XXX::1 prefixlen 64 ' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): Invalid argument'
php: /system_gateways.php: The command '/sbin/route add -inet6 default '2001:470:1f06:XXX::1'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add net default: gateway 2001:470:1f06:XXX::1: Network is unreachable'
Now to figure out how to correctly edit the config so it "sticks" after a reboot.
-
Manual changes to the config are no longer required. Since my posting you're quoting above there have been updates from the pfSense developers to resolve that problem. Did you download the RC1 or the RC1-IPv6 version? I would highly recommend the last one. Downloadable from http://iserv.nl/files/pfsense/ipv6/rc1/. With this release you should be ready to go without any gitsyncing or firmware updating.
My gif0 towards HE.net is using the /64 netmask. Are you able to choose the gateway on the gif0 interfaces page? If so and the routing doesn't work (this still happens every now and then), just go to System -> Routing -> Edit your IPv6 route -> Change nothing and click save -> Click Apply Changes and you'll find that the routing does work after that.
-
Manual changes to the config are no longer required. Since my posting you're quoting above there have been updates from the pfSense developers to resolve that problem. Did you download the RC1 or the RC1-IPv6 version? I would highly recommend the last one. Downloadable from http://iserv.nl/files/pfsense/ipv6/rc1/. With this release you should be ready to go without any gitsyncing or firmware updating.
My gif0 towards HE.net is using the /64 netmask. Are you able to choose the gateway on the gif0 interfaces page? If so and the routing doesn't work (this still happens every now and then), just go to System -> Routing -> Edit your IPv6 route -> Change nothing and click save -> Click Apply Changes and you'll find that the routing does work after that.
I installed the 2.0-RC1 mainline last night, then today used the gitsync method to bring in your changes.
I think I just fixed it - in the gif interface config page I entered "/64" for the netmask. Changing it to /128 seems to have fixed everything. I think I was looking at the HE page at the time and figured I should match the subnet, but that's apparently not correct.
The timing on this is great - I just found out a client's colo provider has had v6 up and running for a long time. They just never bothered telling anyone about it. :) Now I can start getting some basic services up there and with pfsense + your changes I can actually test things end to end. Great job, really appreciate this.
-
The gif tunnel is a point to point link and should thus always have a /128 subnetmask. I'll correct the howto.
No need to run the ndp -a command manually, there is now a diag ndp tables page.
-
Databeestje, I was happily surprised to find out after gitsyncing last week that the IPv6 statistics on the frontpage widget started to work. I gitsynced again last weekend and they stopped working again. Are you aware of this and is this a known issue?
-
I did a firmware update instead of only gitsyncing and now the IPv6 statistics work again. I do experience total freezes of my pfSense box since a couple of days though. Every few hours it totally locks up and I have to turn the machine off and on again. Very irritating. I saw there's a new pfSense RC1 IPv6 image. I'm going to try reinstalling pfSense tonight with that image to see if that solves the lockups.
-
I've fixed the statistics issue. I accidentally overwrote the changes, that happens, atleast you can recover them easily with a source versioning system.
On system_services_dhcpv6.php there is a javascript message that should disable all dhcp fields when disabling DHCP or when it's set to "unmanaged". I failed to get this javascript check working. Perhaps you can have a look @Koen.
There is a ongoing effort with the Intel gigabit drivers which are causing some issues. There is also some active IPsec patching work. One, the other, or both of these might be causing this.
If you set the firmware update settings to gitsync after updating the firmware you can get the older binary bits but still get the newer IPv6 code. The images I've made myself are most likely affected with the same issues.
-
Just tried getting my pfSense box to work again. Something is seriously wrong with the releases. When I take the RC1 IPv6 i386 image of the 1st of March it installs well on clean system. When I restore my config I get an error during boot time that my config is from a newer version and I should urgently upgrade. When I just do a gitsync on this version, the whole IPv6 support is gone right after the gitsync as reported earlier. When I do a full firmware update + gitsync + reboot, IPv6 is still gone. When I take the 22nd of March RC1 IPv6 i386 image and clean install that, it works fine after installation. When I just gitsync that, same shit.. IPv6 support is totally gone. I now took the 22nd of March RC1 IPv6 i386 release and just restored my backup without gitsyncing or firmware updating. IPv6 support is still there and no warnings during boot time. I wonder if this brings back stability.
Funny thing is that I have two other pfSense boxes running which I haven't updated (either gitsync or firmware update) for about a month (both RC1 non IPv6 release gitsynced with IPv6 support) and they run smoothly and without any problems with both IPv4 and IPv6. I also didn't have any problems with my 3rd pfSense box which I do update frequently against the latest firmware and gitsyncs since about two weeks ago. So the problems seems to be introduced in changes made in the last month and most likely in the past two weeks. I hope the developers are able to find the cause. I am using IPSec tunnels but am not using Intel NICs by the way.
@Databeestje, I'll be happy to take a look at the JavaScript. How can I do this? Does it require gitsyncing with the latest version and then just checking out the source of the page? If so, I'll set up a new testbox first so it will not disrupt my pfSense home internet router.