Hello together again,
creepy. Two days ago my PFSense wasn't able anymore to connect in anyway to my CG VPN Service. Always "decompression failure" or something like that appeared.
The final solution was to change from adaptive LZO Compression to OMIT Preference. Then this connection worked again.
And what started to work as well? The VOIP Connections. I don't know how this belongs together, but now i can register like always my softphones and make calls. I think we would have searched years to find this out...But well, fortunately finally now it works again. That is the most important!
Thanks again anyway for the interesting information you posted here and the support you gave!
Have a nice weekend
Do not post them directly here! There is quite a lot of stuff in the config you probably don't want public.
You could use the redacted config from the status_output file. Go to <your firewall IP>/status.php to get that.
But even that has your public IP etc. We probably only need the interfaces and dhcp sections as I said. That should show any mismatch if it's happening.
Steve
The device must have came from those who has access to your LAN...either household or guest. I even believe your Alexa uses Android. For sure, pfSense has NOTHING to do with this issue.
@stephenw10 PFsense is definitely logging events (within the Firewall log view).
Currently, the log is only showing the denied traffic.
Based on the timestamps, it looks like I am not encountering a DoS attack.
[image: 1588883599779-screen-shot-2020-05-07-at-4.32.04-pm.png]
That's helpful, thanks. I am recreating the rules on pfSense B, rather than trying to import them.
pfSense B currently has two em NICs but I will be adding two vmxnet NICs in the next maintenance window, then two more in a future maintenance window. I will be watching for reordering as they are added.
Yes, I completely agree with that. Having pfBlocker create aliases only and assigning them yourself allows you to see exactly what's happening. That's how I use it.
Steve
Try a port test to the site from pfSense. That should work though if other clients behind it can access the site.
Run packet captures to see what's happening. Is traffic for the site actually arriving at the internal pfSense interface?
Is it leaving the WAN? If not where is it leaving, if anywhere?
I assume you do not have Snort or Suricata running?
Steve
@WAR10CK said in Intel gigabit ct Desktop not detected:
AHCI enclosure management bridge
OK, pfsense recognizes the netcard, but why is it saying : AHCI enclosure management bridge under interface em0.
There is no link when I plugin the cable to em0.
The cable works fine in em1.
Does your WAN have a public IP? miniupnpd cannot open port forwards from private IPs.
You should at least see the logs from miniupnpd starting in the system log when you save the config or restart the service.
Steve
That matches the string anywhere in the port number, same as leaving it as 19 which isn't what OP wanted. They wanted it to only match port 19 and no others, so using ^19$ is the way to do it.
@NogBadTheBad Thank you for sending this documentation my way!
As it turns out, what I (originally) wanted to do can be accomplished using an "Alias".
https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html?highlight=alias
You were right. Interface Groups serve an entirely different purpose.
@moxi said in Some traffic is escaping from vpn!:
but why the firewall rule of: ( block any out on wan) never works?
Can you show that rule (an image ;) )?
Where did you put that rule ?
A final solution will be : use the VPN client on the device where you use the VPN. That is, if that device isn't a TV set or something like that.
@moxi said in Some traffic is escaping from vpn!:
I would start thinking that this whole game of privacy protection is not 100% legit
You start to understand. There is hope for you.
You really believed the VPN publicity ??
The outbound NAT rule would be on the WAN at site A with source 10.2.0.0/16. So that traffic from site B can be NAT'd to the site A public IP in order to reach the site C public subnet.
Steve
I think the best you’re going to be able to do here, to avoid a login, is to have your browser (Firefox, Safari, Chrome) save the login info for you. You DO NOT want to give access to your firewall interface without a login. That’s really bad.
Jeff
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.