@opoplawski

Hi
You were right, I was wrong, dtrace does not work with all functions. Therefore, as a result, we see a probe error

P.S.
I think I've found a solution for the userland programs

we find the pid of the php-fpm process
ps -awx | grep php
342 - Ss 8:55.06 php-fpm: master process (/usr/local/lib/php-fpm.conf) (php-fpm)
23960 - I 3:31.30 php-fpm: pool nginx (php-fpm)
27761 - I 2:07.14 php-fpm: pool nginx (php-fpm)
31652 - I 3:16.94 php-fpm: pool nginx (php-fpm)
37038 - I 3:12.25 php-fpm: pool nginx (php-fpm)
46849 - I 0:55.34 php-fpm: pool nginx (php-fpm)
55575 - I 3:18.29 php-fpm: pool nginx (php-fpm)
94877 - I 2:03.82 php-fpm: pool nginx (php-fpm)

2 using dtrace
dtrace -qn 'pid342:radius.so::entry { @[probefunc] = count();}'

dtrace -l | grep pid

70870 pid342 radius.so zif_radius_put_vendor_addr entry
70871 pid342 radius.so rad_close entry
70872 pid342 radius.so rad_create_request entry
70873 pid342 radius.so rad_put_vendor_int entry
70874 pid342 radius.so rad_demangle entry
70875 pid342 radius.so zif_radius_get_vendor_attr entry
70876 pid342 radius.so rad_strerror entry
70877 pid342 radius.so zif_radius_send_request entry
70878 pid342 radius.so zif_radius_get_tagged_attr_tag entry
70879 pid342 radius.so zif_radius_demangle entry
70880 pid342 radius.so zif_radius_request_authenticator entry
70881 pid342 radius.so zif_radius_put_int entry
70882 pid342 radius.so rad_salt_value entry
70883 pid342 radius.so zif_radius_salt_encrypt_attr entry
70884 pid342 radius.so zif_radius_strerror entry
70885 pid342 radius.so zif_radius_config entry
70886 pid342 radius.so zif_radius_cvt_int entry
70887 pid342 radius.so rad_acct_open entry
70888 pid342 radius.so zif_radius_cvt_string entry
70889 pid342 radius.so zif_radius_server_secret entry
70890 pid342 radius.so zif_radius_get_tagged_attr_data entry
70891 pid342 radius.so rad_put_vendor_attr entry
70892 pid342 radius.so rad_send_request entry
70893 pid342 radius.so rad_put_vendor_addr entry
70894 pid342 radius.so zif_radius_add_server entry
70895 pid342 radius.so zif_radius_close entry
70896 pid342 radius.so rad_get_vendor_attr entry
70897 pid342 radius.so rad_init_send_request entry
70898 pid342 radius.so zif_radius_auth_open entry
70899 pid342 radius.so _radius_close entry
70900 pid342 radius.so rad_continue_send_request entry
70901 pid342 radius.so get_module entry
70902 pid342 radius.so rad_put_int entry
70903 pid342 radius.so rad_put_attr entry
70904 pid342 radius.so rad_auth_open entry
70905 pid342 radius.so rad_get_attr entry
70906 pid342 radius.so rad_cvt_int entry
70907 pid342 radius.so zif_radius_acct_open entry
70908 pid342 radius.so rad_cvt_addr entry
70909 pid342 radius.so rad_put_addr entry
70910 pid342 radius.so rad_server_secret entry
70911 pid342 radius.so zif_radius_put_attr entry
70912 pid342 radius.so zif_radius_get_attr entry
70913 pid342 radius.so zif_radius_cvt_addr entry
70914 pid342 radius.so zif_radius_put_addr entry
70915 pid342 radius.so zm_startup_radius entry
70916 pid342 radius.so rad_config entry
70917 pid342 radius.so zm_info_radius entry
70918 pid342 radius.so zif_radius_demangle_mppe_key entry
70919 pid342 radius.so zif_radius_create_request entry
70920 pid342 radius.so rad_open entry
70921 pid342 radius.so zif_radius_put_vendor_int entry
70922 pid342 radius.so zif_radius_put_string entry
70923 pid342 radius.so rad_cvt_string entry
70924 pid342 radius.so rad_demangle_mppe_key entry
70925 pid342 radius.so rad_put_string entry
70926 pid342 radius.so rad_request_authenticator entry
70927 pid342 radius.so zif_radius_put_vendor_string entry
70928 pid342 radius.so zif_radius_put_vendor_attr entry
70929 pid342 radius.so zm_shutdown_radius entry
70930 pid342 radius.so rad_put_vendor_string entry
70931 pid342 radius.so rad_add_server entry

