@jimp Dude... You... are.... an... angel!!!!

I totally missed this and would never have thought of looking for this. You nailed it.

I just tried some scps just to see that uploading through the ipsec tunnel immediately failed and was suspecting my fibre provider etc. It was exactly as you suggested. Applying the patches and rebooting brought be back to a workable state and most likely will have solved my sshuttle problems as well.

I honestly cannot thank you enough! Well done mate!

@kprovost let me start out with two things:

Many thanks for your assistance. I really appreciate it. I obviously need more coffee... The target IP was a typo. I have not spotted that earlier since all my tcpdump were filtering for port 2055 only and of course I would have suspected to see outgoing packets of some sort (which I still do not understand why this was not the case).

However after fixing the typo netflows are being received now and I feel extremely stupid for not having that spotted earlier. Many thanks! Apologies!

@Rapho have youo read "Manually editing the configuration > Edit In Place" in the docs?

As in remove the /tmp/config.cache and restart/save/reload the part of the config you changed?

@Antibiotic look in your state table if client on your network is creating that traffic.. I take it that 92.x address is your pfsense wan IP..

Could be something inside your network trying to go there..

Example, if I try and go to https://10.0.0.1 my outbound rule blocks it.

rfc1918.jpg

If it was related to your vpn why would pfsense send it out your wan vs out your vpn.. Could just be a client on your network, my work laptop when the work vpn on it disconnects I see it trying to talk to work stuff on rfc1918 because yeah their are things in the work network its wanting to talk to - but the vpn is not connected.

From those vpn networks unless they have /8 for a tunnel mask, or there is something on remote network via those tunnels on 10.0 your wanting to talk to and you don't have routing setup right for what is on the other end of your vpn tunnels.

ugggh - I forgot to setup sniff for that dhcp traffic..

@SteveITS exactly.. Notice the RAs to those 3 IPs.. Its possible their was fin that closed the state but the client didn't get them for whatever reason, so it sent an RA (reset)..

@jacobrale I wouldn't worry about them too much to be honest.. Unless your log is just being flooded with them, then you might have something going on that you should look into. Those don't have anything to do with some dns related problem your having - again if your client was doing doh to google dns, it wouldn't be going to those IPs - so those for sure are not related to any sort of dns problem you might be having.

I personally don't even log default deny.. I log specific rules. And for noise coming into my wan, I only log syn blocks and common udp ports.. The rest of the noise I just have no desire to fill my logs with.

If something wasn't working and thought it might be helpful to see the default deny logs, can always click and they are now logged. But day to day its not really of interest to me to see a bunch of noise filling up my logs be it local side interfaces or the wan.

@tinfoilmatt I get your point. Whether you think my approach or the approach of doing it the way pfblocker has it is kind of semantics. People are given tools, how those tools are used is up to them. I personally like the tool that gives me more flexibility and control over what can or can't be done on my networks as I see necessary. If pfblocker is capable, I would like to know the secret.

PS. I still love and use pfblocker, so I'm not bashing on it here. I use pfblocker in the office. If I had a choice, I probably would run pi-hole there too, but it's easier to just enable pfblocker within pfsense and not have a separate server just for that.

@johnpoz At abuseipdb.com you can check it out.

@bescher said in Error on firewall:

Unresolvable source alias 'pfB_PRI3_v4'

This feed contains a bunch of urls to about 4-5 feeds. If one of that feeds is unreachable it trows a error that affects the 'pfB_PRI3_v4' feed. Look what feeds are included in that 'pfB_PRI3_v4' and try to call each of the urls in a browser - so you can determine wich one is failing ... IMHO

My 2 cents,
fireodo

@Robust Have you solved the issue? Where did you find the Dropbear?

@Cowby01 said in file encryption:

I want to use pfSense along with some type of encryption to ensure that all server files are not accessible on machines outside the company network.

You can use pfSense as gate to your network. By default it lets traffic out but nothing in. You can also limit outbound direction if you desire.
But pfSense doesn't encrypt files, that are stored on any other hosts inside your network.

You can encrypt data in motion, when you want to access your servers from outside by using a VPN. This can be terminated on pfSense though.

Go here :

264159ed-298c-492f-93da-bf0195c5dc91-image.png

and enter IGMP.
Hit the Search button.
Pick any of the recent (last 6 months or so) search results.
read one or 2 of them. Apply what is suggested.

Thinking more about it, I think my problem is that I don't know what "interface subnets" means for IPv6.

Does it mean, "the address of the interface/64", which in my case would be the /56 from my ISP + the prefix configured in pfSense?

I tested this with pfSense Plus and CE and only CE is affected. My guess is that the new Firewall State Policy is not fully implemented in CE right now. Or it is a difference in the WireGuard Package.
Edit: I created a report on redmine.

Working:

Spoiler

Working.png

Not working:

Spoiler

NotWorking.png

Edit: Fixed it by upgrading to plus. 😉

@Uglybrian Thank you so much. My LAN3 is working now.

I had similar setting to yours:
c49a79ef-7b09-447e-bd92-ccc5005d1f1a-image.png

So the changing the "Kea DHCP" to "ISC DHCP (Deprecated)" has fixed the issue?

Thank you both! This was exactly the issue; subnet was configured incorrectly on the device at 192.168.20.4! Thank you!!

@clawsonn In my case, I had a bad WAN connection that was triggering this issue. It was also making HAProxy crash. As soon as I disabled that WAN (it was a 4g backup), everything went back to normal.