@johnpoz tcpdenied.PNG TCP_DENIED/403 is caused by pfsense or squid?

@steveits Thank you! Those rules work! Now will try to understand why... :)

So much to learn, so little time!

@regexaurus said in HTTPs response from VoIP to LAN subnet is rejected or dropped:

I did promiscuous PCAPs from pfSense, on the VoIP and LAN interfaces, filtering on phone IP, while attempting to access phone web interface. This is how I determined https requests from PC on LAN are reaching phone, and responses are reaching VoIP net interface on pfSense, but responses are not arriving back at PC...

This suggests the devices you're trying to ping are actively ignoring the requests.

@gislenitsupport Yeah sorry that's pretty sneaky for them to use the same model number.

The eMMC utility says it is available only on Plus. I guess you could upgrade?

Does the console show anything when it stops responding?

I think I found the culprit: ntopng

I removed the package and now everything back to normal responsiveness.

@johnpoz said in Apple TV upgrade:

@furom do those IPs have any meaning? What is 1.79 and 10.165? Did the box at 50.5 use to be in those networks?

No, none of those IPs make any sense. But by the sound of it, the AirPlay tip above should do the trick. Fingers crossed!

@wolf07 Sure. Although note blocking to IP_PublicDNS:443 doesn't block to any other DoH servers that aren't in that alias.

@moussa854 I came to the same problem and after a lot of trial and error I found out that in order to UDP hole punch to work with pfsense you need to set Static Port on NAT outbound.
From the menu Firewall > NAT > Outbound select Mode = Manual and edit the auto created rule LAN to WAN and set static port.
Now everything should work ;)

@johnpoz said in Firewall blocks ports after a certain time:

@mrremo and what fixes it - does it just start working again.

So far only a reboot has helped.

@johnpoz said in Firewall blocks ports after a certain time:

Is it possible your destination box that 192.168.0.2 is changing Ips, or service(s) are stopping?

The IP is also a static one. So no, it has not changed. The service is running. It is accessible on the LAN. I am sure that the problem is not with the server (192.168.0.2), because the VPN port is also blocked. The VPN server is running on the pfSense box.

@johnpoz said in Firewall blocks ports after a certain time:

Validate traffic is actually getting to your wan

The next time the problem occurs, I will double-check.

@viragomann thank you very much, I managed to solve the problem by creating a floating output rule and using all TCP flags and sloppy state.

@johnpoz
Thanks! After displaying the rule description i noticed that for my OpenVPN Client all incoming Traffic in checked against the Rules in the "OpenVPN" Tab and not against the rules in the "SERVER_VPN_NEU" Tab. In OpenVPN was only one block Rule only which i identified after displaying the rule description in the log.
I do not know why there is Interface SERVER_VPN_NEU in the log but rules are checked against OpenVPN.

I added the pass rule in OpenVPN and now it is working! Thanks all!

@asgr71 You can create a URL Alias. Not sure about sending credentials in the URL but it doesn't hurt to try.

@dridhas If you want to lock down a network/vlan normally you would allow only what you want..

Here is an example of a locked down network.

lockdown.jpg

So can ping the firewall, great for checking connectivity.. So things might ping their gateway in a test of connectivity, etc.

Allow dns and ntp

Then block all access to any firewall IP on anything else.. Block access to any other rfc1918 networks via an alias - this blocks access to other networks/vlans you might have.

Then last rule allows anything else - ie internet.

@johnpoz I agree with you, that's what I thought as well. I first only had the bottom 2 rules for the longest time i.e. the any to any rules. I couldn't get stuff to work on the NAS and by stuff, I specifically mean the following two things did not work...

Package manager couldn't load list of available packages Could not sync with Google's NTP time servers

The following things worked

Pinging domains from DS923 interface, which means DNS was working Accessing NAS GUI from the LAN interface

Then I tried the rules as I had them in the question for this topic, that didn't work either BUT it all started working with the rules mentioned in the reply.

But yes overall, the bottom 2 should have done the trick I feel like. I'll try disabling the 23,53,443 and 80 ones to try again.

@mr-crain No reason to reboot anything.. Just troubleshoot the problem..

First things - is traffic even hitting your port.. You also have nat reflection setup? How are you testing this?