for example ,

dtrace -n 'pid342:radius.so:rad_send_request:return {printf("=>%d",arg1)}'
dtrace: description 'pid342:radius.so:rad_send_request:return ' matched 1 probe

@Draco

By any chance you upgraded the pfsense (and or openvpn package) recently ?

I got 'similar issue' that left me baffled till this day see here , maybe it is similar with what you experiencing.

Problem 2 fixed by adding route to 192.168.5.0/24 on Mikrotik side

@kstlan02
First off, it's not wise to use public IP ranges in the local network, even for docker.

Then I'm wondering, why don't you run the OpenVPN server on pfSense.

Do I have to do the port forwarding from the WAN to the LAN or do I have to do it from the WAN to the Docker container that is running OpenVPN?

"LAN address" is the wrong destination here for sure. This is an IP assigned to pfSense itself. Hence forwarding to it, is not that, what you want.

The question is then, how can pfSense reach the container?
I'd expect, that the container gets its traffic forwarded inside the VM. But don't know, how you did configure it.

So you have to forward the OpenVPN traffic either to the VM address or to the container IP. In the latter case, you would need to add a static route for it on pfSense of course.

Hey, In here I've decribed my work on this topic :)
https://forum.netgate.com/topic/189447/openvpn-ssl-tls-user-auth-over-ldap/3

@jimp I tried but unfortunately it didn't work, because the User Certificate that I use for export the OpenVPN Client have the same CA that the server certificate (I think).
The final solution was to reinstall all OpenVPN clients on all devices, hard work but at least all users continue to work!
Thanks for the support 👍

@kprovost The speed difference is substantial with only having one enabled so much so I would say this would need a Redmine to only allow one to be selected at a time. Anyone else agree?

@JonathanLee

Thanks this fixed worked for me. My iPhone would not connect without it.

@Pablomdli said in OpenVPN site to site not working both ways:

The only weird things is that it gives the ip 10.0.8.0 to de office#2 openvpn client

So I'd suspect, that you stated this IP in the CSO.
You should enter an IP out of the tunnel network there, but it have to be one from the second upwards.

@cezar_a your welcome

Trying to find a solution to this as well. It doesn't seem OpenVPN has an option to forward headers which basically makes it impossible to use openvpn as the primary on port 443 if you need to see client IP addresses on haproxy..

As an alternative, I wondered if it might make sense to set haproxy listening on 443 and OpenVPN as a backend on a different port. Has anyone tried this yet? Does this cause double encryption (slow down the connection too much)? Here is an example of one guy who claims to have got it working:
https://discourse.haproxy.org/t/haproxy-with-openvpn-over-tcp-443-on-pfsense/4731/2

EDIT

It looks like he create a TCP frontend on 443 with a default backend going to OpenVPN:TCP:1194 and an acl that checks for SSL and sends SSL traffic to an HTTPS Backend set to localhost:9443. Then he configured localhost:9443 as a Frontend that handles the forwarded Web Traffic.

That looks like it should work, but It's a bit too complicated for me to test on my live server right now and I don't have a lab setup. Happy to help anyone else who might have a lab environment setup for testing.

I could certainly image that the faster you push traffic the more is lost, though not necessarily as a percentage.

Do you see the same when connected to other servers? Is that server in London far from you, is the latency high?

Steve

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.