Thank you very much for your prompt help.

All is good now with HamClock. I was able to find in the instructions how to launch it in a browser. Works like a charm. Thanks for all the help.

@johnpoz good idea. I think I'll keep the rule. Thanks again. Most of the fun so far has been learning with PFSense. I just wish there were clearer guides out there.

@SteveITS Ah yup, completely forgot about that. Was also looking at using the new API, but its on the next version, so will either be updating, or using that, one of the 2, would prefer to use the API, but would rather not come ruin a weekend night updating firewalls.

@Pizzamaka yeah it might be a bit confusing, especially on an any any rule where you don't call out say tcp or tcp/udp and its just IPv4 any any rule.. I think that was their goal with listing the rule that triggers but mentions the igmp protocol even when its an allow rule, for example your lan any any rule.

@johnpoz brilliant thank you PS. working as now as mentioned tested with ping and looks like default is 20 seconds on ICMP. thank you again

@Operations said in Arrow in firewall log, why?: I created an whole reply while you deleted your post so i couldnt submit it hahaha So basically the arrow in the log is because it is a floating rule? So no issues there and normal behaviour? Docker server is pinging my synology because of Kuma Uptime docker. Sorry about that. I missed the crux of your question and got triggered! Yes, the arrow is indicating your floating permit rule matched in the out direction, i.e. traffic leaving the firewall on the 'LAN' interface and that seems to be inline with your rule definition. If your monitoring app is on a different network segment to the target, then you of course need rule(s), somewhere, that will permit that traffic. As to whether floating rule is the appropriate location for that is a matter of personal preference. Regarding explicit echo reply permission in rules, I have found it unnecessary, The pf firewall seems to permit the reply back in without it. But that might not be the case with two-way floating rules.

@Operations yeah pfsense not going to do anything with broadcast traffic one way or the other. If you don't want such traffic in your logs then yeah just create rule to not log it.

@johnpoz I don't remember if I had changed it from a /24 to a /22 when I originally setup the network. I want to say "I don't think so". The clients that pickup IP addresses in the 10.8.13.x and above get the correct subnet mask and they are assigned addresses from pfSense's DHCP server, so to me that's confusing why nothing else is working for them. I want to keep pointing my finger at something at pfSense. I'm going to do a rebuild on a machine and test before I backup the config and rebuild that FW. I have other locations setup "Cookie Cutter" only with the 2nd octet different (10.5.0.0/20, 10.6.0.0/20 ... etc..) The last range is 10.8.12.1 - 10.8.15.254 (10.8.12.0/22) I use manual outbound nat for our VOIP setup and want static port mapping. Normally I would use auto.

@guardian I wish someone would make this feature or a package that could do it. I would use the heck out of it.

@owner-of-a_BAKERY Do you have deduplication enabled in pfB? It works but there can be side effects. What I was trying to say was, start with a low number and see if the counts match up. If they do, add a few more until they do not match. Not sure about the memory but I would expect it takes more memory to read in and process a list, than to store the IPs in a table.

Hi @viragomann, I found it! It was because of a miss configuration into my client OpenVPN connection. Here is a post that explain what was my problem: https://www.reddit.com/r/PFSENSE/comments/i125ig/default_route_now_set_to_vpn_client_instead_of/ I was looking into this because of this: # route get 1.1.1.1 route to: one.one.one.one destination: default mask: 128.0.0.0 gateway: 10.4.112.1 fib: 0 interface: ovpnc1 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 That gateway of 10.4.112.1 was the gateway of my OpenVPN client connection. When I stop the service for that VPN connection, that was the result of the same command: /root: route get 8.8.8.8 route to: dns.google destination: default mask: default gateway: modemcable001.40-53-24.mc.videotron.ca fib: 0 interface: igb0 flags: <UP,GATEWAY,DONE,STATIC> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 So I made search on why the OpenVPN client was adding that route to the routing table: 0.0.0.0/1 <<VPN Interface Gateway IP>> And I found the post tjhat somve my issue. I would like to thank you very much as well as @skenigma for your time helping me solving the issue. Best Regards, Yanick

Looks like OP has double NAT and did not put ISP kit in bridge or pass through mode. Thats problem #1 I added a host oversides to access my NVG599 web GUI under DNS Resolver [image: 1725299645094-screenshot-2024-09-02-at-1.52.33-pm-resized.png]

@abcx10 does we need create a bridge and connect Lan and Wan together ?