Start with the basics - does the port forward work externally? Got to can you see me . org and send traffic to either 7780 or 27020, those are tcp forward.

Sniff on your wan of pfsense - do you see it hit pfsense wan? Pfsense can not forward something it never sees.

Ok if it hits your wan, sniff on your lan side interface while sending another test - do you see it send it.. If so then something else downstream, your sending to wrong IP or port, the device is not actually even listening on those ports? Host firewall on where your sending it.

If you go through the details in the link, you should be able to figure out your problem in less than 2 minutes..

If that all works - then you can move on to if you have problems with nat reflection.

edit: example.

I created a gateway and route to a downstream network 10.20.30/24

route.jpg

Now created a port forward to an IP on that network.

portforward.jpg

Notice as well that my firewall rules shows that traffic has hit this rule the 0/420 B after I sent some traffic.

So sniffing on my wan and lan you see pfsense sent it on. And if I look at where that traffic was actually sent in my sniff, while sent to the 10.20.30.42 address, the mac is to my downstream router I setup.

traffic.jpg

If this simple test works, and still not working - at least you know its not pfsense, pfsense did exactly what I told it too do.. See traffic on your wan address to port 27020, send it to 10.20.30.42..

@chrisfromdallas
The rule has to be added to the interface, where the traffic is coming in. So this might be IPSec in the office.

I was talking about your site before.
But if you have access to the remote site, est practice is to only allow certain destinations.
You can do this by addition the pass rule on IPSec, state the alias (for IPs to block) and check "invert match". So the pass then allows any, but the IPs in the alias.

@gtissington does your switch have a gateway, ie default route set? If not then no you wouldn't be able to ping from a different network..

example. here is my switch

sg300-28#sho ip route Maximum Parallel Paths: 1 (1 after reset) IP Forwarding: enabled Codes: > - best, C - connected, S - static S 0.0.0.0/0 [1/1] via 192.168.9.253, 9808:06:37, vlan 9 C 192.168.9.0/24 is directly connected, vlan 9 sg300-28#

@johnpoz
ah ok as for my home assistant ips
they are
192.168.0.12
192.168.10.12
192.168.20.12
those are the vlants to the main home assistant
then
192.168.0.10 is another

and then on my sisters network i do the openvpn site to site
its
192.168.1.12

and what i didnt understand is if the first rule says use default gate way which is wan then the 2nd rule saying use the the vpn the wan superceeds using vpn thats what i ment..

im having troubles i going to play around and ok good i can delete the grayed out ones.. wasnt sure.. i going to try some things later..

i learning by trying... (: i appreciate the help so far.. least i can access the networks from LAN...
i just never figured why i get more dns results on LAN then the IOT but going to play a bit and see how i do (: im sure ill have questions tomorow.. so i really appreciated the help so far

@michmoor due to security and GDPR reasons ClouldFlare is NOT an option for me. I use my own server at a hoster in Germany and not services like CloudFlare or similar. So only the first option would be interesting, although I have no idea how this could be set up without any example or tutorials.

@steveits i actually had to change the ttl from the default of like 15 minuytes to 5 minutes...that fixed it..:)

@provablueteam123 just add an any<->any rule on top of the ruleset

@bmeeks said in Device discovery across VLANs?:

If your home LAN does not contain the secrets to the alien technology stored at Area 51

haha - how did you know I had those ;) The example I use asking home users about their security setups, more related to when they use disk encryption and then forget to back up the keys, and then redo their OS install and wonder why they can't get into their data..

Not like your storing the nuclear launch codes are you?

@scottlindner yeah that was not meant to be towards you - that was more a personal joke between me and bmeeks.. Sorry I prob could of sent that to him directly.. I personally am not a fan of breaking the L2 barrier even on my home network.. But that is me, it has valid use in a home setup sure.. Unless you do have the launch codes for the US Nuclear Arsenal? hehehe

I have a few posts around here about setup and validation of avahi, but depends on what exactly your using for discovery avahi is for mdns, and you need a rule for the multicast address, etc.

Me not being a fan of it, doesn't mean not willing to help others set it up and validate it works. Me personally for like my printer and air print.. You just have to be on that wifi network to use airprint. Easier to just put the printer on that vlan, My PC can just point to its IP to print, no need for discovery anything. And I have nothing else on my network that would even leverage discovery.. Maybe the roku apps on my phone, but if you join my roku wifi network you can discover, and once you discover you don't heed to be on that network any more to use the remote on the phone, etc.

