Sure.. But that would have nothing to do with the camera's normal IPv4 address.. You stated "move this traffic from say 192.168.x.0/24" like you were going to change the devices IPv4 address to a multicast address.. You wouldn't do that - the device still needs it normal IPv4 address. What multicast address space you want to use for multicast traffic has nothing to do with that. As to anything you would do on pfsense.. Nothing.. devices on the same L2 talking multicast to each other would have nothing to do with pfsense. Also not sure why you would use anything in 225, that is reserved multicast space.. If want to create multicast groups, does your switch(es) support IGMP snooping, or wireless? I woulds assume your camera's talking multicast anyway.. There is no reason to specify which group they are on (via address) unless you have multiple multicast streams on this L2 network, and your wanting to have your switching infrastructure limit which devices see what streams by allowing the devices to join a specific group..

But sure not right away seeing the wol packet leave pfsense got you wondering if was actually going out on the wire.. But going forward you can sniff them on pfsense, you just have to look for them specifically or they can be easy to miss.

Hi, Just wanted to know if there is a way to turn off firewall filtering but keep the LAN devices in communication, if yes how ? As I don't need firewalling, I just need the routing part. Thanks..

There is a possibility to reset the pfsense tracked table. Find better routes to navigate?

The month part of the setup process doesn’t really matter. I think the setup screen defaults to the current month for the system clock/time. In the Scheduling settings, make sure you highlight the day boxes, don’t go for the month or specific date options. That should work out fine. I’m not aware of an 11 day bug here, Or any bug in the scheduler. Did you do any other searching before you posted here about something like this? Jeff

Alright together, i think i got it working. I now used the floating rules with following configuration: All traffic, that should pass the WAN by my ISP (VOIP VLAN) got tagged with VOIP_PASS All traffic that should not pass the WAN and only pass tunneled by the VPN got tagged with NO_WAN_EGRESS One floating rule on the WAN Interface is block -> all traffic tagged with NO_WAN_EGRESS One floating rule on the WAN interface is pass -> all traffic tagged with VOIP_PASS So, at the moment it works in general like expected. Any improvement ideas for this are welcome, if anyone has a better solution! Best regards I hope it helps someone else with this idea

Glad you have it working now. -Rico

@enriqueparra33 One thing you have to keep in mind with FTP is active vs passive mode. Active mode doesn't work well with NAT. These days, clients often, but not always, use passive, as do browsers. When I first used NAT, active mode was all that was available and it wouldn't work through NAT.

This gets very close. Very usable. Thank you.

If by "booting" you mean "getting kicked off a game server", then probably not. Not from a (D)DoS. If someone is flooding your connection with a DoS attack, the bandwidth is already consumed by the time it reaches the firewall. Local QoS does nothing. It must be mitigated upstream (at the ISP)

Hi, I have found myself the beginning of a response : I have managed out, that it's related with the package NTOPNG and the DNS-Server that is used in it : when I change the DNS -Option from [image: 1589552500294-6a862a8c-dc66-4f35-a8c4-9d197c9201d1-image.png] to [image: 1589552546792-cbc2d23f-6331-4c29-bfac-2fcdc869f939-image.png] the messages about a misbehaviour disappear. The strange thing is that pfSense is configured to use localhost as DNS-Server and that unbound is configured on pfSense itself. [image: 1589553190335-14cf15a2-f057-4d1d-9c54-61fe1f29ad5d-image.png] I will put a new post about the problem in the category traffic of the forum. Regards, Michel

I will check it in the evening. A t this time only linux machines are there and I don't want to allow the windows machines to serve some services. Anyway, LAN network doesn't know anything about VLANs, where the host to be connected from VLAN20 is located ....

Once I read the DNS suggestion, I realized I hadn't checked those settings on the scanner. Went into it and saw that it was still pointing to the old, non existent WiFi router for DNS. Changed it and now I was just able to send a test successfully. Greatly appreciate everyone's help!!!!!!

Have you resolved this? I have the same issue, cannot ping the LAN interface.

@Gertjan iVMS-4500 HD For Hickvision!

I assume, there would a possibility to allow access from outside on the NAS. If not, you can also do a workaround with Outbound NAT on pfSense, so that it translates the source IP in packets destined for the NAS into its interface address, which is within the same subnet.