That shows the config is indeed applied, it's configured that way, but the NIC refuses to use it for some reason. Not the first time I've seen that on a Realtek NIC, it's not very common, but some of those NICs cannot have their speed and duplex forced. The config setting applies, and the NIC refuses to use it. That's what you're seeing there. Is what you're plugged into really forced to 100 full? Best to always use autonegotiation if that's an option.

Thank you, yes I do have 2 nameservers defined for each WAN connection in System - General.  So 4 DNS servers total.  It should work when WAN1 is down but I am not at the location to test by yanking a cable etc.  Is there a way to temporarily "down" an interface via SSH or GUI to test this?

Thank you It worked

You're welcome.  :) If you're still worried about heat then mbmon will probably work on that age of box. There are quite a few references on the forum. Steve

Thanks, the screenshots look good. The earlier replies suggested you were mapping pfSense WAN directly to the NIC (not a pppoe interface) and you didn't say you changed that.

You need to better define "freezes up the Internet connection", what exactly happens? Can't open new connections but the existing ones work fine? Can you ping the firewall, its WAN IP, its WAN default gateway, Google, …? Torrent problems aren't common, they're far less common here than with your typical Linksys because they can't handle large numbers of connections generally. If you have settings in your torrent client that let it go crazy with creating large numbers of connections, you may be maxing out your state table. You can check that on the front page of the web interface, and in the RRD graphs, and can increase it under System>Advanced.

How do you know it's not connecting? Try going to Diagnostics: Ping: and running a test on each WAN interface. Steve

ok, thank You very much ! Tom

ok, thank You very much ! Tom

Depends on traffic rate in pps not Mbps, and the hardware you have. That sounds roughly normal depending on specifics.

That last capture is much different, more like what you showed in the text output, which shows the behavior varies. Why isn't clear. What the last one shows is your client sends the SYN to open the connection, it gets a SYN ACK in response, and then it RSTs the connection. In more plain English, basically your client starts the TCP connection, the 10.0.0.50 device responds back for the next step of the handshake, and then your client says "no, close that connection". Then your client sits there for 3 seconds and repeats the exact same process. After that, it sits there for 6 seconds and repeats again. The order is as described, but the timing is such that I seriously doubt the client gets the SYN ACK before it sends back the RST. There is around a half ms between the SYN ACK and RST, which is far too short of a window for the client to have gotten the SYN ACK, so it seems more like the client sends then SYN, and about 10 ms later, sends the RST. The two retries have 1 ms between the SYN and RST. I have no idea why your client would be behaving that way, but that's the issue. Firing up Wireshark on the host itself, in the capture options put in a filter for "host 10.0.0.50" on the OpenVPN interface, and see what you get at that point would be my next troubleshooting step.

Sorry I edited while you were typing! I'll read your other thread. Steve

you can't do that. installing packages locks things and you can't load other pages, you have to wait for the install to finish.

You have to do that by IP, need a DHCP reservation on that MAC if you're going to use DHCP on it.

I'm seeing an MTU issue after upgrading from 1.2.3 to 2.0.  I 'fixed' this by editing /var/etc/pptp-vpn/mpd.conf and adding: set link mtu 1396 Then, killing the mpd process and restarting it: /usr/local/sbin/mpd4 -b -d /var/etc/pptp-vpn -p /var/run/pptp-vpn.pid -s pptps pptps That's not a pfSense 'solution' but perhaps others here could try it to see if our problems are the same? This wasn't necessary before, so I'm wondering if defaults are different, path MTU discovery is somehow broken, etc.  BTW, I read that XP's pptp client requires 1396, so that's what I set for a compatibility floor.

The paid version of Kiwi syslog daemon can forward log records to another syslog server but I don't know if it can do that at the same time as logging the messages itself.   You might need to have two paid copies of Kiwi as well. EDIT:  Having read the whole of the link below, I see that you don't need the paid version unless you want to spoof the original IP address. http://www.kiwisyslog.com/help/syslog/index.html?action_forward_to_another_host.htm ~~I don't have the full version but you get 30 days of full function with a trial copy.  ~~It does only run on Windows though.