One way of looking at it is: i386 is the instruction set of the old Intel 80386 and various extensions. AMD64 is the i386 instruction set with extensions for additional registers, 64 bit registers, 64 bit virtual addresses etc.

Most recent "i386" CPUs also understand the AMD64 instructions so are capable of running either i386 kernels OR AMD64 kernels.

For applications like pfSense I suspect in most cases there is little or no gain in using AMD64 kernel over i386.  One exception though, would be "heavy duty" firewalls needing to keep large numbers of connection states and thats because the AMD64 instruction set allows the kernel address space to grow much much larger than the size allowed by the i386 kernel.

Stick with i386

I'm guessing there might be support for the VM to take advantage of the TOE-part of the chip aswell maybe.
I'll have to do some reasearch on that.

I don't have a highend datacenter, but I do have a hobbist garage :-)

http://0o2471.net/16220

@kpa:

PfSense is certainly not creating a windows domain but the default DNS domain which is .local may not be what your windows hosts expect. You can change the DNS domain at System->General setup.

Thats it ! Thanks !!

Thanks, that did it :)

@rcfa:

So I know that the card isn't totally fried, I know the OS recognizes it, I know the cables are OK and I know the configuration isn't to blame for the matter.

What I don't know, if there's a plausible way for a card to fail such that both interfaces are visible, and one of the interfaces is damaged enough to only pass a small amount of traffic, rather than no traffic at all.
Basically, I'm trying to figure out, if this could potentially be a driver issue (I'm on an amd64 install).
I can try to track it down by swapping the nic card into some other system and/or moving to an i386 install, but both of these are going to take major amounts of time, so if there are known issues with cards like these, now would be a good time to know, before I spend the better part of a day taking the system apart, switching components, reinstalling the OS, etc.

Also, if you have any other ideas on how to test this matter further, I'm all ears and eyes…

Inspect the RJ45 jack's and look for any deformation of the pins. Or maybee some "dirt" has ended up in there… use a good torch!

Im on a CD install with the last snapshot.

Thanks! Snapshot of today fixes the issues, GRE including static route is up and running!

Patches accepted.  ;D

I don't think there is any technical issue, as there is a "reinstall all" that reinstalls currently installed packages in one big batch.

I have another question about multi-WAN together with shaping. We have two asymmetrical WAN links with different up/down bandwidths. The providers use inbound policing on the traffic, so I would like to shape outbound on each WAN link to the respective upstream bandwidth, so we won't hit the policers of the carriers. Now, in my understanding of the pfsense shaper, traffic has to be assigned to limiters via the rule base. However, rule base as far as I know only looks at inbound traffic (i.e. decide whether to permit traffic XY to enter via that specific interface). In our case, the traffic to shape comes in via LAN, however at that point, I don't know yet which outbound gateway the traffic will be routed to, so where would i create an outbound rule per WAN link that selects the proper limiter?

Seems like a lot more work for very little tangible benefit for most users. It's convenient to have them all there in one place, and most people don't have any need to take a screencap of their settings. You have to paste it somewhere to save the picture, and editing that much even in paint is simple.

Besides, the PSK tab will eventually go away and get merged into the user manager.

It may be how the SPDs are ordered, though I'm not sure there is any way to ensure the ordering of these unless you can absolutely ensure the order in which the tunnels actually establish (which is probably impossible in practice)

Also, not surprisingly, the manually modified config is overwritten on reboot.  I guess there is an xml file somewhere to be changed.

The current NUT machinery works - at least for my UPS.  The problem is with the GUI/xml/config layer not doing what it claims to do.

I noticed your post on the freebsd forum.  If there is any update on this situation please let me know and i will give pfsense 2.0 another shot.  Thank you.

I notice this bug (CP not working on VLANs) has been closed, yet the problem persists for me. I can access the CP page manually by typing the router IP address, but am not redirected there automagically when trying to access other websites.

I have tried to investigate this issue further, but found no culprit or solution.
I am writing my observations here, hoping someone more knowledgeable may be able to enlighten me!

First of all, I have created http://redmine.pfsense.org/issues/618 in the hope that the issue will not be forgotten.

To recap:
Tiny-DNS worked fine for me on 21-april, but was broken on 6-may.
(I am not sure if the box was rebooted in between, so I cannot get any closer to a specific date).
On 6-may, TinyDNS is trying to upgrade itself and as per pkg_config.8.xml it tries to download daemontools-0.76_12.tbz from http://files.pfsense.org/packages/8/All/
However http://files.pfsense.org/packages/8/All/ only contains daemontools-0.76_14.tbz (i.e _14 instead of _12).

I am a newbee to pfSense, but as far as I can see, the FreeBSD package building would be controlled by either
pfsense-tools/builder_scripts/RELENG_8_1-supfile
or
pfsense-tools/builder_scripts/RELENG_8-supfile
… not sure which...

The RELENG_8_1-supfile file is being updated every now and again to reflect the current date, whereas RELENG_8-supfile has been stable since october last year.

The timestamp on http://files.pfsense.org/packages/8/All/daemontools-0.76_14.tbz is 21-Jan-2010

And sure enough, according to http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/daemontools/Makefile.diff?r1=1.28;r2=1.29;f=h FreeBSD upgraded from _12 to _13 already on 04-jan, and to _14 on 7-jan.

Around 21-Jan, RELENG_8_1-supfile seems to have contained either
date=2010.01.22.12.00.00
or
date=2010.01.26.19.00.00
so as far as I can see, this should have picked up the _14 release, consistent with http://files.pfsense.org/packages/8/All/daemontools-0.76_14.tbz

So, from all the info I can find, _14 was introduced back in january, but "my" TinyDNS broke only in may. I wonder why...

I see a few packages in  http://files.pfsense.org/packages/8/All/ have the same name but different versions.

Could it be that daemontools-0.76_14.tbz was build already back in jan-2010, but that a daemontools-0.76_12.tbz was also left in place, but somehow deleted between 21-april and 6-may ?

Any hints would be much appreciated...

Thanks for the prompt attention guys.
Will try and get a free trip back to New York to test  ;D

BTW… thanks for the great book!