For the route table to be consulted it would have to pass through the firewall. It's better to drop the traffic at the firewall. And using -reject is bad because that sends back an ICMP unreachable. If it's a malicious network, you don't want to send anything back based on their requests. What you want is -blackhole. And you can still add those on BSD if you want, but you have to supply a gateway: route add -blackhole -net x.x.x.y/zz 127.0.0.1 Or use the GUI and pick Null4 or Null6 as the gateway. I'd still just block it in firewall rules and forget about it though.

spamming - ie sending emails is not dns queries.

I managed Check Point firewalls for years starting with Nokia IPSO-based appliances and then later Check Point branded appliances. No custom chips in any of them. All were pure software. The IPSO operating system owed its origins to FreeBSD and Check Point's SPLAT (Secure Platform OS) and later GAIA OS were both hardened versions of CentOS/RedHat Linux with a Check Point authored software package on top. No custom hardware anyplace. In fact, l frequently used both in VMware virtual machines in my lab although the IPSO VMs were a bear to configure because Nokia did use a custom NVRAM chip to hold some configuration info and you had to fake that out in the VM. I did it by using FreeBSD 7.1 to create a very basic setup and then copying the IPSO image on top of it using dd. The biggest difference I see between pfSense and the Check Point products is the Check Point stuff can suck a whole lot more money out of the corporate treasury each year for maintenance and support contracts and licensing fees ... . Later Edit: After thinking about it some more, it would be unfair to suggest pfSense and Check Point are identical in every way. Each offers its unique advantages. For a large corporate enterprise network, Check Point does have some nice management features that pfSense currently lacks -- mainly Check Point's SmartCenter server and all the firewall deployment, management and log consolidation functionality it offers. You can do some similar things with pfSense and third-party tools, but it's not as clean at the moment. Of course that Check Point functionality will cost you a rather substantial sum (very quickly rising into the 6-figures range in US dollars). pfSense costs you exactly zero US dollars if you support yourself, and still is very competitively priced if you purchase Netgate support. However, out of the things I mentioned above, nowhere did I say that expensive product was any more secure than the free one. In terms of security, when managed by a competent admin, the free product and the expensive one are identical. The expensive one just offers some management conveniences.

