2.1 snapshot, my first impressions
-
I'll skip over a few things that Chris answered already
Reboot System: "The system is rebooting now. This may take one
minute." Um, not on my pokey net4801 it doesn't…it's more like 3.5
minutes. :-)Touche'. That is less and less true these days too, even on fast server-class hardware it can take a bit. Perhaps I'll put "or two" on the end. :-)
https://github.com/bsdperimeter/pfsense/commit/a86c158d032aa1d9255eb1db59217fb39c2980e8Firewall rules => Floating: "No rules are currently defined for this
interface". Huh? That phraseology doesn't quite seem to make sense
for this page…I thought these rules could be bound to multiple
interfaces.Yeah that doesn't quite hold true on that page. I just fixed it:
https://github.com/bsdperimeter/pfsense/commit/7be4635326d45a8bbcd653d8795e31fc4c70b32fThe 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 was pleasantly surprised to see the HE.net tunnelbroker as a DynDNS
choice (well technically it's not a DynDNS system, but I understand
why it's grouped together). A nice feature, and better than the
updater script that I had been using.I added that because both of my WANs were dynamic and after about the third time of booting up with no IPv6 (or recovering from a WAN outage) I got tired of manually updating it on the he.net page. DynDNS may not be a 100% fit on the name, but the resulting action is perfect.
We've had a little discussion about ways to make connecting to he.net or similar easier, either adding a bunch of fields on the WAN page with a tunnelbroker WAN type (much harder to code, but easier for the user) or maybe a wizard to set it up. Not sure if we'll get to simplify that much at all. While the config is straightforward, some of the locations aren't exactly intuitive for users. We do have several docs out there about setting it up though.
The DHCPv6 page was a little confusing. Initially all I wanted was to
have rtadvd running so I could get SLAAC (i.e. "Unmanaged"), on the
basis that this is what I had before. However I wasn't able to get
router advertisements to work with DHCPv6 disabled, so I ended up
enabling DHCPv6 and going to "Assisted" mode. I was a little confused
about why I needed to specify a Range for the DHCPv6 server in
Assisted mode, but perhaps I just don't understand how this is
supposed to work. I wanted a knob to set the rtadvd priority to
"high" but didn't find one (this isn't critical, but would be nice).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.
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.htmlFinally, I noticed that after the validator rejected my
input, the key length of the CSR went from the default of 2048 down to
512. That seems like a bug to me.So the first time you submitted the CSR it was set for 2048, but when it displayed the error the key length reverted? I did a ton of work on the Cert Manager but the CSR code is probably the least touched by me, since I don't use external CAs. If I can get more detail about how to reproduce it I can look at it, but as Chris said, that's worthy of opening a bug report at http://redmine.pfsense.org with some info about how to make it happen.
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.
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.
Anyway, that's the end. To all the developers, many thanks for making
this thing, you've done a nice job. I'll be very happy if pfSense can
can put me out of the business of maintaining my own firewall
appliance and it looks like it's well on its way there.Thanks!
-
@cmb:
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's a reason for that, but it escapes me at the moment. Those legitimately aren't valid characters for some reason in some circumstances.
Got it. It seemed very strange particularly since when I generated CSRs using OpenSSL command-line tools, it wasn't a problem. (Hrm, have to go see what my company's product does in this area, particularly since I thought I understood this part.) I see where jimp had some additional comments in this area.
@cmb:
Finally, I noticed that after the validator rejected my
input, the key length of the CSR went from the default of 2048 down to
512. That seems like a bug to me.yeah, feel free to open a bug report at redmine.pfsense.org on items like that.
Wilco. I'm going to try to come up with a minimalistic way to reproduce it.
@cmb:
While I was trying to get my firewall rules working right, I was at a
loss to see how to debug ruleset problems through the web
Configurator. I finally gave up on this and just fired up a shell on
the serial console and did "tcpdump -i pflog0", which is what I used
to do on the old system. Is this the intended debugging method, or
did I miss something?Status>System logs, Firewall will show you the same as pflog0 is showing.
Aha, thank you. I need to learn how that data is being presented, but now I know where to go look.
@cmb:
I have the NTP server enabled and apparently running, but I'm unable
to get it to serve queries from ntpdc, even with all of the interfaces
selected as listening. All I'm trying to see is to see if the NTP
daemon is actually synced with the configured timeservers and I'm not
seeing a way how to do this.welcome to the fun world of openntpd. It silently refuses to sync clients for the first few (2-3 maybe? don't recall for sure) hours until it's happy its time is synced. tcpdump the traffic and you'll see that I suspect.
Hrm. I think ntp.org ntpd is somewhat similar with respect to syncing clients, but all I really wanted is to do "ntpdc -p" so I see if the daemon really succeeded in syncing to one of the configured servers (in my case I don't care if it can serve clients). I'll play with this some more. As of now, "ntpdc -p" still gives me a timeout, and I had the system running overnight, untouched. It looks like it's synced but I don't have any way to tell that.
@cmb:
yeah 128 MB RAM has gotten to be a bit light. PHP takes a good chunk of that, I'd like to see some resources put towards shrinking that footprint a bit, but not sure it'll happen by 2.1 release.
Might be time for me to hunt around for change under the sofa cushions then. :-)
@cmb:
If you're not careful, you'll just get into helping maintain a bigger project I hope. ;)
In all seriousness, always glad to see @freebsd.org folks here, and appreciate your feedback.
Heh. Just for the record, I'm no longer a FreeBSD developer type person due to an extreme lack of time, although I still consider myself a very enthusiastic user / supporter. It's great to see systems such as pfSense built on top of FreeBSD!
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 ;-)
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. :-)
