Yeah blocking it is fine.. I do it for both doh and dot.. Dot is easy just block port 853.. But doh can be problematic to block since its just standard 443. But tricking a client into thinking its talking abc, while its really talking to xyz is way more tricky. Unlike with normal dns over tcp/udp 53.

@logboss Not in a ideal way with specific miracast ports. I simply assigned the TV a static IP and added Allow rule from TV to Office Net and from the Office Net to the TV. So not they can communicate on all ports to TV IP. Not great, but it works :-) IOT Net Rule [image: 1623243945330-screenshot-2021-06-09-at-16.05.16-resized.png] Office Net Rule [image: 1623243951283-screenshot-2021-06-09-at-16.05.08-resized.png]

@lightningbit Indeed :)

@nuclearstrength I can't speak about your issue, though I expect it should pass both. However, with firewalls you only open what you need. If you use only UDP for OpenVPN, then you only open UDP.

@jimp said in Upgrading pfSense 2.4.5.1 to 2.5.1 unknown file system: I'm afraid it wouldn't be recognized as a bug in pfSense as there is nothing we can directly do to solve it. Logic would dictate that since I tested with FreeBSD and it was fine that you folks can look into this and determine what is causing it and directly take action and use a kernel/configuration which works. Now if you folks are not willing to do that based on your reasons then that is another matter. I tested with 2.5.2 and it has the same problem. I feel I have provided sufficient information here to have an engineer track this problem on your side to start looking into this further if someone really does care and wants to fix the problem.

@watkinsufs Why do you need to do all these things? Just ignore it and move on. Looks like some client doing a dhcp-discover and your WAN is blocking it like it should.

@viragomann said in Portforwarding on WAN next to VPN configuration: @blvermeu said in Portforwarding on WAN next to VPN configuration: One last thing I can think off is that this simply does not work when having the VPN tunnel as the default gateway, would there be a way around that (besides specifying the gateway under the fw rule)? It doesn't work on 2.5.1 due to this bug: https://redmine.pfsense.org/issues/11805 But it should work well on 2.5.0 and 2.4.5. However, why do you need the VPN as default gateway, since you policy route the VPN traffic anyway? Simply check "Don't pull routes" in the VPN client settings and modify your firewall rules if needed. Thank you, that is indeed a good remark, i'll try and play with this go get the WAN as default. I guess in the past I wanted all traffic to go by default on the VPN and only by exception via WAN, but i might rethink this strategy. On a different note, i was not fully aware that the default gateway for VPN was not required (when doing policy routing), i'll also try to take a look at this. @viniciusmerlim said in Portforwarding on WAN next to VPN configuration: @blvermeu said in Portforwarding on WAN next to VPN configuration: round-robin This will be fixed on version 2.5.2. Maybe there are some patches to fix it by now. Did you check this? Thanks so much both for the feedback. It's good to hear it is going to fix itself eventually, i will nurture some patience meanwhile. Do you have any idea when the next updates that will address these issues will be 'public' and by public i mean not in Beta... :-)? Thank you and kind regards! Ben

@bambos Blocking access to the interface will not block traffic passing through it, as the interface IP address does not appear in any packet passing through the router. Only if you use the interface address as the destination will it be blocked by a rule to block such access.

@kom Thanks for the fast reply

@gertjan thanks a lot Gertjan for the video.

@kom It worked like a charm. I have been able to get everything running. I am moving on to the next thing to check off my list. Have a great day and thanks again. Dragonrider68

Yeah some shitty apps might require L2 discovery only, and have to be on the same network to find the camera. Depending on your setup functionality.. You could join say your phone or tablet to wifi that is same L2 as the camera. You prob want to look for a camera that software allows for just IP or FQDN without having to use discovery protocols if your go is to not let it use the internet and then use locally via browser or app..

@nghia1123 The closest you might get to that is the Snort or Suricata packages.

Thanks! Will get on it. Enjoying pfsense but still get hold of it so we can then start promoting it commercially. Best regards

@sfjames You need a VIP and a port-forward. VIP: Add an IP Alias VIP: Interface - WAN Address type - Single address Address - one of your IPs (not the WAN one) and the mask you got from your ISP, likely a /29. Create a NAT Port-forward: Interface: WAN Address family: IP4 Protocol: TCP Destination: Your VIP Destination port range: whatever ports you need for your server. You can create a ports alias via Aliases and then use that here. Redirect target IP: Your LAN server Redirect target port: Use the same port(s) or alias as above That's all you need to do. pfSense will automagically create the required firewall rule on WAN. To test, you need to go outside your network via your phone or VPN. You will have to update your domain's DNS records to point to that VIP if you want to access your server via it's public name. From inside on your LAN, you should create some host overrides in pfSense DNS (Resolver or Forwarder, whichever you use) to resolve your servers FQDNs to their LAN IPs. Aliases Port Forwards Troubleshooting NAT Port Forwards

Its easier to spot when they post the rules on the interface vs specific details of a rule. All that is needed to be seen to know if the rule is correct or not can be seen on the interface tab - also shows order and other rules that might prevent rule from working, etc.

@heper Yes, thank you for elaborating on that, I do understand and I have used this in the past for ad blocking scripts on other brands firewalls. In this case though, DNS is not the issue, but I am now 100% sure that I made a mistake using the RFC1918 rule for LAN side VLAN segregation. This worked flawlessly on my previous (UniFi USG) firewall, but now with pfBlocker there is a conflict. I created a new alias with only the local networks used by my VLANs (all within 192.168.0.0/16) and this has definitely solved the issue of slow web page loading. Thanks for your input! Pete

@steveits Got it. They're talking over the switch. Thanks. VLAN or don't use as wifi thermostat are only choices unless I leave on home LAN.

@kom yeah I completely overlooked that. I actually felt really dumb when it crossed my mind that the WAN address is that particular router address and not the outgoing address. I'm sorry for taking your time really, kudus for trying to help!!!

Great suggestion! Thank you. Ticket resolved.