Thanks, KOM. I have some success, am able to access a machine on the LAN side of the firewall from the WAN side using the static IP. My test machine (the workstation on the LAN side, that runs a test web server) is a VirtualBox virtual machine running CentOS 7.6 I installed fresh, for this purpose. It gets its IP from the pfSense DHCP server as 192.168.200.10, which is aliased to one of my available static IPs as you describe. I have ports 80, 443, and 22 forwarded, and they all work. There is one thing I learned after several hours of beating my head against the wall, which might help any other newbies trying to get this to work... DON'T FORGET TO TURN OFF THE #%$%$& FIREWALL ON THE LINUX WORKSTATION ON YOUR LAN!!! or the equivalent (Windows firewalls?) on whatever else you're using as a workstation on your LAN. :-( CentOS 7.6 (and I suspect most Linux distros) installs iptables or firewalld by default, and turns it on with a default set of rules. If you installed it as a workstation rather than a server, the default rules block server stuff. So, all my attempts were getting through the pfSense firewall just fine, only to be blocked by the Linux firewall in the workstation VM on the LAN. I went in there and said "sudo service firewalld stop" and by magic, everything started to work. Yeah, I know, this should be obvious. It totally got past me. :-( So for now I think I'm all set, until the next roadblock :-). Thanks for all your help.

@fernandopf I have had no success either. I could be my configuration: Media Server on VLAN 20 (10.2.10.200) Trusted Wired Clients on VLAN 25 (10.2.25.0/24) Trusted Wireless Clients on VLAN 30 (10.2.30.0/24) IGMP snooping enabled on my UniFi switch for VLANs 20, 25 and 30 IGMP Proxy enabled with Upstream being the media server Downstream being 10.2.25.0/24 and 10.2.30.0/24 Firewall rules enabled for IGMP from 10.2.25.0/24, 10.2.30.0/24 and 10.2.20.0/24 to anywhere with "Allow packets with IP options to pass" enabled under advanced options for each IGMP rule I have downloaded the latest IGMP proxy binary (dated April 30) from https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/latest/All/ Interestingly, the size difference from the latest pfSense 2.4.4-RELEASE-p2 (amd64) release and the snapshot is 130K (snapshot) to 39K (release). This has worked for some but no joy for me.

@jeff3820 Late post with no success either. I could be my configuration: Media Server on VLAN 20 (10.2.10.200) Trusted Wired Clients on VLAN 25 (10.2.25.0/24) Trusted Wireless Clients on VLAN 30 (10.2.30.0/24) IGMP snooping enabled on my UniFi switch for VLANs 20, 25 and 30 IGMP Proxy enabled with Upstream being the media server Downstream being 10.2.25.0/24 and 10.2.30.0/24 Firewall rules enabled for IGMP from 10.2.25.0/24, 10.2.30.0/24 and 10.2.20.0/24 to anywhere with "Allow packets with IP options to pass" enabled under advanced options for each IGMP rule I have downloaded the latest IGMP proxy binary (dated April 30) from https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/latest/All/ Interestingly, the size difference from the latest pfSense 2.4.4-RELEASE-p2 (amd64) release and the snapshot is 130K (snapshot) to 39K (release). This has worked for some but no joy for me.

@viragomann said in Problems accessing a device on a different sub-net: Have you configured the default gateway on the wrt310n? Exactly.. Many a native firmware for wireless routers don't even have an option to put a gateway on the lan IP.. If you can run 3rd party firmware on it, you can prob add it. if not you will have to source nat traffic to the wrt310n IP to look like traffic from your lan is pfsense IP on that wrt310n network.

Alright so if I have multiple subnets, how will it affect my connection? Shouldn't my device just connect to the ip of the router?

That would have ZERO to do with problems on your own local network. Yes. The main problem was the internet access timing out; the internal problem only surfaced when I was looking into the packet dumps. There still might be an issue there, but I think its more likely that I wasn't looking at a full conversation. We've had zero issues with the NFS uses, so I'm chalking it up to my lack of experience with reading packet captures. Thanks for the help!

Euh ..... Read the log file : it shows what goes on : The watchdog finds unbound dead. One second later, dhcpleases found "etc/hosts changed size from original!" and want to restart unbound also ... [ edit : if you are using 'pfblocker ' and the like, this will take some time ... ] For the - maybe related "dhcpleases kqueue error: unkown" see, for example, see https://forum.netgate.com/topic/112302/dhcpleases-unbound-errors-in-the-logs [edit : dhcpleases does this probably to early ... unbound is about to be started - pid file not yet created => things get messy now ] Btw : restarting a process that goes flat out with a @KOM said in Praising Service Watchdog !!: segfault aka general protection fault aka memory access violation should not be restarted with the wacthdog. The problem should be solved. @chudak said in Praising Service Watchdog !!: What would you do to figure out why it's going on ? Applying the one big advantage of open software : look at the code : you can see what happens yourself ;)

Here is one of the reasons they are doing this https://www.cnn.com/2019/05/02/politics/china-pentagon-report/index.html

Hi, thanks a lot for claryfing this, I'll keep it disabled. BTW, I tried all the reccomendations I found in this page: https://docs.netgate.com/pfsense/en/latest/hardware/tuning-and-troubleshooting-network-cards.html but still cannot get more than ~5.5 Gb/s from my Intel NIC (measured with iperf3 and multiple parallel streams). Is there anything else I could try or this is something I should actually expect from these cards ?

Maybe nmap? You certainly are running ever package under the Sun

For x86/64 based systems with a monitor I’ve mostly been successful using gparted (CD or USB) and the dd command. More recently I have been using pfSense VM’s on ESXi (Free). With Nakivo Backup (Free) you can backup 2 VM’s straight onto a Synology NAS (intel CPU only). With open-vm-tools running inside the pfsense VM i can do automated full backups every night without the need to shut down . Since the backups are snapshot based they only take a few seconds. (The first backup takes a few minutes). Restores only take a few minutes, too and you can select a different Esxi host as target. For the backups to work (esxi snapshots) you won’t be able to pass through phyisical NICs via vt-d, however i couldnt notice any performance impact using vmxnet3 adapters...

Interesting can you open a ticket with us at https://go.netgate.com we will get you the image file needed to reflash the unit. Thanks!

Pfsense doesn't know what the client OS is nor does it care.. Is your pc also wireless?

You can watch the traffic with Wireshark to get a clue. Also, if in doubt, remove pfSense from the equation. Do you have a cheap router you can drop in it's place?

No, just ignoring it.

Further information on both packages @johnpoz listed can be found in this sub-forum: https://forum.netgate.com/category/53/ids-ips. And here is some specific documentation created for the Snort package: https://docs.netgate.com/pfsense/en/latest/ids-ips/setup-snort-package.html.

Thank you, this was the problem...