@ri Add a rule on the Admin Gateway interface to allow it. Firewalling Fundamentals Troubleshooting Firewall Rules

@kom Thanks for the reply. I haven't touched the settings, so as of now all hardware offloading is occurring. I have a 100x5 comcast internet connection through a motorola modem, and i get about 100-115 down, 6Mb up. however my apps that i run ARE latency sensitive.. plus it says in the documentation (as i understand it) that the hardware offloading could be detrimental to performance. yeah, i'm kinda splitting hairs, but.. Thanks!!

@jorge-silva said in Rsync issue - cant do a rsync to a external NAS: My pfsense is totally open, i dont have any rule beside the original ones. With the original rules, the system defaults to being totally closed. I tried to connect to our external QNAP with another client QNAP, and no error is given, so, it is a problem with the pfsense. It's a problem with your configuration. If you want Rsync to be open to the Internet, you must create a NAT port forward and point tcp 873 to the ip of your QNap. e.g.- WAN TCP * * WAN address 873 192.168.x.y 873 rsync to qnap

@nogbadthebad I see. I don't know it.

nice for everything you can learn, thank you very much for the info, it's a bit easier and faster to play and learn now to make it happen.

@johnpoz As its setup in High Availability Sync the guide said to use manual outbound NAT Thanks Dan

@viragomann came back to this. Thanks again for pointing me in this direction. im so impressed with the pfsense documentation!

@cire3 said in Only Some of my Port Forwards work ?: @nogbadthebad Just downloaded it and going to check it out, didn't know about the Windows Version :) This is what I have (Does being on a VPN change it ? I'd run the test when disconnected from the VPN and try to establish what you were told by port forward ties up.

@viragomann said in DMZ configuring: @mynetworkrocks Damn! You said, the USG does not respond to ping. So you cannont use it for gateway monitoring at all. The gateway might get marked as down (check in Status > Gateways), hence pfSense ignores the route. So best to disable gateway monitoring here, since it is a local gateway anyway. Dam! that was it, the monitoring was disregarding the route ..... so I disabled the monitoring and disabled the monitoring actions and it worked straight away :) The USG doesnt allow it to be "pinged" but the routing works now :) Thank you sir!

@detox said in exclude local IP from firewall rules: What I need to do is be able to configure and test it before I deliver it. There is nothing to do but plug it in. It would work out of the box.. As long as its wan and lan networks do not overlap. Since it would be natting. To configure this 2nd pfsense - access the gui from its lan side 192.168.107/24 network. Create a rule on its wan to allow gui access from your network, you will have to disable the default block rfc1918 rule on the wan. Since you will be coming from a rfc1918 network.

No states could still be there. It doesn't really come up that often... But states have bitten new users a few times wondering why their block rules are not working.. Normally because they just did a test before they did the rule.. And that state is there, on the exact thing they were trying to block ;)

He also has pfblocker floating rules that could very well be blocking.. And still hasn't shown what he is using for auth.. From what reading you have to be using oauthv2, etc.

How litteraly should the "not allowed on lan" be taken ? 1: If really litteraly , you could acheive the "allowed on lan" via an "intelligent snmp write capable switch" and have the switchport in shutdown state , until the condition arises , where you then send a snmp comand to open the switchport interface. 1.a: This will still require some pfSense magic , to switch the default gateway, from the "landline gw" to the "sat gw" 2: Leave both "gw's" turned on , and control the dataflow via pfSense routes , and some "ping magic" .... See 1.a @johnpoz Would know more abut the 1.a pfSense stuff /Bingo

Thank You NogBadTheBad and johnpoz

@viragomann routes? bro im connecting from my router gui, I have an option for this. I can do everything except ping the server and connect to the gui while connecting to the vpn .

@spookymonkey It's been a while, but I started with default deny all-interfaces, skip lo0 then started adding allow rules. Suprisingly few are actually needed, less than a dozen. Windows Updates does some weird stuff to broadcast and port 0 but for normal operations the allowed list is pretty short. You wind up seeing some "co-opting" of protocols (something that is normally TCP only Google decided to use it as UDP for something) so you need to adjust things. Packet capture/analysis: google up Wireshark. Lots of good information. You can wind up banging your head, so pick one thing and trace it (NTP is a good one to start with I think). It's not just about the packets, it's about the contents of the packets and the protocols (TCP vs UDP) so get used to looking at specific bits in packets. Can make your head hurt at times, but what you see on the wire is what you are working with. pfSense and pretty much every other commercial solution has a "default deny in WAN, allow all out WAN". It's the best way to get things to work, but I think you need to keep an eye on the LAN side to make sure you don't leak things (my opinion figure out what is best for you). Most important: have fun.

@kom Thank you, that was a great explanation. I have it sorted now.

@dotdash It may just be a bug with the current firmware. It's supposed to work, at least based on what people say on the forums. Maybe I'll look into downgrading since it looks like trying to mess around otherwise is just not gonna work or be overly messy.

@viragomann So we set up another Front / Backend for sites that were not previously managed by haproxy. Everything works fine except the websocket connection. The strange thing is that the websocket connection no longer works even on the other local virtual machines on the LAN (which are not web servers).

@kom said in Why doesn't this rule work? Or are the logs going mad? Or ???: Nothing to be worried about. Not sure I would say that.. A few here or there than yeah prob not.. But if your seeing a lot of them - prob a good idea to track down that is causing them. Could be your states are being reset, wan going down can do that if you set pfsense to do that - which I believe is default.. IP change on wan another thing that could reset the states. If a lot of them - could be asymmetrical traffic flow, etc. A few here or there are normal with how tcp works and especially wifi devices trying to leverage an existing state after switching from cell to wifi, etc. But if seeing a lot of them - I would investigate to why vs just blowing it off.