Hmm, strange indeed!

Do you have an OpenVPN server running on the firewall? Does it show the clients connecting to it? What are they supposed to be connecting to?

What do you see logged when the webgui cert changes?

Steve

@BFost said in Looking for ideas on troubleshooting an OpenVPN file transfer speed problem.:

is getting 60-70ms latency which seems totally fine to me

You understand with that latency, your 8mbps is right in the ball part for a window size of 64k.. So you really need to look what is going on.

math.jpg

I take it they are downloading, and not uploading - because upload they have a max of 10 per their isp anyway..

Are they on wifi.. We have lots of users report bad vpn performance - they were just on a shit wifi connection. If they plugged in a wire, no issue with their performance.

@Sperber said in Dual OpenVPN-Setting, CARP & Failover (HA, MultiWAN):

(Vorkbaard hat das bereits beschrieben: https://vorkbaard.nl/openvpn-in-a-pfsense-carp-cluster/ )

Die Info ist aber relativ alt und nicht zutreffen. Wir haben da sehr verschiedene und komplexe Services laufen und keiner braucht irgendwelche seltsamen Settings mit "local <extIP>" o.ä. - das sollte heute überhaupt nicht mehr nötig sein. Macht im CARP Setup auch keinen Sinn, da die CARP VIPs alle auf dem Master laufen und man diese so nicht ansprechen kann. Split CARP mit Master/Backup auf dem selben Node ist in der FreeBSD Variante von CARP/pf nicht enthalten, das ist leider nur in OpenBSD enthalten.

Mich interessiert allerdings auch wie @viragomann wie man überhaupt auf der 2. pfSense im CARP die Annahme von OpenVPN erlauben will. Der Traffic kommt ja nicht bei ihr an, weil der via CARP IMMER zur primären läuft, nicht auf den sekundären Node. Und wenn man das forwarden sollte auf Node 2, würde der Node versuchen asymmetrisch zu antworten (oder es läuft alles wieder über Node1), was auch wieder nicht sehr schön ist.

Wie ist das also realisiert, dass die Clients sich auf Node2 connecten und das auch funktioniert, wenn Node2 mal aktiv wird und Node1 passiv weil vlt. gerade gewartet wird o.ä.?

Ansonsten wäre mir schleierhaft wie das im Redundanzfall wirklich sauber funktionieren sollte ohne dass manuell eingegriffen wird?

Cheers
\jens

Start your own thread, it's unlikely to be the same issues others have hit. While symptoms may be similar, there are numerous possible causes that can look the same, and trying to diagnose multiple people's issues in a single thread is not feasible.

@steveits

/facepalm - Again, I am new to this and I see what I needed to do! I installed the patches package and applied all, did the reboot, and bingo! Back in business! Thank you so much!

Solved!
Followed a lot of rabbit holes down until I found these:
https://serverfault.com/questions/1064935/openvpn-server-connexion-ok-but-no-access-to-remote-lan

which lead to:
https://openvpn.net/community-resources/how-to/#expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet

Main take away was that I needed to add

push "route [Local LAN subnet] 255.255.255.0"

to the advanced configuration on the server setup.
Still reading a bit more to understand how this worked, but I'm able to ping my local machine as well as remote into it.

Happy days.

@kamil-0 opcjach serwera OpenVPN odchacz opcję "Inter-client communication". Komunikacja między klientami nie powinna działać. Ale jak wrócę do domu to sprawdzę.

@viragomann it's ok problem solved i can ping Local machine on LAN network after configuring check box redirect gratway

@wingrait said in Network Drive Slow Performance?:

10Mbps = 1.25MB/s with no other overhead.

hahaha - well problem solved ;) Glad you got it figured out.. Bytes vs bits is hard sometimes hahahah <ROFL>

edit: btw thanks for pointing out the actual issue, vs just walking away leaving the thread hanging to keep egg off your face..

The B vs b thing bites everyone in the butt at some point, reminds me of still the constant question about wireless, but the router says it can do 1900mbps on the box - why am I only see 200 ;) hehehe

@moadmin
Hey guys, can i get any suggestion on this, its still happening even with split tunnel config.
When VPN is on and connected, google meet calls are choppy and distorted, when we turn it off the video is smooth and in good quality.
This happened after we updated our pfsense to 2.6.

Yes, it could be. I'll try to replicate and open something if there isn't anything already open.

@coyotekg The client certs use the CA as the issuer just like the server certs do so yes, you would need to change them.

@marcelobeckmann O problema foi resolvido quando liberei as portas 1194 na LAN e no OPENVPN, nas regras do firewall dos dois PFsenses. Após isso, as VPN começaram a fechar a conexão e consigo pingar entre os servidores. Muito obrigado pela ajuda.

@jeffreyn said in No Clients Can Connect To OpenVPN Due to CRL Expiry:

@jimp I applied the patch when it was released. I'm reading the release notes for 23.01 and see Issue #13424 has been addressed in the new version. Do I need to do anything like remove the patch before or after I upgrade? Or does everything take care of itself?

You do not need to do anything with the patch after upgrading. You can delete the entry from the system patches package.

