@erdosain9 said in Block android apps (netflix, youtube, spotify): it does not block applications. This somewhat proves that "app's" do not use the web server of the same resource. Ports and IP addresses are probably different. Two solutions : Reverse-engineer the app to find the IP and port info. or "Wireshark" the traffic generated by the app. IP and port info will show up.

@cheapie408 said in Ways to manage devices on network: IE: All networking related stuff IE, Switches, Routers, AP etc... would be between 1 to 10, all IOT devices would be 11-40, IP Cameras would have it's own range. Makes more sense to do that in CIDRs not decimal ranges.

NVM discovered the issue was with Squid. 2nd time since the installation of Squid. I have to disable the services, make sure the device gets online then re=enable it and it seems to work there after.

@Derelict said in Confused about ISP setup: You could also bind the OpenVPN server to localhost and forward the ip_address:1194 to 127.0.0.1:1194. In your situation that is probably what I would do. Doh! I don't know why I didn't think of this.. it sounds perfect! I'll give that a shot tomorrow....

@mveplus said in Release of aarch64 images for espressobin v7 board: First product equipped with Microchip CryptoAuthentication Device which provides assurance your system is running authentic, unaltered pfSense software Does it mean that Netgate SG-1100 hardware based on Espressobin v7 has additional build in hardware signature chip? Quick skim of the V7 schematics does not reveal any Microchip authentication processor. Would that prevent installing ARM recovery image to a vanilla board? Best regards, Martin My testing says yes, that chip prevents all kinds of things from working. The recovery USB fails with "no valid serial" and "no Thoth module found". Upon getting pfSense to boot on my Espressobin via microSD going a different route, I have also found that it cannot check for updates which I also believe is based on having a working CryptoAuthentication device. Would be great to see a community edition but they sure put in a lot of effort to prevent vanilla Espressobin devices from working. I don't mind buying the devices from Netgate, I just hope they don't EOL as quickly as some of their previous ARM offerings. I would imagine the espressobin will still be for sale long after Netgate stops selling a product based on it. Maybe that's when we'll see a community version. EDIT: Yes, there really is an extra chip inside. My SG-1100 has a cool little board soldered to GPIO.

Check this: https://docs.netgate.com/pfsense/en/latest/routing/unable-to-access-some-websites.html But I would check MTU or bad subnet/mask first. Steve

Thank you everyone. So both the fixed ip set on device and those set on pfsense must not be in the dhcp pool. I will have to change some of my fixed ips. I will definitely install pfblockng.

If you're using firewall rules based on url aliases and the firewall is using different DNS to the clients they may be resolving differently and therefore not applying. If those URLs resolve to many URLs such as, for example, google.com they will likely never be effective as the IPs change frequently. Steve

You can lagg the two SFP ports and connect them to your switch. That will hive you some redundancy but won't improve the speed since they are each 10Gb anyway. Using the SFP ports connected to an external switch does make it easier if you want to bring in a number of VLANs for example. You would have to tag those through the internal switch otherwise. You can use outbound NAT rules and port forwards for individual IPs in the DMZ if you wish. Or 1:1 NAT rules to achieve the same. If the /29 is routed to you via another IP you could just use it on the DMZ interface directly. You do lose an IP as the interface address though if you do that. Steve

So what is the actual problem here? You are unable to browse the web from clients behind the firewall? That blocked TCP:SA traffic looks like a coincidence to me if it's always from the same remote IP. It's something in particular triggering that. Do you have outbound NAT set to automatic still? Check the routing table in Diag > Routes, do you have a default route? How are you getting a WAN IP? DHCP from your ISP? Is it pulling a valid IP and gateway? I would assume it is since you can ping out correctly. Check you can open TCP connections? Go to Diag > Port Test. Try to open port 443 to netgate.com. When you try to open a webpage from a client what actual error do you see? Steve

I think this will help you https://docs.netgate.com/pfsense/en/latest/book/config/what-to-do-when-locked-out-of-the-webgui.html https://forum.netgate.com/topic/13464/change-firewall-rules-with-shell

Yup, connect over VPN is most secure method and hence the recommended one. https://docs.netgate.com/pfsense/en/latest/firewall/remote-firewall-administration.html Steve

@Pippin Thank you for show me the origin of the issue. Pointed on github.

EDIT: Full TCP dump of switching cables to fiber ISP and then renewing/releasing DHCP in the UI: https://gist.github.com/marshallford/f6fd85988b2ceaed882cec37038efcfd EDIT 2: TCP dump of plugging in fiber directly to linux laptop: https://gist.github.com/marshallford/c67afcfb121c13f20df8dc830fc50b13

That is out of the box how it pfsense is - nothing to do for that.. Not sure what part your not understanding about the default deny.. All unsolicited traffic inbound to pfsense wan is just dropped.

Nice!

I didn't see that one, but I'm not terribly crazy about adding even more JavaScript to work around that. Might be worth considering, at least.

You can block without trusting.. You have to use explicit (I believe), ie the client has to point to the proxy.. It will send the connect command for https, so proxy know where trying to go, and can either allow or deny based on that host name... What you can not do is allow say www.domain.com but block www.domain.com/something without doing mitm... Since onlly the host is sent in the connect. There is a hangout that I believe goes over this stuff - let me see if can find it. edit: here you go https://www.netgate.com/resources/videos/squid-squidguard-and-lightsquid-on-pfsense-24.html [image: 1563542241750-peek-amp-splice.png] edit: Also if all your looking to do is block access to sites, be it http or https wouldn't pfblocker be another option?

It seems that the secure shell daemon not have been running for some reason...all is good now.

Ok @jimp thanks for the feedback. I do hope you can add that to the roadmap, I'm sure it would be useful for many. Best regards.