@Gertjan For what? I have no problems) everything works well) re-read the topic again and understand why I left the config)))

Any outbound rules can only be floating. Adding the inbound scheduled rules as floating rules means you can put them all in the sane place which makes managing them easier.

@RobbieTT I kind of like Windows it was a big upgrade over MSDOS 3.11 or DOSSHELL. But really it's like non stop Azure use even for home use now. Windows ME had pinball

@asiawatcher step one is actually validate traffic gets to pfsense wan, pfsense can not forward what it never sees. So go to like can you see me . org - test to this port 5000 while you sniff (packet capture) on the wan - do you actually see the traffic get there? [image: 1695471394859-port.jpg] Maybe your behind a cgnat? If you do not see the traffic hit your pfsense wan, then it can never forward it. If you see it, then sniff on your lan when you do the same test - do you see it send it on to this 192.168.100.200 box? Possible this 100.200 box is running its own firewall, or not even listening on that port, or maybe not using pfsense as gateway. But until you actually validate pfsense sees the traffic on the wan.. Maybe your rules are wrong, mabye the IP your forwarding to is wrong, etc. etc.. But first step is to make sure pfsense actually sees the traffic your wanting to forward, otherwise your just going to be spinning your wheels and it would never work.. edit: here you can see my port forward I created, but my box isn't listening on that port - but pfsense would still send it on. Via packet capture on my lan interface when doing the can you see me test. [image: 1695471994431-portforward.jpg] So pfsense did what I told it too - but the box didn't answer, so the problem is not with the port forward. You would also notice the counter went up on my firewall rule showing that it allowed traffic. [image: 1695472055799-counter.jpg] But first step in troubleshooting port forwards should be to actually validate traffic gets to pfsense to port forward.

@coxhaus said in Do I Need IPS ?: I used WAN years ago. Never used LAN. I do have some problems with this though, pfS "drop" everything on the WAN by default and it's a noisy interface and look at this one Bill knows it best: https://forum.netgate.com/topic/76141/snort-on-lan-wan/5?_=1695283899257

I can confirm with the cron job that the schedules work. I timed the command to run when the schedule is timed, so it doesn't need to run every hour.

@oznet DNS Query Forwarding: Enable Forwarding mode

Sorry for the very delayed reply, this is the first chance Ive had to do some testing. It now appears as if its working, although please let me know if I'm missing something, and the only thing I've done is that I restarted the router the other day due to some issues with my internet connection. I started off my confirming all subnets and IPs were correct then proceeded with the following tests Desktop 10.100.3.3 255.255.255.0 Firestick 10.100.3.5 255.255.255.0 Mobile 10.100.3.6 255.255.255.0 Tablet 10.100.3.7 255.255.255.0 Laptop 192.168.1.21 255.255.255.0 Desktop to Firestick SUCCESS Desktop to Mobile SUCCESS Desktop to tablet SUCCESS Desktop to www.google.co.uk SUCCESS Desktop to 8.8.8.8 SUCCESS Desktop to 10.100.3.1 FAIL (as expected) Desktop to Laptop FAIL (as expected) Mobile to Desktop FAIL (Not as expected but research shows this is a windows firewall rule I need to configure) Mobile to Firestick SUCCESS Mobile to Tablet SUCCESS Mobile to www.google.co.uk SUCCESS Mobile to 8.8.8.8 SUCCESS Mobile to 10.100.3.1 FAIL (as expected) Mobile to Laptop FAIL (as expected) Tablet to Desktop FAIL (Not as expected but research shows this is a windows firewall rule I need to configure) Tablet to Firestick SUCCESS Tablet to Mobile SUCCESS Tablet to www.google.co.uk SUCCESS Tablet to 8.8.8.8 SUCCESS Tablet to 10.100.3.1 FAIL (as expected) Tablet to Laptop FAIL (as expected)