@joshopkins
Seems all the settings you did are correct, apart from the push-route commands in the default options. These do the same as the "local networks" setting does, which is the preferred way. You shouldn't have both settings.

Ensure that the access is allowed by rules on all incoming interfaces. Means on the OpenVPN interface at B and on the IPSec of A and C.

To see what's going on, sniff the traffic on the involved interfaces, while you try to access a remote IP from an OpenVPN client.

I agree, pfSense could be much easier. But it is not a consumer product, it is for the enterprise and those are the ones who are willing to pay the money its cost.

Thank you @bingo600 for your help, advice and clear information. I will implement it like you advice and give you a feedback :-)

Thank you

@bobby121418

As long as the ends have different addresses, within the same subnet, it should work. PfSense does that for you automagically. It assigns the first usable address to itself and subsequent addresses to the client(s). All you have to do is pick the subnet.

So the P2 will effectively end up being (in my example) 10.200.10.0/24 to 10.100.10.0/24.
Each side 'hides' it;s local 10.10.10.0/24 subnet behind another, same sized, subnet. You could use any unused subnet for that I just chose 10.100.10.0 and 10.200.10.0.

So on each side that would be the Binat address.

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/phase-2-nat.html

However if you do not need access between the two subnets dircetly but only from the pfSense_1 OpenVPN subnet this becomes easier. You only need to BiNAT on the pfSense_2 side like:

Screenshot from 2022-05-12 14-02-05.png

On the pfSense_1 side the P2 would be just be 172.10.10.0/24 to 10.100.10.0/24

To access the remote side VPN clients would need to use the equivalent NAT address.

Steve

@mrDick гляньте тут - https://forum.netgate.com/topic/131401/%D0%BC%D0%B0%D1%80%D1%88%D1%80%D1%83%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-openvpn/75 настроено не по феншую, а переделать не получается. Но сколько лет работает на 3 офиса.

UPD по новым требованиям отключите сжатие и поставьте алгоритм на 512

UPD2 тьфу, забыл. Может уже и не актуально, но в Keenetic в ПЕРВУЮ ОЧЕРЕДЬ отрубите свой OpenVPN от других интерфейсов через CLI (там мануал есть в их хелпе), иначе эта пакость будет туннель пихать и в WI-Fi, даже если там гостевая сеть настроена!!!

Still following the thread I mentioned above, I saw that the eval previously was right before RESULT=.
I have tried to comment the if statement block and move eval, so this way

# eval serial="\$tls_serial_${check_depth}" # if [ -n "$serial" ]; then eval serial="\$tls_serial_${check_depth}" RESULT=$(/usr/local/bin/php-cgi -q /etc/inc/openvpn.tls-verify.php "servercn=$2&depth=$3&certdepth=$4&certsubject=$5&serial=$serial&co nfig=$config") if [ "${RESULT}" = "FAILED" ]; then exit 1 fi # fi

and I don't get anymore the error on the certificate!
I don't know if I need to open an issue about this.

However, now I get the error about the user authentication

SENT CONTROL [spike]: 'AUTH_FAILED' (status=1)

like I was getting when I set "Certificate Depth = Do Not Check".
I looks like I'm not the only one having this issue.

@johnsheridan Thanks for the info and testing. That makes sense. I’ll have a look at those files and patch.

This will be probably fixed in one of the next releases then.

@stephenw10 I didn't realize that I was able to create an interface for VPN. I did that (and it booted the remote users, lol), and was able to configure the FTP Proxy Client plugin to work with it. Thank you for your help!

@benjaminpc said in PfSense AWS OpenVPN kein Internet:

Wenn ich mich aber nun via OpenVPN verbinde kann ich zwar die PfSense pingen aber nicht die Server im LAN Netz
Ebenso haben die Server kein Internet

Beide Symptome könnten hier dieselbe Ursache haben, aber auch verschiedene.
Ich würde die Internet Verbindung der VMs als erstes in Angriff nehmen. Scheint mir leichter zu klären zu sein.

Nachdem die pfSense aus dem Internet erreichbar ist und ihrerseits die Server erreichen kann, besteht mal "physisch" eine durchgehende Verbindung.
Ich nehme an, vom LAN ist nach wie vor alles erlaubt, also die standardmäßige any-to-any Regel aktiv.

Dann versuche mal von einer VM einen Ping auf 8.8.8.8. Wenn das funktionieren sollte, liegt es vermutlich daran, dass die VMs keine Hostnamen auflösen können.

Falls der Ping auch scheitert, könnte das Outbound NAT nicht funktionieren. Dann würde ich die Frage stellen, wie dein WAN konfiguriert ist. Wenn manuell, hast du in den Interface Einstellungen auch das Gateway angegeben?

@mdomnis I have since upgraded to 22.01 with FRR version 1.1.1_6. In my preliminary testing, the routes seems to be working closer to what is expected. I still have a weird issue where sometimes the neighbors don't like to peer fully and I have to force restart FRR, but from some quick tests, it looks like at least the route is being added to the table correctly. For now at least.