I ended up deleting the interface and building it from scratch. It was mainly the effort of redoing the static DHCP leases. I had set up a dummy interface first and copied the rules over to that one, and then back to the redone interface.

That fixed everything. It must have been some kind of corruption I could not shake in any other way.

@johnpoz lol! Yes, if I can help it I will keep things private and locked down appropriately. I will plan that carefully if that were to happen, right now it's just a thought but have no need :)

don't beat my drawing skills because I've worked very hard on it (ha ha just kidding!) but here is a small drawing on how I have (or want to) set my network.

Network Plan - Overview SMALL.png

With only one small difference:
At the moment I haven't connected my Cisco router between my PC and pfSense firewall, so there is a plain, straight UTP cable without any switch or router in between.

Dear @johnpoz

My problem is described here: Problems configuring OpenVPN on pFsense 23.01

Let's not discuss my problem any further here. I am just about to try again troubleshooting using your ideas but any further discussion about my problem, should be done there.

Thanks you really very much for your ideas. I will keep you posted.

@lcbbcl Agreed, makes sense when put like that. I somehow got the idea that I could first block everything and then open this, but obviously got it wrong. Thanks for quick response!

@steveits

Found that the issue was caused by Snort blocking Google IP's for various reasons. What I cannnot explain is why I needed (for an entirely unrelated reason) to re-config the snort interfaces to be able to actually see that Snort was the culprit. At least I am pretty sure its the case because since I last posted on this thread, I've had two episodes of connectivity issues and both times it was clear as day that Snort was blocking Google IP's. Unblocking them made my VPS reconnect almost instantly.

For now I consider this solved!

@johnpoz Oh, yeah. !! Thanks.

@dominikhoffmann

Just include your networks inside of the alias:
Select IP, then there will be a Type field, select Network(s)

66141865-2a6f-4937-9fd9-b882ae93014b-image.png

The main problem is detecting that "specific packet". Do you mean specific payload content? If so, remember that nearly 100% of network traffic today is encrypted and only decrypted at the two endpoints of the conversation. Firewalls and intermediate devices can't see into the payload. They see only random encrypted bits.

Can you open a Redmine issue for that at https://redmine.pfsense.org/?

Some of the easyrule code changed to add extra validation and that specific type comes through in a way that doesn't seem to align properly.

@viragomann OMG you just saved me so much troubleshooting time! I didn't know PostgreSQL and PG admin needed to both be installed. I only had PG Admin and thought I can just jump right into doing stuff with databases. I can finally get everything up and running. Thank you!

@jknott said in Very odd UDP 40000 request. Please help me understand:

@furom

Unfortunately, my crystal ball is busted again, so I can't offer much more.

Bummer... But thanks much for trying. There oughta be some way of finding out device on that vlan has tried to make the connection, I'll just continue trying, there must be a way. Have a good one :)

@gwaitsi What @rcoleman-netgate already said:
2f4cbbd6-14b0-4c97-88ea-fa0c53e1de74-image.png
515cd4e5-71f4-4c48-9225-3192fc4d5f56-image.png

@viragomann
that did work, anything else I can try?

No ideas?

Sorry but I am experiencing an internet outage with recovery scheduled for 02/28

Yeah, in the Dark Theme some extra "marking" is needed because of the dark background. In the default theme, disabled rules show as obviously grayed-out on the white background, but on the darker background of the Dark Theme something extra is needed. Notice the text is lighter in an attempt to show 'grayed-out", but the red bars help the lines stand out.

SUPER stupid thing to miss. I'm sorry for wasting your guys' time! It was indeed rule order bombing out the traffic. FYI I do already have dyndns setup with my domain so connectivity from external sources will be immediately functional...I still likely to keep internal traffic off the WAN interface though. Just a personal pref. Thanks all and have a great day!

@johnpoz said in Guest LAN client isolation possible?:

but blocks rules shouldn't ever have a "state" ;) So that is odd for sure. maybe he adjusted the rule from allow to block? And there were states from when it was allow?

Makes sense, with coffee. :) Open states would allow traffic to "bypass" the block rule.

@DominikHoffmann is that rule with both the source and destination as GUESTWIFIVLAN Net? That shouldn't make sense either. On a separate interface one would want rules something like:

