Use of protocols that are designed for the same local network, be it broadcast or multicast.. Are meant for devices on the same L2 network.. If you have a TV that wants to find your sonos speakers for an example via such a protocol.. Simple solution put them on the same network! Done..

Jimp point here is that what protocols your devices use on some local network has zero to do with pfsense..  If they want to talk UPnP or or SSDP or DLNA between each other you have zero to do on pfsense for that to happen..  If you have some sort of broadcast or multicast protocol you can try out avhai which helps with mdns, etc.  Or you can play with igmp proxy for your multicast stuff.  Which is most likely done better on your switch setup..

To be honest devices that require such nonsense as having to be on the same L2 to work, I wouldn't use those - vote with your dollars..  Nice that they want to make these things easy for the idiot user to just plug and discover via some broadcast/multicast protocol.  Great.. But allowing me to put in an IP or a FQDN of the device it wants to talk to should also be a option..

tbh, that was a stupid fast integration, thanks alot for a great product and awesome response!

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