The last entries in the system log have the dual port NIC going up and down before the server locks up. Kinda seems odd because nothing is plugged into them...

Can you post the log entries or some of them.

Perhaps the unterminated NIC connector is picking up electrical noise causing the link state to flap. Have you configured the interfaces in pfSense? Perhaps pfSense is looping trying to bring those interfaces UP, failing, trying again etc etc.

What build of pfSense are you using?

A nic might not appear in pfSense because
1. It is not recognised by any device driver in the FreeBSD kernel (in which case it won't appear in the ifconfig output); or
2. It hasn't been added to the pool of interfaces used by pfSense. To do that go to Interfaces -> (assign) and click on the "+" button on the bottom right of the page. If there is no "+" button then pfSense has all the recognised interfaces.

Does your pfSense box have a route to your remote DNS server? Does the remote DNS server have  route back to your pfSense box?

my problem is i can't access the internet

Please help us to help you by proving more details:
Can't access the internet from where?
How did you attempt to access the internet? (ping? ftp? http? telnet? ssh? ...)
What was reported when you attempted the access?

If I reassign vlan10 from fx0 to em2,   the interface name goes from fx0_vlan10 to em2_vlan10,

Please describe exactly what you mean by "reassign vlan10 from fx0 to em2". VLAN numbers are not global assignments, they are local to a physical interface. Thus VLAN 10 on fxp0 is a distinct VLAN from VLAN 10 on em2. Is suspect if you are "moving" a VLAN from one physical interface to another, the proper course is to delete the original VLAN interface then create a new VLAN on the correct physical interface.

We can't change anything on the FTP server, so i think we need a bit of tweaking since its being refused as it is.

Check the documentation for the ftp client being used. ftp client on my Ubuntu netbook will enter passive mode if the client is invoked with the "-p" command line option, for example:

Code:

ftp -p 192.168.1.1

Some ftp clients accept a "passive" command or some spelling variant. On the same ftp client the "passive" command toggles passive mode.

Thank you for the input on the issue, If I get the IP + port number from her, can you guide me trough how to setup pfsense.

No.
1. You haven't given me configuration information: ftp from which pfSense interface TO which pfSense interface.
2. As previously mentioned, in certain configurations no firewall tweaking is required.
3. The port assigned by the ftp client for the ftp server to connect commonly varies for every invocation of the ftp client.
4. There is no proper diagnosis of the original problem, only my speculation.

But I got a problem with one of the users that can't connect to a ftp server.

I presume its a user on the LAN side of pfSense attempting to connect to a FTP server on the Internet. Normally FTP client will connect to FTP server and give the server a port number so the server can connect back to the client. One connection is used for control, the other for data transfer. The connection from server back to the client is normally blocked by a firewall. The user should give the appropriate ftp command to set the server into passive mode so that the client opens both connections rather than the server opening one.

I'm unable to find Dynamic DNS logs.

OK, post the output from pfSense shell command

Code:

clog /var/log/system.log | grep -i dns

.

Here is an extract from my system (IP address obfuscated)  May  6 01:01:01 pfsense php: : DynDns: updatedns() starting
May  6 01:01:01 pfsense php: : DynDns debug information: xxx.29.zzz.164 extracted from local system.
May  6 01:01:01 pfsense php: : DynDns: Current WAN IP: xxx.29.zzz.164 Cached IP: xxx.29.zzz.164
May  6 01:01:01 pfsense php: : phpDynDNS: No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.

I did try it.  And it changed MAC for both physical (parent) and the VLAN.  That's reason for the question.

Can you try on a different type of NIC?

Was expecting that spoofing the MAC on the VLAN interface would enable promiscuous mode and only use the spoofed MAC for the VLAN.  NIC is Broadcom 440x 10/100 (bfe0).

Some NICs don't need to enable promiscuous mode to see frames directed to a "non-standard" MAC address. I think (but its a long time since a looked at this) one way that was done was for the NIC to have a number of programmable MAC address hash registers and a receive frame was accepted if the hash of the destination MAC address matched a value in one of the MAC address hash registers. It was then up to software to determine if there was an exact match between destination MAC address in the frame and "acceptable" MAC addresses.

Again, it's not important to have Gigabit speeds, it's just the hardware that I have and that is most available, it's problematic to *have* to use a 10/100 hub to avoid hard failures.

Generally you can configure a Gigabit capable device to operate at 100Mbps.

For this box at home, I'm going to call it solved unless anyone wants me to experiment to see if we can find the root cause.  Again, a straight Linux like Centos 6.3 or ubuntu 12.04 server with iptable for routing doesn't have any problems with this same setup.

I would be interested to see if enabling flow control "fixes" the behaviour. See my earlier reply with a link to another topic for some clues about enabling flow control on the NICs.

I am really hoping for a non-anecdotal, authoritative "THIS is the card we all know is THE ONE" but if I cannot get that, I will try this one.

There are some reasons why this is not possble now and probably won't be possible for some years:
1. Some suppliers change the chipsets used in their cards without changing the model number. In such a case one particular revision of the card might use a supported chipset while another revision might use an unsupported chipset.
2. Some chipset suppliers don't provide open access to programming data for their chipsets making it very difficult to write open source device drivers.
3. The FreeBSD kernel developer community seems considerably smaller than the linux kernel developer community so there are fewer people to write new device drivers or port device drivers from other open source operating systems.

I suggest you try it. I suspect it might be driver dependent. In some cases it might be necessary to set the VLAN parent interface into promiscuous mode.

The few tutorials I read suggested a configured parent interface was unnecessary. But I can't think how else to control traffic across management VLAN 1.
[/quote]
I have not ever configured a Cisco switch so I might have misread the configuration information you posted. It seems to me you have misconfigured the switch. You need the port connected to the pfSense box to be a trunk port with it sending VLAN tags for every VLAN you are using. In pfSense you need VLAN interfaces for every distinct VLAN ID you are using. You then control traffic from VLAN 1 by using firewall rules on the pfSense interface with VLAN id 1. It looks to me that you have configured the switch to NOT send VLAN tags on VLAN 1 and VLAN 2 seems to be both tagged and untagged. However you need to configure it, the result is that you want the port connected to the pfSense box putting VLAN tags in transmitted frames for all VLANs. Maybe the VLAN 1 is special and you really should use another VLAN id to accomplish this.

I had it working today, for a few fleeting minutes. Then I did something and broke it again.

Time to stop random tinkering. Decide on a simple objective, make a simple change, document the change and then test that change brings things closer to your objective. Repeat as necessary.

It is very hard to help when someone reports "I made a few changes that I can't remember and now it is broken".

Does the noise from tcpdump mean it's my firewall rules blocking?

Impossible to tell without a reasonable sample. However it is unlikely because I think tcpdump shows incoming frames BEFORE firewall rule processing has occurred.

My home pfSense box is P4 based with 10 interfaces including 3 Intel 'em' GigE NICs and I've never seen anything like this.

Different chipset? You don't drive your NICs so hard? Or maybe whatever you have connected to them doesn't drive them so hard?