allow from VLAN to "This Firewall" DNS
block from VLAN to "This Firewall" (blocks connecting to pfSense 443, etc. on any interface)
block from VLAN to LAN Net
allow from VLAN to any

Marked solved because I have deleted the override and maybe it was also for home.arpa. Thanks Jim.

@dfsense Well that is wrong solution to a self inflicted issue.. Is pfsense not the default gateway to these devices?

@johnpoz Do you think any of this has anything to do with Netflix?

I have tried adding a rule allowing the Apple TV any access to anything, and it's still broken. I have T-Mobile Home Internet, and it's double-NAT as a result... If I connect directly to the wireless signal sent off that device Netflix loads.

I'm wondering if because Netflix is included on my cell plan, it's somehow verifying I'm connecting through their service, and it thinks I'm on another network? Or if there is any way to test that?

Still confused...

@fjmp24 must of been some other discovery protocol - there are a few of them.. avahi is just for the mdns discovery.

I would guess WSD.

@dark_prophet next step for what - from your wireshark I see some traffic to 2302 on both udp and tcp... So pfsense is forwarding the traffic.. Why your box is not answering we have already gone over why that might be..

@johnpoz Thanks for the example and your explanation of the port forward rule. I have created a similar one but indeed specifically for port 445. This time I did not do an exploit from my Windows 11 machine but from Kali Linux in the same LAN segment 192.168.0.0/24 as my windows 11 machine. This time it is quite easy to run the exploit on a machine in a different LAN segment behind the pfsense firewall. I suspect Windows 11 has built-in security.

@viragomann it probably might just have been a bug. Red herring. Never happened before.

@steveits it answers my question, thanks!

@steveits: It does on my end as well.

@viragomann
Thanks! Blocking of private networks was the issue.

Default route was already in.

You rock!

@keyser yep was going to write this..Thats how i would do it.

@dominikhoffmann said in Can’t forward gateway WAN Port 1360 to host on internal private network:

What am I looking for?

A existing state pointing with the wrong IP on it or something.. Kill the bad state..

@viragomann completely agree, you might source nat to allow conversations with something that uses a different gateway than pfsense, or doesn't have a gateway (camera as example).. Or if it was some iot devices that prevented access with no way to allow for it.

But if its a device running its own firewall - it would be better to correctly set this devices firewall to allow the traffic, or just disable it if you feel that is appropriate for your network. Secured, you mange all the devices, nothing hostile on the devices own network, etc.

@4rr3n said in Inter VLAN:

@jarhead said in Inter VLAN:

@4rr3n First, why would pfSense be off?

Things happen, power cuts, kids or animals etc.

As long as pfSense is handling the layer 3 portion the vlans will not be able to communicate to each other. Layer 2 is handled by the switch so anything connected to it will still communicate with each other.

So vlan10 devices will talk to other vlan 10 devices, vlan 20 devices will talk to other vlan 20 devices, but vlan 10 won't talk to vlan 20 and vice versa.

So, from the example you have provided, is that the case when PFSense box is turned off or on ? My concern is what happens when the layer 3 (pfsense in this case) is not present but switch/access point is still turned on.

Well, you asked what would happen when it's off, so I wrote what would happen when it's off.
When it's on, all would work as expected.

@pfrickroll said in Blocking outbound ports & trusted sites list on VPN:

Is there a way somehow to block the above inside that VPN?

I'm not sure of how Twingate works. But if it is like a typical VPN where the connection to them is being done via an app on a device (computer, phone, tablet, etc) then as far as I know your are not going to be able to filter traffic via pfsense. All of the traffic routing out the device will be encrypted by the Twingate app and pfsense will not be able to see any of the destination information other than the routing of packets to Twingate. If this is the case, you'll have to revert to blocking on each device (host file, built-in firewall, etc).

If Twingate is set up as an interface in pfsense then you can address this by creating Aliases of the ports, sites and IPs you want to block then use those aliases in firewall rules on that interface.

@dobby_ Thanks, yes I know it is best done from outside, but have limited possiblity for that so wonder if the setup I suggested will be useful and secure for this or not.
But perhaps using another firewall in front of pfSense and a raspberry pi or similar in between to use as pen-tester would create the same effect... As pfSense is what I want to test, it should be sufficient, right? As long as just connecting to pfSense WAN, and using a dedicated monitor/tbg/mouse for the RPi...