Well I would not go looking for other issus until that is solved. As you say IN errors on WAN would affect download more than up.

So that is a 10G copper NIC connecting to a 1G device? I assueme (but suggest anyway  ;)) you have tried swapping out the cable?

Can you not use a 1G NIC directly for WAN?

Perhaps I've misunderstood your setup.

Steve

@doktornotor:

If you mean what's actually listening on pfSense itself:

netstat -an | grep LISTEN sockstat -l

Yes, thank you that's what I meant.

Regards.

I found this command:

/usr/local/sbin/pfSctl -c 'interface reload wan'

but it seems it doesn't work in my case

interface description of pppoe interface: DYN1
if I do ifconfig I see pppoe0 interface
it's using em2 physical interface

which is the command to try in my case?
please help me

I checked the box but I'm still getting the same behavior.  When I look at the state table I'm seeing this…

LAN tcp 10.10.10.227:32400 -> 10.1.1.186:52925 CLOSING:CLOSING 8 / 0 2 KiB / 0 B
LAN tcp 10.10.10.227:32400 -> 10.1.1.186:52939 CLOSING:CLOSING 8 / 0 2 KiB / 0 B
LAN tcp 10.10.10.227:32400 -> 10.1.1.186:52986 CLOSING:CLOSING 12 / 0 5 KiB / 0 B
LAN tcp 10.10.10.227:32400 -> 10.1.1.186:53008 CLOSING:CLOSING 8 / 0 2 KiB /

Does this mean that the firewall is closing the session or 10.10.10.227?

Any other ideas?

Thanks for the help.

I'm pretty sure it's mpd5.

Avahi is only for mDNS discovery, not for generic broadcast protocols. If Sonos products use or can be made to use mDNS it should work with avahi.

First, I wouldn't enable NAT Reflection on a global level. It can be set for each NAT rule individually, and that's how I would do it as not everything needs it. I do have it enabled for my Plex port forward, and have found things to work seamlessly with it this way. It's actually required for Sonos to be able to access Plex because of a limitation in Plex's Sonos implementation.

Using the custom setting for DNS Rebinding would be a good idea too. I also have this set in my DNS Resolver settings. There is also a setting for DNS Forwarder (dnsmasq). Both can be found here.

And if you're forwarding DNS to OpenDNS or somewhere else that blocks DNS Rebinding on its own, a domain override for the plex.direct domain would be good too, though I'd override with Plex's own DNS servers instead of using another DNS provider to remove a variable from the equation.

@Harvy66:

@purduephotog:

@johnpoz:

Dude I understand what a CA is… But we are not talking a public freaking CA.. We are talking a CA that create a handful of local certs.. Which sits on his firewall - which is pretty freaking close to locked room!!

Yeah, sorry about that.  I'd been explaining crypto all day to people at work that couldn't understand what was being done.  I got into a lecturer mode.

Still, could make the root CA on a new or different HD or even a bootable USB stick, do the work, export the certs, then pull the stick.  That's pretty secure too.

I know the feeling. Every so often we ask another company to send us their public key and they send us their private+public key pair where their private is a wild-card EV cert from Verisign.  It saddens me so many don't understand such basic concepts.

I got another nice one. A large org (about 100B usd yearly turnaround) gave us the public key for their root and sub ca:s. The only problem? Their ca:s had 50 year lifespans and no CRL paths specified…....

Why don't you just have the NTP server listen on all LAN interfaces? Why only one?

Are you not using gateway groups? It's a standard pfSense notification whenever a gateway in a gateway group goes up or down:

TMOBILE_DHCP is down, omitting from routing group FIOS_to_TMOBILE
8.8.8.8|192.168.0.254|TMOBILE_DHCP|982.895ms|1995.669ms|0.0%|down

Hi,

Read your write-up 5 times.
At best, it's not very clear.

What is a "Plex server" ?
"Plex is running on a Server 2016 VM hosted on a Server 2016 box" AND "I am in the same LAN as the server and have tried different RDP clients and different devices." In this case, pfSense isn't used at all, you could even shut it down. RDP will work.
I have my 2008R2 on my LAN, and can connect to them from any other PC device on the same LAN. No traffic is 'touched' by pfSense in this case.

One of my Windows 2008R2 can be accessed from the outside (Internet) using RDP. A simple NAT rule on pfSense will do the trick.
Don't know what NAT refection is.

I guess you have a VM setup issue here.

Btw : check your keyboard. At least one key is broken.

Everything I am doing is 2.4-RC on a XenServer VM. I have no reason to believe 2.3.4_1 on a physical would be any different.

Sorry for reviving an old post but I just ran into this same issue on my newly purchased SG-4860 running 2.3.4-RELEASE-p1

This doesn't seem very intuitive & seems like it could potentially cause some unexpected & problematic behavior if someone deletes a LAGG & then tries to use the ports individually without being aware of this "functionality".

The reason being, when you assign interfaces to a LAGG, they all are given the same MAC. The potential problem (and definitely unexpected behavior) is that after removing the interfaces from the LAGG they all retain the same shared MAC!

In the attached screenshot you'll notice that igb4 & igb5 have the same MAC. That's because they were assigned to the same LAGG at one point & then removed. This was definitely not expected behavior & took me a while to figure out why it had happened since I had never manually set a spoofed MAC on the interfaces directly.

Is this behavior really functioning as intended?

Interfaces.jpg
Interfaces.jpg_thumb

I must to add the line in /boot/loader.conf

hw.mfi.mrsas_enable=1

I can not give you any scientifically sound information on it (Steve probably can), yet, I am using VPN with a Celeron without AES-NI, to download usenet movies, and I have 150 Mbit down, so I think the lack of AES-NI is not a performance problem.

Unfortunately that could be anything. It could be the drive itself, the cable, the port on the motherboard/controller, even drive firmware and not a hardware fault.

Check Diagnostics > SMART Status, see if anything looks out of sorts there in the 'All' output for the drive. Maybe even initiate a test and see if it finds anything.

If it's a SATA disk, swap the cable out and try a different SATA port on the motherboard.

If that doesn't help, it probably is the disk.

The crash report you attached indicates a filesystem issue. The LAN address part might be related, it certainly does not sound like any problem I've heard of unless you had an IP conflict or overlapping networks.

To fix the filesystem crash, use the console and boot to single user mode. Then run "fsck -y /" a few times until it does not find anything, don't stop when it claims to be clean. It may take 3-5 times.

Is this how you do that?