To be clear, there is nothing downstream of the Actiontek except for wireless connections, and that's currently limited to a single laptop that only sees occasional use.  I kept the Actiontek as a standalone device so as to avoid any such IP address conflicts.  I wouldn't even be using it were it not for the fact that I still have one STB in use on the upstairs bedroom TV.  I intend to disable the wireless function and set up wireless on the pfSense router at some point.  For now, I just want to get the basic internet features working.

In any case, I have found the problem and got it working.  Apparently the "Block bogon networks" checkbox is checked by default and it was preventing the router from allowing internet access.  I had gone through one of the tutorials yesterday and it jogged my memory when I was looking through the various configuration screens.  I reset everything back to factory defaults and reran setup from the beginning, but this time I unchecked the "Block bogon networks" box.  When I was done the yellow exclamation mark next to my network access icon disappeared and I was able to connect to the internet.

I had a similar issue happen during my upgrade.

http://forum.pfsense.org/index.php/topic,57024.0.html

I didn't know what the root cause was, but I suspect it was the same thing that happened to you.

Hmm, OK.
Why have you bridged WAN and LAN?  :-\

If you are able to post the stuff Wallabybob asked for this will be much easier.

Steve

Thank you for the answers.
I stopped looking for a serial cable in my old cable-boxes and you were right: I didn´t need one.

Solution was quite easy and your answers gave me the last push to it:
"pfSense-2.0.2-RELEASE-4g-i386-nanobsd.img.gz" was correct
After plugging the WAN-cable  to eth1 and my client to eth0 made it:

I got en IP-Adress from pfsense: 192.168.1.100 my new dhcp-Server is the pfsense-Box: 192.168.1.1 I can config it by using the webinterface on https://192.168.1.1

thanks a lot!

Steffen

.

I normally just open the system log on another tab and keep refreshing it.
Status -> System Logs

It's kind of a pain compared with tailing the log, but it's right there in the GUI.

I would like but it is not necessary .. I'll try that at least recognize the hard drive to install PFsense .

Can use something like

/etc/rc.firmware pfSenseNanoBSDupgrade path_file

@wallabybob:

@pozolero:

it freezes in configurin WAN interface…

Freezes for how long? There can be delays while pfSense is waiting for response to its DHCP request.

What build of pfSense are you using?

Hi there wallabybob, can be frozen for up to a day or more if I leave it in that state.  I'm using pfsense 2.0.1.

But the funny thing is that at first it did not happen. That began to happen eventually.

The dell server has two hard drives configured in RAID, could this be the problem, maybe one of the two is saving an image and is remaining in the system and this is happening?

Regards

On physical hardware, that's usually caused by a buggy BIOS and upgrading it generally fixes. Though mucking with the timecounter sysctls may be a work around, as Steve noted.

for others, these are the links jimp was referencing to:

http://snapshots.pfsense.org/FreeBSD_RELENG_8_1/i386/pfSense_RELENG_2_0/?C=M;O=D
http://snapshots.pfsense.org/FreeBSD_RELENG_8_1/amd64/pfSense_RELENG_2_0/?C=M;O=D

1. has been fixed in the tree and will be corrected in 2.0.3, there are already several threads for it.
2. Harmless message, has always shown up with limiters and in some cases captive portal.

Not sure about 3, haven't heard anything like that.

done, thanks

Make sure both master and slave have their GUIs on the same type/port, e.g. both https on 443, or whatever you want as long as they both match.

@jimp:

Not the same issue. And that's been asked/answered a few times already in other 2.0.2 threads.

OK. Thank you for setting me straight. I'll go look it up.

Should I req the post be deleted?

@jimp:

Looks like it was updated, but all indications from most people are that it improved.

That thread you linked was for a much older version of FreeBSD so it isn't exactly relevant.

Yes, I agree but seeing exactly the same messages over timeouts.

Under 2.0.1 never a issue, put 2.0.2 on these two machines and now network card issues.

I  have disabled msix on the nics and set the other tuning parameters indicated for e1000 (set the queue to 1, etc) in hopes it stabilizes this issue.

Did some more testing.

If NAT sync is turned on in XMLRPC Sync config the outbound NAT's are synced and any extra rules on the backup, even if the "do not sync" checkbox is set on it, is removed.  If the "do not sync" is set on the master for a outbound rule that rule is not synced, but any additional rules not on the master are removed from the backup.

If I turn off NAT sync in the XMLRPC Sync config we dont get the outbound rules being wiped out on the backup.  Obviously we loose the 1:1 and other NAT rules being synced as well.

In 2.0.2 perhaps the NAT sync is not evaluating the "do not sync" explicit rule on the backup before removing rules?

@Nazarene:

the mirrors i have found are for Compact Flashes, memory sticks and live cd's. can someone point me in the right direction with say a link to where i can get a mirror tht i can casually burn to dvd.

The LiveCD is also the install CD so the version you want is almost certainly this:
http://files.nyi.pfsense.org/mirror/downloads/pfSense-LiveCD-2.0.2-RELEASE-i386.iso.gz

If you have more than 4GB of RAM you may want the 64bit ISO instead but you probably don't need that.

Steve

That could be from NTOP I installed a few days ago, it looks like its the type of libraries it would install now that you mention it, the only other package I have on this firewall is open-vm-tools.

@extide:

Depends on how the rules are created, if they are generic rules then they don't apply to any specific interface. If they are bound to an interface it would be the friendly name like LAN or WAN or OPT1, etc, not the freebsd name like em0.

I would say just export your config, build the new box, import the config and then see where you stand. You should be pretty much ready to go, you will just need to reconfigure the interfaces themselves, but the rules should be fine.

Awesome!  Thank you very much for clearing that up.  Knowing that it may not be a waste of time makes me a little more comfortable bringing down the network to attempt this.  I'm going to give it a go.