@viragomann & @Gertjan Thanks for your help! Managed to solve it with a floating firewall rule! I only tried to block it from the interface that I thought the traffic originated from first. But now I tried to add a floating rule that blocked the traffic from all interfaces that shouldn't have access to it, and it worked!

@johnpoz OK, I understand much of the issue a bit better now. The real problem is related to internal/external DNS. (See below) Devices on different subnets/VLANs have different DNS rules... Turns out the stuff that's borked has DHCP-level DNS override for that subnet, specifying external (8.8.8.8) DNS for devices on that subnet... With the result that those devices don't ever get the internal IP address for the (mqtt) server in question... (my pfSense DNS resolver has host overrides for internal servers) And apparently the packets get royally screwed up: <internal IP A> sends SYN to <external WAN address> then the <SYN ACK> reply from the server is <internal server IP> to <internal IP A> which simply does NOT work. Edit: belay the question below. I've now learned about NAT Reflection, and @johnpoz' well informed disgust at any use of it ;) Alternative question: how do we have DNS handle different subnets / VLANs in different ways? In essence, after local host overrides, some VLANs would be processed by forwarding to our filtered DNS service, while others would use unfiltered generic DNS. Any idea how to implement that? I don't see that as a feature in the GUI at least. Bottom line question... is there a correct way to configure the ability for internal IP's to access NAT'd devices by way of the external WAN IP address? If so, perhaps I don't need the host overrides in the first place. (The Rst stuff is, I think, because I wasn't looking for the packets in the right place ;) ... now I'm testing on a laptop with wifi rather than a phone, so I can run WireShark and see exactly what's happening...)

@biggsy Good catch on the TCP only traffic. I've fixed that so it's now blocking all traffic instead. Yes, I am running IPSwitch/ Progress IMail server. Any hints or tricks about that? I'm REALLY hoping someone buys that product line. It's a great mail server. Progress is making a mistake by saying they're going to EOL it.

@heper Very true! I think this step-by-step was meant for a bare-bones setup with no other gateways in place. But, it worked as a "Pass ! NOT <Private Networks>" in the tutorial, hence me wondering why it wasn't working for me. I updated to a reject rule, removed the invert and kept the rule at #1. It is now working and IOT network on the iPhone cannot ping the Secured Network. Naturally, the Secured Network could not initially ping the IOT network, so I implemented a Pass rule at #1 allowing traffic to flow from Secured to IOT, and now can successfully ping in that direction. A benefit to the ! rule seemed to be no need to make pass rules on other VLANS. But anyway, problem solved. Thanks to you and @johnpoz for your help! Greatly appreciated.

That clears things up - thanks again @Bob-Dig and @viragomann for all your help.

@kenw said in Block access to cable modem from guest network: Here is a screen-shot on my firewall rules for the IOT network: Here are my rules. They allow only access to the Internet and also ping to the interface. [image: 1672581746499-056f581f-c4fe-4aef-87ea-19b5a52135fc-image.png]

@eaglex Yeah it would just be the one port. Restarting the phone would not clear states but you can see/delete them in pfSense or restart pfSense.

@johnpoz said in No routing to class C WAN: @zak-mckracken clearly your not going to be using isp A ip address with isp B clearly the wants was added by hand you have dhcp delete it Well, I was considering to change it to the new intermediate network gateway, but that doesn't make sense: The added gateway is identical to the DHCP gateway, kind'a confirming it was added manually due to the problem I described in the other thread. So you're right; It has to go! And so it went, nothing seems to break down with it. Thanks for all the help, guys!

@kankamuso "Source port" is the port the remote computer uses to connect out to the server, in this case SSH on port 22. Source ports are typically random and higher than 1024. By setting the source port to 45678 you'd have a roughly 1/64000 chance of it working. If you set the source port to any and leave the destination the same it will allow any inbound connection. accept incoming requests on port 45678 and redirect it to 192.168.1.2:45678 (WAN interface on my pfsense) If it was being redirected to an internal server that would be a NAT rule not a firewall rule. A firewall rule is still needed but note by default NAT forwards create a linked firewall rule to allow the NAT to work. However that's not what you're describing. To get pfSense to listen on 45678 you'll either need to change the listening port on its SSH server, or you could try forwarding WANIP:45678 to LANIP:22. I'd recommend not allowing connections from the world though. https://docs.netgate.com/pfsense/en/latest/recipes/ssh-access.html#ssh-daemon-security. If you really need remote access from a non-static IP you could set up a dynamic DNS hostname and allow connections only from that hostname.

@viragomann said in No internet connectivity.: So why did you set a /24 in Proxmox, but state then a /29? This was just my writing error, there /29 set in proxmox. Anyway, my issue is fixed. The issue for me was that I kept skipping "Upstream Gateway" configuration upon pfsense first setup, though it was exactly what I was missing. Thank you for giving me extra knowledge

@viragomann Thanks for the reply. Can you point me to something more detailed. I need more than a general strategy. Again, thanks for answering.

@uniqueusernamebetween2 said in Rule for disallowing all internet traffic: Is there a way to set up the WAN on a timed schedule Normally, WAN access isn't scheduled. pfSense itself also needs WAN for NTP, DNS, package upgrade tests etc. What you probably want is this : Time Based Rules.

@theclient said in Unity Editor won't open after upgrade to 2.6.0: Firewall log doesn't show anything with his IP. Firewall rules only log when you set them to log. The default LAN firewall rule doesn't block any traffic.

@johnpoz Hi and sorry for late answer. The icmp was sent to that net's broadcast address. Why is still unknown, I suppose that is a question for my NAS vendor... I have made a habit of masking most addresses, agree rfc1918 is not really necessary

@bob-dig Thank you, makes sense, that's what I assumed.

@gertjan Hey thanks for the response buddy, but I, fortunately, had it figured by myself. I changed the static route and updated the GW there that was configured to WAN instead of LAN. Now pings work perfectly.

@mrpfsense (don't do this but) 1 ) on LAN add a firewall rule that passes port 25 outbound to any and logs it. instead do: 2a) on LAN allow port 25 outbound from the one server IP, and 2b) second rule after 2a: on LAN block port 25 outbound and log it If spam is being sent that implies a PC is infected. Alternately Spamhaus has other lists like the policy list were the ISP reports it shouldn't be sending mail at all...often set for DHCP IPs.

Looking at the firewall logs from the console, I see that those log entries are marked as blocked, so your solution to disable logging blocked events should work. Thanks for your help.

@jarhead very good point!! luckily i know who own's the /16 and know I'll never need it.