@kineticspl said in Blocking IOT inbound access: I thought outbound only access was "safe" for IOT devices Noop. On the contrary. With free outbound access you can't be sure what the camera does with all the info (images) it collects. Storing all these videos on a 'cloud' => great. You really have to trust that cloud storage. That's why cameras are (should !) be using a local NAS or DVR, with big disks (+UPS because this is /privacy security related). Or you rent your own cloud "NAS", a place where you are the admin (root ) and no one else. Best would be to open a VPN tunnel between your pfSense and this off site cloud/disk space storage facility. @kineticspl said in Blocking IOT inbound access: didn't work locally on my network even with rules in place What rules ? Where / on what interface ? @kineticspl said in Blocking IOT inbound access: I tried googling and found "hole punching" Also called : NATting (actually PATting) : this is needed so you or some one else can initiate a connection to the IOT from 'anywhere on the Internet'. This is ok, if it was 'you' using, for example, your phone, to client to 'home' to look at the camera. Normally, you don't NART anymore. Activate the OpenVPN server on pfSense. On your phone : use an OpenVPN app. When needed, activate the phone openvpn app fist : your phone is now connected safely with your pfSense, and you can access all local resource 'as if you were at home' without any security issue. When done, stop the OpenVPN connection. @kineticspl said in Blocking IOT inbound access: robot vacuum What is that ? @kineticspl said in Blocking IOT inbound access: Ideally I'd like to only be able to access these devices locally and not from the outside at all. That's what you obtain by default. Put them, IOT stuff, on a separate network, and if needed, block outgoing traffic on that network, with the exception of, for example, NTP-to-pfSense, if these IOT need real time.

@Jake-0 said in Help with bridging issue: However, after i created the bridge on the LAN interface I immediately lost connection to the Web Console. This shouldn't happen normally. Steps to do this: Change the LAN IP to something else in the LAN subnet and access the webConfigurator using the new IP. Create a bridge and add the LAN and other interfaces to it. Create a bridge interface, enable it and assign your desired LAN IP to it. Then you can remove the substitution IP from the LAN interface.

@Hammer8 I experience the same with headscale, a fork of tailscale controller to self-host. I made an auth-key (that does eventually expire) and register the pfSense node WITHOUT an expiration date. After some weeks it dies and I cannot get it back online without making a new auth-key. It is as though the tailscale package does tailscale login instead of tailscale up at random times. Seeing this on pfSense 2.7.0 with the 0.1.4 tailscale package Next time it fails we need to go in the CLI and see if there are any clues as to why its logged out. IMO once logged in, it should only do tailscale up and tailscale down, it should not login, logout.

@ASGR71 said in IP Address format of firewall aliases: within the CIDR range are still getting through! Like what? What IP and in what cidr do you think it should hit. If your going to create an alias.. Validate that aliases actually populated with what you put in via the table listing under diagnostics. As to doing this with pfblocker on a sg1100.. Why prob not a good idea to use pfblocker with some crazy amount of dnsbl settings.. Creating some asn based aliases is pretty low resource requirement.

I've had this problem... isolating subnets etc... This is a common issue with firewalls and you can find out how to do this in the documentation... https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/opt-lan.html It will give you a fully explanation than is possible in the forums. ;-)

Hey Tim... I've had this problem... isolating subnets etc... This is a common issue with firewalls and you can find out how to do this in the documentation... Just substitute OPT with WLAN or IOT. Should be all the same. https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/opt-lan.html If you want to isolate individual clients, it has to be done at the switch level. You'll have to find a managed switch that suppoers this feature. ;-)

Things to think about thank you. I shall look at moving my IOT's to their own LAN. I quote like a bit of tinkering, that's partly there reason I have pfSense, I'll persevere with Snort for a bit, see how it goes.

@alexmay we certainly appreciate your thoughts and insight on this for sure! What I ended up doing because of the sheer capitulation from port mappings… I created an Alias for the NVR and Doorbell (Lorex Devices) allowed all ports to those two devices only. As much as I loath AWS and Google, the dynamic source port mappings far exceeds my capacity to continue allow/deny round robin port maps. Maybe I could try allowing ports 5088, 5070, 8080 from the source to those ios but I’m not 100% confident on my ability to get this rule correctly on the LAN side…