Yeah that's a mistake. Corrected.

Not that I can think of. You can do a circular capture that keeps overwriting the older files but you can miss the event if you don't stop it soon enough after it happens. See if adding -p helps:

nohup /usr/sbin/tcpdump -i eth0 -p -c 1000000 -s 0 -w /root/packetcapture.cap arp or port 67 &

First of all, you need to clarify if the pritunl VPN users (while connected) will be "going" out with their 192.168.22.x IP address , or with the IP address of the Pritunl network interface (192.168.226.1).

Also, I assume that you have created a Server in the pritunl that assigns the 192.168.226.x IP addresses. In that server, you will have to add a route towards the 172.17.172.x network (see below)
b7fc52a1-f8e5-4555-8671-6d04a35c5b5b-image.png

After you do the above, then you can start pinging from a VPN user towards your Servers. In order to see if the Pritunl VPN user is going out with its assigned IP addres (192.168.2226.2) and not with the Pritunl server IP (192.168.226.1), go to Packet Capture in pfsense and check the traffic on the pfsense interface that belongs to 172.17.172.x network.

*I would create an alias for these VPN users and name it "OpenVPN_Users" (Alias type is network with an IP address 192.168.226.0/24).

Then I would go to the firewall rules and I would add a rule to allow the OpenVPN_Users network towards the 102.17.172.0 network. Not sure if you have to configure the Advanced Settings on that rule, but if you still cannot ping the servers, you may have to go and change the TCP flags to "Any" and the State Type to "sloppy" (see below)

4e012871-d683-4bee-a1e1-8e3c38a6307e-image.png

Also, I assume these VPN users will be having internet access via your pfsense, which means that they will be going to the outside world via the WAN interface. If so, maybe you would have to add a NAT rule, but check first if it works without any NAT rule.

I have not been able to reproduce the problem here, but I can see how it might happen. I opened https://redmine.pfsense.org/issues/9582 to track it and committed a fix: https://github.com/pfsense/pfsense/commit/45f95753963e497b5ce14493f9cca05336d75c7b

You can install the System Patches package and then create an entry for 45f95753963e497b5ce14493f9cca05336d75c7b to apply the fix.

Alternately, you can use viconfig to edit the config and remove that <vlans></vlans> line, or download a backup, edit it out, then restore.

Isolated the issue! During testing, I had misconfigured my cable-modem ISP. A hard reset of the cable modem and a switch back to DHCP on pfsense wan-1 interface cured the issue.

Not sure how it was providing 50% connection, as everything was messed up.... :-)

Full capacity restored!!

You could set a sysctl tunable for machdep.hyperthreading_allowed=0 if you didn't want to disable HT in the BIOS.

Ok it´s solved!
As mentioned I canceled all ntp-relevant setups and build up this as new.
Of course: it does´t work: my test-client did not syncronise with the running NTPd on pfsense.
I found a little tuto which described how to configure such a setup. Nothing new at all but it says how one could test if it works. This test was new for me: stop the ntp-service on the client, give ntpdate 192.168.114.1 (which is the CARP-LAN-IP) and start the service again.
The ntpdate says: "no server suitable for synchronization found". A rule for udp/123 from LAN to the FW is active. Than i checked some configs in the Switch between the FW and the VM-Host with the test-client. It was preventing "SYN/SYN-ACK Flooding". Made tests, checked it twice, problem was found.

Thanks for all advices and hints.
Fred

@MarekAndreansky said in pfSense goes silent, then resumes operation, repeatedly:

Is there a way to test cabling via pfSense?

As said : there isn't.

But, as you know, you have a WAN and LAN.
What about swapping cables ☺
If the problems move to a new interface - on WAN for example then you know that your problem is the cable.
If it is the same interface, you know that you should focus on a that interface (NIC) - check both sides.

@johnpoz
Sorry for my rather not so helpful answere.
It is connected via a gigabit inteface normal rj45.
There are not any packages installed.

Yes you can use a shaper with in a double NAT setup. As long as the shaping on the pfSense interface is more restrictive than anything upstream it should work fine.

You should be bale to use PPPoE without it dropping out though. I use that here without issues.

Steve

But you are still able to ping pfSense from the client in that situation. Both the LAN and WAN IP?

And presumably you can connect to the webgui also? Can you ping our from pfSense itself in Diag > Ping?

Is there anything in the system log when this happens? Do you see attempted ping in the firewall log?

Steve

Hmm, I guess good to know at least, but....

@mhertzfeld said in Ransomeware infected machine:

not failover to one of the other ports on the board.

It can failover to another port for IPMI? That doesn't seem like all that smart of an idea from a security point of view ;)

Ouch! Nice catch though.

So your OpenVPN configuration is causing it to wait for a password before it starts. Maybe you have it set to user auth but didn't enter a password.

You might try adding auth-retry nointeract; to the custom options, too

KOM....

Sometimes bitter enemies can eventually become best of friends.......stranger things happen.....just a thought

Peace

i noticed, sorry i can not update my configs yet since the i am facing the issue described in here

So i need to wait until i can modify or downgrade the system to safely remove the transparent-client-ip feature. I was going to use this feature for internal smtp server to forward the original IP.

I would not suggest you open a port to the public internet for your cameras.. Not a good idea! Use a vpn..

But
https://docs.netgate.com/pfsense/en/latest/nat/forwarding-ports-with-pfsense.html

@guardian said in Please tell me what this error message is likely serious?:

Any idea how many "bad attempts" are necessary to trigger the message?

It depends on a few factors, but that's all decided by sshguard and could be found in their docs.

@guardian said in Please tell me what this error message is likely serious?:

How long sshguard has been part of pfSense

Since 2.4.4.

@guardian said in Please tell me what this error message is likely serious?:

Is the "user id" of the attempted login available in a log somewhere?

The main system log.