2.1 snapshot, my first impressions
-
The DHCP leases are shown in UTC, even if I've set another timezone for the box.
As Chris mentioned that's a bit of ISC-DHCPD fun - We've always just passed that through, but we could conceivably convert that to local time. (Though I'm sure the moment we do, someone will mention that the times in the GUI and the lease times in the file don't match ;-)
Haha…too true!
If you just want SLAAC then "Unmanaged" should have done that, but personally at home I use either Managed or Assisted mode, depending on what I'm doing. I am running an older 2.1 snapshot based on 8.1 for my edge router and if I turn on RA, and my tablet gets an IPv6 IP, as soon as the tablet goes to sleep the firewall will panic/hang. So I tend to keep RA off. :-)
Reminds me, I need to try an 8.3 image to see if that's any better.
Sleeping the tablet makes the firewall hang? Wild.
Anyways, yeah, I wasn't able to get rtadvd working (as in "not in the process table", and no router advertisements in tcpdump) in "Unmanaged" mode. When I went to "Assisted" mode everything worked fine. I'm happy to run that way personally, but I figured that "Unmanaged" mode was supposed to work. :-) I might try to troubleshoot some more in my Copious Spare Time (TM).
I liked the implementation of the Cert Manager, or at least the part
that I used. I was able to generate a CSR and get it signed by my
internal CA and put the cert back up to the pfSense box without any
hassles. One thing I thought was odd was that the input validator on
the Organization (O=) field of the DN didn't let me enter a dot (also
it'd be nice to see something more specific than "contains invalid
characters").There was conflicting information all over the web about what was and was not allowed in those fields, depending on what CA and software you're talking about. So we decided to err on the side of caution there.
Two random conflicting examples:
http://www.hp.com/wwsolutions/misc/hpsim-helpfiles/mxhelp/mxportal/en/admin_cert_server_create.html
http://www.dyndns.com/support/kb/generating_csrs_for_ssl_certificates.htmlI didn't look those references up yet but I will, thanks.
The shell from the serial port menu wanted to print stuff in all kinds
of cute colors which is nice but made things very hard to read in my
terminal windows, which are usually black text on a white background.
Something in me would like to see the shell prompts, etc. in just
plain text.What terminal are you set for? It works for me in Konsole, Putty, SecureCRT, etc, on FreeBSD and on Windows. Though that's just in root's .profile and such, it can be yanked out without too much effort. I mainly access mine over a USB/Serial adapter dangling off my FreeBSD workstation, I run tip from the shell in a Konsole window, or over ssh, and the color has been fine for me there. But I'm sure YMMV there depending on the terminal window options.
Terminal, MacOS X Lion, but it's mostly a coloring issue. The main problem is just that anybody with a white window background is going to have problems reading the parts in grey. If I make the window background black, it works much better. IMHO it'd be better to just leave the colors alone (i.e. don't set them); it's too hard to guess what the user is going to have set in their Terminal / xterm / whatever defaults. But this isn't a big deal; I suffered through many "angry fruit salad" window manager settings in undergrad and this is minor compared to that.
It feels like my net4801 is right on the edge of being able to run
pfSense (particularly due to it having only 128MB of RAM)…I noticed
some entries in the system logs about processes getting killed because
of a lack of swap space (I know there is no "swap space" per se). I
might need to move to a beefier platform.That is a bit light, even a net5501 or an ALIX would still be fine though, it just needs a bit more breathing room on the RAM. Though we do try to keep the RAM usage low, that's getting more and more difficult. I'm running on a net6501 at home right now and it's excellent.
That's good to know, thanks.
Cheers!
Bruce.
-
If you just want SLAAC then "Unmanaged" should have done that, but personally at home I use either Managed or Assisted mode, depending on what I'm doing. I am running an older 2.1 snapshot based on 8.1 for my edge router and if I turn on RA, and my tablet gets an IPv6 IP, as soon as the tablet goes to sleep the firewall will panic/hang. So I tend to keep RA off. :-)
Reminds me, I need to try an 8.3 image to see if that's any better.
Sleeping the tablet makes the firewall hang? Wild.
Yeah we believe it's an 8.1 thing. Same thing happens on occasion to a CARP cluster I manage. The wrong sort of thing happens with IPv6 (usually trying to contact an unreachable IP) and pretty soon it gets stuck in a loop/livelock, will either panic or hang, usually with a bunch of "discard frame w/o packet header" messages from all the NICs on the console. Seems to only happen to me though, just my luck!
Anyways, yeah, I wasn't able to get rtadvd working (as in "not in the process table", and no router advertisements in tcpdump) in "Unmanaged" mode. When I went to "Assisted" mode everything worked fine. I'm happy to run that way personally, but I figured that "Unmanaged" mode was supposed to work. :-) I might try to troubleshoot some more in my Copious Spare Time (TM).
Seems you can make it run by using Unmanaged mode and checking the box "Enable DHCPv6 server" - It won't actually start dhcpd -6, but it will run rtadvd. With some testing I found a bit of an odd mix there. I imagine there may be a couple bits of logic that aren't quite right, or perhaps the wording isn't right. Some people have called for us to split up the RA and DHCPv6 pages, but personally I like having them together.
Here's a quick rundown of a few things I tried:
Disabled -> Unmanaged (dhcpd v6 disabled)
rtadvd is not started, dhcpd -6 not started
Unmanaged (dhcpd v6 enabled)
rtadvd is started, dhcpd -6 not started
Unmanaged -> Managed (dhcpd v6 enabled)
rtadvd is started, dhcpd -6 is started)
Managed (dhcpd v6 disabled)
rtadvd is started, dhcpd -6 not started
Managed -> Unmanaged (dhcpd v6 disabled)
rtadvd not started, dhcpd -6 not started
Managed -> Unmanaged (dhcpd v6 enabled)
rtadvd started TWICE, dhcpd -6 not startedApparently, according to databeesje, when I saw rtadvd running twice it's because the previous run hadn't exited yet, as it waits to send out a message to shut down cleanly and tell everyone it's going off.
What terminal are you set for? It works for me in Konsole, Putty, SecureCRT, etc, on FreeBSD and on Windows. Though that's just in root's .profile and such, it can be yanked out without too much effort. I mainly access mine over a USB/Serial adapter dangling off my FreeBSD workstation, I run tip from the shell in a Konsole window, or over ssh, and the color has been fine for me there. But I'm sure YMMV there depending on the terminal window options.
Terminal, MacOS X Lion, but it's mostly a coloring issue. The main problem is just that anybody with a white window background is going to have problems reading the parts in grey. If I make the window background black, it works much better. IMHO it'd be better to just leave the colors alone (i.e. don't set them); it's too hard to guess what the user is going to have set in their Terminal / xterm / whatever defaults. But this isn't a big deal; I suffered through many "angry fruit salad" window manager settings in undergrad and this is minor compared to that.
Ah, white background would explain that perfectly. All mine are black. You can just kill those lines out of /root/.tcshrc and it'll stop. The prompt, and the variables for ls colors are all in there. I believe the .tcshrc file is preserved between upgrades as well, if I remember right.
-
Seems you can make it run by using Unmanaged mode and checking the box "Enable DHCPv6 server" - It won't actually start dhcpd -6, but it will run rtadvd. With some testing I found a bit of an odd mix there. I imagine there may be a couple bits of logic that aren't quite right, or perhaps the wording isn't right. Some people have called for us to split up the RA and DHCPv6 pages, but personally I like having them together.
Hi Jim–
I'll try that. I definitely did not think of checking the DHCPv6 box until after I went to Assisted mode.
I saw the discussion about the RA and DHCPv6 pages. It's a bit of a weird situation because RA and DHCPv6 are separate but they're somewhat related. I'm not sure which way I prefer, myself.
I broke down and bought a net5501, just turned it up a few hours ago. Of course the interface device names all changed from the net4801 (sis* -> vr*), and I somehow managed to mess up the interface assignments in the serial console, also I think I lost my tunnel interface. Fortunately I had a backup of the configuration, so once I got the net5501 on the network I hacked the XML configuration to change the interface names and restored that back to the box. Yay for having the entire system configuration in one file in an editable format.
Stuff runs a lot better now on the new hardware. Throughput is somewhat better than before, although I haven't stopped to measure this properly. The UI is a lot snappier loading pages, and my RRD graphs now work, also no more mysterious processes getting killed.
The only other thing I tripped on is that the HE.net tunnelbroker updating requires that the IPv4 address of the tunnel endpoint be pingable. (This is not a new requirement but I'd forgotten about it until I got this new hardware, which obtained a different public IPv4 address.) Since ICMP is by default blocked on the pfSense WAN interface, my tunnelbroker updates were silently failing. After I tried this manually from the tunnelbroker.net Web pages, the problem was obvious...I added a pass rule to allow pings to my WAN interface and poked the Dynamic DNS configuration, then everything worked as planned. Wonder if that's worth a note on the configuration page?
Thanks!
Bruce.
-
The DHCP leases are shown in UTC, even if I've set another timezone for the box.
As Chris mentioned that's a bit of ISC-DHCPD fun - We've always just passed that through, but we could conceivably convert that to local time. (Though I'm sure the moment we do, someone will mention that the times in the GUI and the lease times in the file don't match ;-)
I took a stab at this one jimp if you want to check it out over on jithub.com it's in a pull request it another pull request for HTTP to HTTPS redirect for URL names. I added a check box in System: General Setup so the person has the option to use UTC or local time based on time zone for the DHCP Lease time.
-
The DHCP leases are shown in UTC, even if I've set another timezone for the box.
As Chris mentioned that's a bit of ISC-DHCPD fun - We've always just passed that through, but we could conceivably convert that to local time. (Though I'm sure the moment we do, someone will mention that the times in the GUI and the lease times in the file don't match ;-)
I took a stab at this one jimp if you want to check it out over on jithub.com it's in a pull request it another pull request for HTTP to HTTPS redirect for URL names. I added a check box in System: General Setup so the person has the option to use UTC or local time based on time zone for the DHCP Lease time.
Thanks for trying but I'm not sure that's the best way to go about it. It doesn't really make sense to put that option there, it would make more sense either on that page itself, or on DHCP, but since they are separate for each interface, it would have to be global… not sure what's best there. A checkbox on the actual DHCP lease display would probably be the most logical and have the least impact. Keeping the setting in the dhcp section of the config would also make the most sense.
Or the easiest thing to do is just print "UTC" at the end of the lease timestamp and do nothing else. But that seems a bit trollish ;-)
Also, the DHCP part should be on a separate pull request, it's not related to the HTTP/HTTPS redirect. And that pull request can't be automatically merged anyhow, looks like it needs updated for one reason or another, it tells me it doesn't apply cleanly. Each pull request should be distinct in its purpose.
-
I saw the discussion about the RA and DHCPv6 pages. It's a bit of a weird situation because RA and DHCPv6 are separate but they're somewhat related. I'm not sure which way I prefer, myself.
Yeah we keep debating that here too, but ultimately I think keeping them together (to me) makes the most sense, I just wish we could come up with a page title that was short enough to fit on the menu that described both things. I can think of plenty of ways to say it, but none short enough as "DHCPv6/RA" would be.
I broke down and bought a net5501, just turned it up a few hours ago. Of course the interface device names all changed from the net4801 (sis* -> vr*), and I somehow managed to mess up the interface assignments in the serial console, also I think I lost my tunnel interface. Fortunately I had a backup of the configuration, so once I got the net5501 on the network I hacked the XML configuration to change the interface names and restored that back to the box. Yay for having the entire system configuration in one file in an editable format.
In most cases though all you need to do is reassign the interfaces and you're back in action.
The single config file is a lifesaver in many respects. The fact that it's simple to follow plain text XML also makes hacking on it nice and easy. If you were really looking for an adventure, you could have just edited a temp config.xml, pasted the contents over the serial console, then mv /root/yourconfig.xml /conf/config.xml; rm /tmp/config.cache, then reboot. (or put an edited version on a USB stick and mount/copy it from there), then you could skip the intermediate step of getting it back onto the network.
Stuff runs a lot better now on the new hardware. Throughput is somewhat better than before, although I haven't stopped to measure this properly. The UI is a lot snappier loading pages, and my RRD graphs now work, also no more mysterious processes getting killed.
Good to hear it's working a bit better on that hardware. If you think that's snappy you should see it on an atom-based box. :-)
The only other thing I tripped on is that the HE.net tunnelbroker updating requires that the IPv4 address of the tunnel endpoint be pingable. (This is not a new requirement but I'd forgotten about it until I got this new hardware, which obtained a different public IPv4 address.) Since ICMP is by default blocked on the pfSense WAN interface, my tunnelbroker updates were silently failing. After I tried this manually from the tunnelbroker.net Web pages, the problem was obvious…I added a pass rule to allow pings to my WAN interface and poked the Dynamic DNS configuration, then everything worked as planned. Wonder if that's worth a note on the configuration page?
We have a note about requiring ICMP here: http://doc.pfsense.org/index.php/Using_IPv6_on_2.0#Enable_ICMP but which other page were you thinking could use a note for that? The DynDNS config? If your WAN rule (As pictured above) references the "WAN address" macro in the "type" drop-down, then it will follow your WAN IP automatically and you don't need to update it should your IP change.
-
The DHCP leases are shown in UTC, even if I've set another timezone for the box.
As Chris mentioned that's a bit of ISC-DHCPD fun - We've always just passed that through, but we could conceivably convert that to local time. (Though I'm sure the moment we do, someone will mention that the times in the GUI and the lease times in the file don't match ;-)
I took a stab at this one jimp if you want to check it out over on jithub.com it's in a pull request it another pull request for HTTP to HTTPS redirect for URL names. I added a check box in System: General Setup so the person has the option to use UTC or local time based on time zone for the DHCP Lease time.
Thanks for trying but I'm not sure that's the best way to go about it. It doesn't really make sense to put that option there, it would make more sense either on that page itself, or on DHCP, but since they are separate for each interface, it would have to be global… not sure what's best there. A checkbox on the actual DHCP lease display would probably be the most logical and have the least impact. Keeping the setting in the dhcp section of the config would also make the most sense.
Or the easiest thing to do is just print "UTC" at the end of the lease timestamp and do nothing else. But that seems a bit trollish ;-)
Also, the DHCP part should be on a separate pull request, it's not related to the HTTP/HTTPS redirect. And that pull request can't be automatically merged anyhow, looks like it needs updated for one reason or another, it tells me it doesn't apply cleanly. Each pull request should be distinct in its purpose.
Far as doing a seperate pull request for the Time format change it will not let me. It forces me to put the pull request with the HTTP to HTTPS redirect. So if you know how to make it do what you want me to do can you please tell me how to resolve this issue. Thanks jimp!!!
I can move the check box and put it on both the DHCP and DHCPv6 page all I did was modify the function adjust_gmt which is the same in both status_dhcp_leases.php and status_dhcpv6_leases.php files. All the function does is get passed the epoch time when the lease is created then manpulates it either for UTC or local time. I guess that way if you want UTC for all your DHCP and on DHCPv6 local time for those leases you could.
Far as the HTTP to HTTPS redirect can you tell me what I need to fix or modify. I just got tired of typing in just the domain name I set up for the router and it would not redirect it would just sit there and now it works.
-
It feels like my net4801 is right on the edge of being able to run
pfSense (particularly due to it having only 128MB of RAM)…I noticed
some entries in the system logs about processes getting killed because
of a lack of swap space (I know there is no "swap space" per se). I
might need to move to a beefier platform.Report and fix here: http://redmine.pfsense.org/issues/2063
-
Stuff runs a lot better now on the new hardware. Throughput is somewhat better than before, although I haven't stopped to measure this properly. The UI is a lot snappier loading pages, and my RRD graphs now work, also no more mysterious processes getting killed.
Good to hear it's working a bit better on that hardware. If you think that's snappy you should see it on an atom-based box. :-)
Heh. I thought of the net6501 but the net5501 was already an unexpected expenditure.
The only other thing I tripped on is that the HE.net tunnelbroker updating requires that the IPv4 address of the tunnel endpoint be pingable. (This is not a new requirement but I'd forgotten about it until I got this new hardware, which obtained a different public IPv4 address.) Since ICMP is by default blocked on the pfSense WAN interface, my tunnelbroker updates were silently failing. After I tried this manually from the tunnelbroker.net Web pages, the problem was obvious…I added a pass rule to allow pings to my WAN interface and poked the Dynamic DNS configuration, then everything worked as planned. Wonder if that's worth a note on the configuration page?
We have a note about requiring ICMP here: http://doc.pfsense.org/index.php/Using_IPv6_on_2.0#Enable_ICMP but which other page were you thinking could use a note for that? The DynDNS config?
Yes that's what I had in mind when I wrote that, but upon thinking about it, that won't help the people who just nail up their tunnelbroker configuration. And this requirement for ICMP might not apply to all tunnelbrokers (sonic.net, my old ISP, supports IPv6 tunnels but they didn't have that requirement). Finally I should have RTFM-ed. So nevermind. :-)
Bruce.
-
We have a note about requiring ICMP here: http://doc.pfsense.org/index.php/Using_IPv6_on_2.0#Enable_ICMP but which other page were you thinking could use a note for that? The DynDNS config?
Yes that's what I had in mind when I wrote that, but upon thinking about it, that won't help the people who just nail up their tunnelbroker configuration. And this requirement for ICMP might not apply to all tunnelbrokers (sonic.net, my old ISP, supports IPv6 tunnels but they didn't have that requirement). Finally I should have RTFM-ed. So nevermind. :-)
Yeah, hard to find a good place for that outside of the doc wiki really. At the moment HE.net is the only tunnelbroker type in DynDNS so it might be worth mentioning there. Makes me wonder if somewhere there exists a list of which providers require ICMP… Might be time to make a spreadsheet like I had to make for FreeBSD wireless support. :-)