@jahonix Thank you for reply. Actually ,it has only one internal interface(em1) whose ip is 192.168.56.40. and the internal network has only one host whose ip is 192.168.56.42.

@jimp Will do, thanks.

Solved my own problem by disabling the rule associated by my limiter. Thanks Mr Derelict for the time. [image: 1561379011019-disabled-limiter.png]

So it was the source port after all. Glad to here you got it working.

Here or General Questions.

@neti said in Protect Systems behind pfsense for SACK Panic - CVE-2019-11477?!: My Question is how can i protect Servers behind the pfsense? Can i use synproxy to protect the Servers? Can i use pf scrubbing? I cannot find any filter option for min or max mss. pf doesn't have an option to check the MSS explicitly. There is a scrub option to enforce a maximum MSS, but that's it. The scrub function doesn't check for a minimum MSS as far as I can see. I'm not sure if synproxy would help you, it may introduce some other problems as well. Worth a try if you have an exploit test you can run against a vulnerable system.

@Gr8Britton said in Cannot resolve any sites at https://go.microsoft.com/fwlink/?LinkId=: @bmeeks Ah, I see that now. There is a tab titled WAN Rules. Well, I probably can't figure out what it was, but it should be good now. Thanks! You can see exactly which Snort rule blocked by going to the ALERTS tab, choosing the WAN interface in the drop-down at the top, and then looking through the list of alerts to find one containing the IP address that was blocked. In your case that was 23.65.34.215. Find that alert in the DST column. If I recall correctly, you can click the DST column header to sort by the data. On the row for that alert it will show you the rule GID (Generator ID) and SID (Signature ID). The GID is usually "1" for most text rules. The SID, as I said earlier, is unique to a specific rule. In the right hand column you can find a summary of the rule's message. From that you can usually guess which category the rule is in, but the SID will uniquely identify the rule. P.S. -- the above assumes your network traffic is not so high as to cause the alerts log to rollover. In that case, that alert may have rolled into an archived log and no longer be visible using the GUI tools.

Looks like that alias was corrupt for some reason. I re-created it and made sure it looked proper in the tables and now i'm good to go. Thanks so much for all your help.

ok, this is now fixed in case anyone else has this issue this is where I started to realise what was wrong.. [2.4.4-RELEASE][admin@pfSense2.localdomain]/root: pkg update -f Updating pfSense-core repository catalogue... pkg: Repository pfSense-core load error: access repo file(/root/var/db/pkg/repo-pfSense-core.sqlite) failed: No such file or directory pkg: https://pkg.pfsense.org/pfSense_v2_4_4_amd64-core/meta.txz: No route to host repository pfSense-core has no meta file, using default settings pkg: https://pkg.pfsense.org/pfSense_v2_4_4_amd64-core/packagesite.txz: No route to host Unable to update repository pfSense-core Updating pfSense repository catalogue... pkg: Repository pfSense load error: access repo file(/root/var/db/pkg/repo-pfSense.sqlite) failed: No such file or directory pkg: https://pkg.pfsense.org/pfSense_v2_4_4_amd64-pfSense_v2_4_4/meta.txz: No route to host repository pfSense has no meta file, using default settings pkg: https://pkg.pfsense.org/pfSense_v2_4_4_amd64-pfSense_v2_4_4/packagesite.txz: No route to host Unable to update repository pfSense Error updating repositories! checked route out f the firewall - not looking good [2.4.4-RELEASE][admin@pfSense2.localdomain]/root: host -t srv _https._tcp.pkg.pfsense.org _https._tcp.pkg.pfsense.org has SRV record 10 10 443 files01.netgate.com. _https._tcp.pkg.pfsense.org has SRV record 10 10 443 files00.netgate.com. [2.4.4-RELEASE][admin@pfSense2.localdomain]/root: route -n get default route: route has not been found checked the default gateway which was set to the WAN_PPPoE gateway, changed this to the VPN gateway and I the firewall can now route traffic and can see the lists and packages

@Derelict I know I just didn't want to affect a client that we have constant vpn connections to 5 sites. I know a update shouldn't affect that but seems like any time I make a change something happens which has given me a type of superstition lol. They will be off service as of July 1st that was my plan to update Pfsense then. I am a huge PFsense fan boy and have been super impressed with it though thanks for taking the time to respond to me as well really appreciate it and answered my suspicions.

@JKnott said in Updated from 244pl1 tp 244pl3 now super slow FTP: @Kartoff said in Updated from 244pl1 tp 244pl3 now super slow FTP: Most of the times I use it within my LAN, so only me and couple of my friends who I gave connectivity can get into it... Anyone with Wireshark and access to your connection will be able to read your ID and password. Use SFTP. Usually I don't put login credentials... So nobody can see username and password, they are simply aren't there :) When it is shared on the FTP it meant to be seen ;) If I do not want anybody to have access to particular data I just don't put it in the directory where FTP server has access !

Yes, Suricata can drop packets within a session using its Inline IPS Mode. However, this mode uses the netmap OS driver and that requires your network interface card (NIC) be one of the supported driver families. Inline IPS Mode does not block a host IP address in the same way the Legacy Blocking mode does. Instead, it uses a netmap pipe between the NIC driver and the kernel OS stack and selectively drops packets that match Suricata rules. There is a new Snort package available for pfSense-2.5-DEVEL that also implements the same Inline IPS Mode of operation (and with the same netmap driver limitations). The new Snort package allows you to leverage OpenAppID to detect Layer 7 applications and drop those packets. Details on both packages can be found in the IDS/IPS sub-forum here: https://forum.netgate.com/category/53/ids-ips.

i stand corrected regarding the behavior of pfsense which actually does not forward packets with the broadcast address as a destination. ( axcept afaik in some weird cases with policy routing. pf does ). but it does forward some crafted packets using a different network's broadcast as the source or destination. ( which unfortunately would not be handled by :broadcast since pfsense has no way to determine the address is indeed a broadcast so no-go anyway ). i'm not seeing anything. i just want to prevent such attacks while keeping my ruleset as simple as possible. thanks. there is indeed quite a range of attacks using broadcast addresses for the source of packets and 0.0.0.0 as well. regarding multicast, i have those as well. a way to match them as a whole would be very convenient to prevent them from being logged. but that can be performed with a small number of rules. since what i am trying to achieve here is indeed the default behavior, i'm sorry for using up your precious time. thanks again.

Your Config is wrong, check https://docs.netgate.com/pfsense/en/latest/book/openvpn/bridged-openvpn-connections.html and follow the steps. -Rico

Thanks. Ill keep that in mind for next time. It would be nice to have multiple alias inside the rule, rather than nested alias In any case, ill leave it how it is - as its easy to read for troubleshooting :) Thank you

When 2.5 is out of development. https://forum.netgate.com/topic/143624/snort-package-potential-new-feature-teaser/11 https://forum.netgate.com/topic/143812/snort-package-4-0-inline-ips-mode-introduction-and-configuration-instructions