@1-21gigawatts Does the hotspot network overlap with the OpenVPN server network you created?

@carrzkiss still at 1 ms TTL..

And your SOA expire is set below the recommended level at only 604800, rfc1912 recommends 2 weeks as the min value.

Your TTL in your SOA is set to 1 hour, 3600 but you prob have 1 second set on your actual records.

@4rr3n said in WAN Modem and VLAN Firewall Rules:

@gblenn @johnpoz @SteveITS @mvikman Thanks for helping me out with this one, your knowledge and provided information helped a ton. This whole setup was a nightmare to configure. After taking a short break, I started over and finally managed to set it up. However, I still have two remaining questions.

From my testing, it looks like the virtual interface that is used for PPPoE to pass over the traffic from VDSL line also have access to the Web GUI of the modem that is accessed via its own physical LAN interface. I was able to confirm this by pinging LAN interface of the Modem from the WAN interface in pfSense.

Is this normal behaviour for this type of setup or should I worry as things are not correctly configured ? On the surface, now everything works how I want it to but not sure about this one as I don't want to expose anything on the WAN side.

The last question I have is, my modem provides ports to use like SSH, I tried to find more information about this but was unable to find anything online. The Modem settings only give me ability to allow or deny access to the said port on the LAN side but not WAN, does anyone know if Modems by default expose any such ports on the WAN side when used in bridged mode ?

I appreciate all the help I'm getting here, I know it's a lot of questions I'm asking but I'm new to pfSense and haven't dealt with such a setup before.

Not entirely sure what you mean "virtual interface has access to web GUI"? The LAN side of the modem is protected and separated from it's WAN side by the firewall built into the modem/router. The fact that you can ping, and access it, from pfsense is like I wrote above. You should in fact be able to ping the LAN side of the modem from any device behind pfsense, unless you explicitly block that.

If you try to ping from the WAN side (your actual public IP) your modem will probably not even reply. SSH is a safeguard to be able to access the modem in case the GUI isn't working, or for more advanced control of the device. You can safely turn that off!
And IF for some reason it is available on the WAN side, you should absolutely turn it off...

Bridged mode (or DMZ) means that all ports are "passed on" to pfsense, and it's pfsense responsibility to be the firewall, which it does in an excellent way of course. But there is no simple means of accessing ports on the modem, "reaching in from the outside and somehow in between" the modem and pfsense...

The only reason I can think of a modem exposing a port would be if the ISP has it set up for remote support. But I doubt they would use a known port like SSH... Probably some random port very high up then...

Having now implemented and tested this, I believe that it still acts as a match/pass but will not create additional states when it's at the limit set by this option.

@mucip said in Adding in to Alias and reload firewall from command line?:

Hi @bmeeks ,
Ok. I will try to live with this fact. Thanks... :)

Regards,
Mucip:)

You can see the IP addresses you add at runtime by going to DIAGNOSTICS > TABLES in the pfSense menu and then choosing the table name correspondig to your alias. Literally that PHP code runs the same pfctl utility to dump out all the pf tables and their content for display.

But the GUI stuff under FIREWALL > ALIASES won't see things you do directly in the pf tables using pfctl yourself.

@jarhead Thank you, that may be the only thing I may have right. elmo

@jlee_eye Issue resolved.

@viragomann Got it, I thought the package would be re-evaluated by the WAN again 🤕
Thanks for the clarification.

@efny Either way works. Listening on WAN is a bit less complicated. Either type of rule can have a source alias.

@thewaterbug

More progress on this. I moved the Blue Iris (NVR) server to the .50 network:

4cb00e44-1521-49d0-a0d6-cf3cb9dda2f2-image.png

and experimented with the fw rules to figure out how to allow access to the cameras that are still inside .0, and eventually learned I had RTSP "backwards" because it's pulled from the camera and not pushed by the camera. And then I learned about ports aliases and condensed it all, thus:

944ad159-9ce6-4511-8c0f-fb74c253582a-image.png

A bunch of this will be moot once I migrate all the cameras to LAN50, but it was a good exercise figuring out how to grant access without the default LAN any rule on the LAN50 side.