In your example rule, destination should be 10.0.50.3 if you're trying to keep things tight. Correct. Filtration is done at the point of entry to the interface. Once it passes that, it's allowed ot go where its destined. Correct. Correct. https://docs.netgate.com/pfsense/en/latest/firewall/firewall-rule-basics.html Also note that existing states aren't affected by a rule change, so reset your states between rule changes via Diagnostics - States - Reset States. You can filter on just the states you're concerned with, or nuke them all.

@Derelict said in PF States limit reached.: Is this running on Hyper-V? Appreciate your reply. It is on a physical box. Supemicro Atom C2750.

@vladanpopovic said in external smtp ip appears as local: actually I can't Oh, yes you can. The filter, or better, as @kiokoman stated, a milter, can be made verbose to see what happens. I have this in my master.cf file : policyd-spf-perl unix - n n - - spawn user=nobody argv=/usr/local/bin/perl /usr/lib/postfix/policyd-spf-perl -v "policyd-spf-perl " is a Debian package, and known as a postfix milter. You see the -v option ? I added it. You can also changing my $VERBOSE = 0; to my $VERBOSE = 1; in /usr/lib/postfix/policyd-spf-perl Instead of one line that details SPF operations like DUNNO, fail or pass, I get the whole boat load. Here are the details https://pastebin.com/qxdg9QKX Just an idea : you have to open this file : /usr/lib/postfix/policyd-spf-perl and add a gateway like this : use constant relay_addresses => map( NetAddr::IP->new($_), qw( 92.xxxx.20.243/32 2001:xxxxx:52:cff::1286/128 ) ); # add addresses to qw ( ) above separated by spaces using CIDR notation. # mail2.aaa-bbbb-fumel.fr # 92.xxxx.20.243/32 2001:xxxx:52:cff::1286/128 If I didn't do this, mails received by mail MX backup (when the main MX is down) would be marked bad by this SPF filter - sorry : milter. You use probably another milter for SPF. Just check the doc of the source - or even better : check the source - it's perl or bash or something like that. Making it verbose is always - not difficult -.

thank you for your answer! It don't seem to work... The point I don't understand is how my netgate is going to communicate with my squid server in azure... did he have to?

@gethersJ said in PFSense Firewall Log View - Showing Logs Once ICMP: If i try and ping google.co.uk on a continuous loop from my PC, I will only see that event in the logs view only once... but I really need to see this for each ICMP request. So if it pings 50 times I would like to see the ping in the logs 50 times You are not tracking traffic if you would see 50 icmp pings in your Logs. Firewall Logs are exactly that - Logs. They are not to be used for traffic analasys. There are other packages that do that job, traffic log isn't the right one. And of course you only see 1 hit in the logs, as only the first state / request is logged, all other pings are matched against the valid state and are passed through because of stateful filtering. If you want to log traffic, use ntopNG, bandwithd, darkstat etc. or just install softflowd and send your flows to an internal flow collector and let it parse and beautify your traffic :)

many thanks you for the hint / workaround. Overseen this "Login protection" yet (looked for sshguard anywhere...ß) and try this now... come back to mark solved if this works.

can I also point out I am not the one who posted the diagram, nor is that the configuration of my network? Derelict posted it to show me a proper routing configuration when dealing with multiple vlans... and the diagram clearly shows an L3 switch and an L2 switch.

Did you review the OpenAppID setup instructions in the pfSense documentation? Here is a link: https://docs.netgate.com/pfsense/en/latest/ids-ips/setup-snort-package.html?highlight=openappid#application-id-detection-with-openapp-id. You have to enable the OpenAppID rules download (along with the OpenAppID detector stubs), update the rules on the UPDATES tab to download the necessary files, then go to the RULES tab and select which OpenAppID categories you want to use. Sounds like, from your description of things, that you have not done all of these steps. Also, you will find that Snort and OpenAppID will work better with the new Inline IPS Mode feature available in the Snort 4.0_6 package on pfSense-2.5-DEVEL.

@graeme said in FW: lan to wan: On other hw and sw firewalls doing lan to wan only works. Any LAN bound device (PC, Phone, visitor, etc) can access the WAN == most often the Internet. Typically, non trusted devices should be connected to other 'LAN' interfaces = OPTx interfacers as they are called by pfSense - special firewall rules can now be set up for these type of devices. Basic rule : on LAN you should connect only trusted devices. @graeme said in FW: lan to wan: I.e. a network card can only go to net and cant talk to other cards .... Again, devices LAN, by default, can 'talk' to anybody on every interface WAN(s) or LAN(s). @graeme said in FW: lan to wan: ... nor devices on same range. What am I doing wrong please? Any device connected to a LAN can connect to another device on the same LAN. Guess what : because traffic goes through one or more local LAN switch(s), and never even touches or uses (the firewall of) pfSense. Proof : my LAN, with about 45 devices on it, works very well for local (device to device) communication, even with pfSense shut down. pfSense, by default, does not behave any different as any other firewall/router, soho or pro. Why should it ? What makes the difference : the guy in front of the keyboard.

I'm guessing your "smart" plugs are talking to a mother ship somewhere. If they are Alexa or Google Home enabled, they need to get their commands to function from some AI server out in the cloud. If you have severed or blocked that access/path... they aren't going to work. This is the way Apple's Siri environment works. You speak commands or questions to the device, it sends that voice data to the cloud to be AI processed, then the server(s) send the data back to your device. Am I thinking of this the right way? They probably have to have internet access to function properly, maybe even at all. Why don't you just setup pfsense to allow them to bounce around in your IOT network, block them from all other internal LAN networks, and allow them to talk (maybe with limited port traffic stuff) out to the web/internet. @KOM suggested above essentially this setup. Jeff

What you want isn't a log, it's called Netflow. There is the softflowd package which can help here, but there are other ways to reach that goal.

or .. who know what bloatware they put inside their apps maybe it want to send statistic data from your nas (full of porn) somewhere

So that shows me they have your modems GUI page unreachable by a setting on their end. Can you plug a computer direct into the modem and see the GUI? I bet not. Set your computer to 192.168.178.2/30 and try that. Your ping proves you have access.

True "Bonding" gets you just one IP address from the two connections. Thus most of the bandwidth by the two connections combined for one file download. Are your connections PPPoe by chance? Then look up MLPPP. Pfsense can do MLPPP. If your on fiber though Id be looking for an upgrade in service first. Other methods for bonding do exist. They require equipment and cooperation by the other end of your connections whether by your ISP or by a man in the middle company. Otherwise if you are just looking for failover and loadbalancing then the link provided by ptt above will do ya!

@KOM Thanks for the reply! That solved the problem!

@Gerard64 said in how come on a natted port 80 a blocked ip can still telnet in: But i don't want to put that information out on a forum. Here a my WAN rules : [image: 1566550021227-12aeaf38-778a-4588-977c-7942758fe7b5-image.png] Tell, me : am I at risk now ? Btw : I was one NAT rule : the one that gives "Source" hosts access to my "diskstation". edit : the NAT rule : [image: 1566550158674-3e064f53-7e17-4b4c-9d79-a38174290c27-image.png]

Hi, I know this is an old thread, but just a quick line to confirm the behavior; I am running 2.4.4-RELEASE-p3 with several nested aliases. Only the top aliases (not their children) are used in rules. For some unknown reason, one of the firewall rules with source= top alias for a pass rule was not allowing the devices in one of the children aliases, the other two children aliases were working ok. Following the following suggestion by @jimp everything went back to normal. "Does it make a difference if you kill filterdns (killall -9 filterdns) followed by a filter reload (Status > Filter Reload, click Reload Filter)?" In case It helps.