@Rod-It nothing happened it seems to work for the OP what I suggested as he thanked me afterwards you wrote for OP, I wrote for @louis2 and here we slipped

You could also just look at the gui ;) If its logged it shows the little icon next to the rule.. [image: 1594926630080-log.png]

Just alert on the first packet in 300 seconds:- alert ip 172.16.5.0/24 any -> !$HOME_NET any (msg: "IP with TTL>=100"; ttl:100-255; threshold:type limit, track by_dst, count 1 , seconds 300; sid:20000012; rev:001;classtype: policy-violation;)

Share your Interface Configuration and Firewall Rules via Screenshots. -Rico

@johnpoz Noted, Many thanks.

Thanks folks. Google University didn't turn anything up so I didn't think that there was much of a chance that one existed. What I was hoping for was a rule builder where I could have the same interface names, etc. and then simply upload the new configuration. Thanks anyway - appreciate it.

@pooperman said in how to access from outside to server (teamspeak): since this is the 1st time I am using NAT port forward Noop. The second time. Your ISP router (should) contains the same NAT rule. "All incoming UDP traffic on port 9987 is redirected to the PfSense IP - this is a LAN IP from an ISP router point of view." Then, on pfSense : "All incoming UDP traffic on port 9987 is redirected to the TS SERVER IP - this is a LAN IP from an pfSense point of view." You could chain on like that if needed. It is a wise thing to change your ISP router setup so it NAT's only port 9987 to the inside (to the pfSense IP). Right now, no big deal as you have a second firewall : pfSense. Security : Every TS server which is globally accessible should expose it's 9987 port on the Internet. The server only recognizes TS voice traffic, it will discard everything else. After more then 10 years of development they should be rather good at that. If not, every TS server would be getting exploited - and there are a lot of TS servers in the world. Web servers do the same thing. Mail servers do the same thing. You should trust them, or not using them.

True, DNS goes over UDP and beyond FTP I have to open SSH since it is an SFTP connection. Now everything works. Thanks friends.

@louis2 This subsystem does not work in conjunction with PF . For example, it works perfectly with ipfw ( it is used by this firewall for deep packet inspection ) . Simply using its capabilities , you can filter packets based on the device's mac address, vlanid, and other attributes (ip, tcp/udp packets). But, unfortunately, using this subsystem, you can't create tags that PF would understand.

@bmeeks said in Site being blocked by pfB_Top_v4 rule; whitelists not working.: by opening the file directly in an editor. As I said above, open the file and check. pfBlocker has a Firewall > pfBlockerNG > Log Browser option where you can see every (any !) file used by pfBlockerNG. Hitting Ctrl-F (poor man's grep) for "46.1" did give two results for me, but not the network I was looking for. [image: 1594357528881-75288615-fc18-4171-bf40-d922bf2fb160-image.png] This : @serbus said in Site being blocked by pfB_Top_v4 rule; whitelists not working.: I think that pfB_Top_v4 is part of the GeoIP (not DNSBL) system in pfb. Check in Firewall -> pfBlockerNG -> IP -> GeoIP -> Top Spammers and make sure that France is not selected as one of the top spammers. answers one of my own questions : where does "pfB_Top_v4" come from - as I started to think that this list isn't identical for us all. Of course : it's build from GeoIP data ! This : [grep "^46.105." /usr/local/share/GeoIP/cc/](link url) returns, among others /usr/local/share/GeoIP/cc/FR_v4.txt:46.105.0.0/18 right away - and a lot more. I still could find a network match for 46.105.55..... - but, because I'm living in France, I do not (not) have FR checked in the GeoIP selection - didn't know they could spam over here, as we have laws that say that that isn't allowed ... ( ;) ) edit : I'm getting to old for this ? I actually "own" (rent for live) a 46.105.x.y IP ( 46.105.79.38 to be exact) it's my own family name domain name IP ...... (me banning my haed early in the morning). Back then, it wasn't really known to be in "France" - Google said it was based ine the ... US. That changed. I'm off selecting FR in the GeoIP lists .. see if I'm about to blacklist myself ....

@kiokoman key word here "it can be normal" thx

@Gertjan said in Firewall/Aliases add host by FQDN not work: Typing where ? Your PC ? At that moment, your PC had probably cached another IP for Google.com - not the same one pfSense was using. As said, google.com has thousands of IP's, not just one. Hi @Gertjan Thanks for your reply. Yes.Typing URL on my PC.(IP:10.24.10.2) I can ping "google.com".But I cannot display the webpage by entering the URL on the browser. How can I check if my dns is broken or not? [image: 1594197642096-81593775-b13f-48e8-bdba-44f6d9f4943f-image.png] Thank you.

@BCMguy said in WhatsApp messages will not send - but calls work: Thank you everyone - I've cleared out some Facebook IPs from the snort2c list and it looks like that's restored functionality. Took me a bit to find the right places to look to find the blocking. I wasn't getting snort alerts because it was being handled by the firewall directly via the snort2c table. You can never get a block from Snort that Snort does not alert on first. Now, if you have tons of alerts and/or have your alert log size limit set very small, it is possible for the alert entry to wind up in a rotated alert log and thus it won't show on the ALERTS tab because that tab only shows alerts from the active log (it does not go look into rotated logs). The snort2c table you refer to is populated by Snort using a FreeBSD system call. So any IP address in that table can only have come from Snort (nothing else writes to that table assuming you don't also have Suricata running as it shares that same table). In fact, that table is how Snort blocks. It puts the IP address to be blocked in that table via the FreeBSD system call. The table is created solely for Snort to use (hence the table's name). When you view blocked hosts on the BLOCKS tab, the GUI is dumping the contents of the snort2c table to the screen. The recommendation is the set the "Remove Blocked Hosts Interval" to a reasonable value of 1 hour or less. This will let the associated cron task automatically remove blocked hosts from the snort2c table when that host has not seen repeat traffic within the interval entered. For some reason never understood by me (the package maintainer, some folks think NEVER is the best choice for this parameter. It is not. Use a short interval like one hour tops or less for this parameter.

Note that I found another discussion on this subject a couple of years ago https://forum.netgate.com/topic/103460/firewalling-mac-addresses Whatever! given IPV6 with its "changing IPs" we simply need! mac-filtering to be able to filter traffic from or towards a specific devices in our own subnet. to allow something for that device (originating or destinating) or to block something Just the same things you can do with an IPV4-adress Louis

Thank you, I already reproduced this issue on my pfSense seems pfctl icmp-type + sticky-address issue, but only if you select icmp message types (icmp any works fine) https://redmine.pfsense.org/issues/10726

That helped me a lot. Many thanks

Hello! FTP without the dynamic port forwarding was too much of a burden. I converted everything (Win servers, NAS, webops, clients, scripts, etc...) over to sftp. Security beyond basic src ip restrictions was never a concern for these particular ftp transfers, but the move to sftp was definitely on the todo list and the upgrades from sonicwalls -> netgates were the catalyst. John

@MUST-UPON-TURN Hm, maybe there is a bad switch around? Providers go to the last mile only.. The infra inside could be the culprit..