Download iperf on the two good and two bad desktops.

Run iperf ( server mode ) to iperf ( client mode ) record the speed between both good desktops

Run iperf ( server mode ) to iperf ( client mode ) record the speed between a good desktops and bad desktop.

Repeat test 2 but put fixed IP addresses on the devices and connect them directly together.

I'm guessing it's the nics on the bad desktops, test 3 would prove this.

@overpf:

So then, pfsense cannot be virtualized.

It can be virtualized fine. Just pass the NIC through instead of emulating one, or see if the VM can emulate a link-down event when the physical connection is interrupted.

Btw. there is a dedicated board for that kind of questions: https://forum.pfsense.org/index.php?board=37.0

I just really liked how basic it was.  It created a small little graph that sat on top of all windows, and if Internet performance started to seem spotty, you could glance up and see if your Internet connection was getting saturated.  If it was, then you could dive into the GUI and dig into what was hogging the bandwidth.  The only things I've found recently, are big and bulky, and are overkill for what I'm trying to achieve.

At least you can use that TP-Link for port mirroring.  It works OK in that role.

Actually, promiscuous mode is more about getting frames off the wire that have been sent to other, non-broadcast MAC addresses regardless of VLAN… The connected switch will already be filtering most of this in normal circumstances unlike when hubs were a thing and you could see everything.

Promiscuous mode need not be enabled for a pfSense interface to "trunk" VLANs.

Well after spending alot of money upgrade to cat 7

CAT 7 won't do much.  Gb is designed to work over CAT5 cable, though CAT6 is often used.

@RussellA:

Also, the Status Interfaces not showing DNS settings on OPT1 (or WAN2 depending how you've labelled it) is a red herring. Even with a working DNS service when the WAN is down, the status page only lists DNS settings on the WAN Interface section and not the OPT1/WAN2 section.

A few things I found which weren't in the instructions which eventually allowed DNS service to work when WAN was down:
1. On System->General Setup page uncheck the option DNS Server Overrride.
2. Also On System->General Setup page check the option Disable DNS Forwarder (See Note 1 below).
3. On Services->DNS Resolver page check the option Enable (This should be checked already because of step 2).
4. Also on Services->DNS Resolver page check the option DNS Query Forwarding (See Note 2 below).

I tried this, it works for the internet, but the NAT stopped working. I have a NAT that goes to OPT1, and I have set the firewall rules manually to set that gateway.

Why are you forwarding 1000 ports but only have the torrent client listening on 1?

And that screenshot still shows the wrong port for the current forwarded range. I assume you have updated that?

Steve

Sounds like file system corruption. You might consider installing a UPS…

One thing I learned a long time ago is, if you're prepared to watch for a failure, it won't happen.  ;)

Thanks, ok that does make sense. I need to use source hash so I guess I'll just use a portion of the subnet.
Would be nice if we could use source hash with alias. Sticky round robin just doesnt do it for us.

Thanks for clearing that up!

Ok, so 10.0.0.4 is not in the 192.168.3.0/24 subnet.

Is the VPN server actually at 10.0.0.4? How is that subnet connected?

If the client and server really are both in the 192.168.3.0 subnet that that's the wrong IP address the client is using. In that instance the traffic would go directly between them so pfSense would never see it.

However running a VPN between two devices on the same subnet seems… unusual at best.  ;)

Steve

Thank you, SammyWoo.

I've had the traffic shaper run in different configurations since you suggested it, but the first couple of days the connection kept crashing every couple of hours despite the traffic shaper being up and running.
Then I changed the port for torrents to use to one outside of the normal P2P range of ports that my ISP didn't seem to be messing with.
That seems to have solved the problem.

I went with NAT source hash subnet 3.3.3.128/25

But it looks like(at least it seems this way) that my pfsense is also giving out the Broadcast address 3.3.3.255 to some of my clients, they then obviously lose internet access. If I check the states for their private address I see this "3.3.3.255:5205 (172.16.49.160:61396) -> 8.8.8.8:53 SINGLE:NO_TRAFFIC"

Now I'm not sure if it's showing the broadcast address on the outgoing interface because this IP is failing to get out onto the internet?

So as a test I changed the NAT outbound source hash rule from subnet 3.3.3.128/25 to 3.3.3.128/26 which should give out IP's up until 3.3.3.190, and ip 3.3.3.191 is the broadcast….but after making this change and searching the states I can see that pfsense is giving out the IP 3.3.3.191, this shouldn't happen as this is the ranges broadcast address.

Are you using PPTP?  If so change immediately!  Go with openvpn or IPSEC Mobile..  Personally I prefer Mobile ipsec as it supports windows 10 native built in client.

Maybe try enabling syslog and pushing to syslog server and you might get some info regarding the last seconds prior to hanging system.

@detox:

Derelict …..

According to Suddenlink, all the static IP's I will be issued are class C  /24

Thanks

So on the interface itself in a larger subnet than your allocation.

There is no good way to put those addresses directly on servers.

I would 1:1 NAT in that case.

Or I would ask for a routed subnet to an address on that /24.

Lets look at it this way… Lets say your wan IP is 1.2.3.4

What is the default lan rules?  Any Any right!  So is 1.2.3.4 fall into ANY?  If so then yes the lan would be able to access it.

Rules are evaluated as traffic enters that interface from the network its connected too, first rule to trigger wins no other rules are evaluated.  So when you have some client on 192.168.1.X for example on your lan wanting to go to 1.2.3.4:443 that falls in the rule any any - so yes it is allowed.

If you do not want to be able to hit the wan IP from your lan - then put in a rule that blocks that on your lan... But seems kind of pointless since your allowing lan your web gui on the lan address via the anti lockout rule.