@iorx Duh! (Homer Duh! that is...). If everything else fails read the manual. So I did... and love and behold I goofed up. I had changed the common name for the client certificate and this NEEDS to reflect the OpenVPN Client Specific iroute config. Change the common name there to match my certificate and it's working again. Not really sure what I was thinking here If was trying to prevent a common name collision or something. Not very scientifically. If some one makes the same "Duh", I leave this up here for amusement of doing things almost right. Brgs,

@viragomann Thank you very much for your help. I have already solved it that way. Best regards

I assume you mean the bundled client installation package, as changing the default location within the firewall itself sounds silly. The installer is simply a 7zip sfx package - it should be easy enough to make your own.

@viragomann said in ovpn with same network addresses works but: The only other option you have might be to nat the IP address to something else. But this has to be applied on the remote site. You can assign an additional IP outside of the LAN subnet to the remote pfSense VPN interface (there must be an interface assigned to the VPN server) and nat it to 192.168.0.1. Also you have to push the route for the new NAT IP to the client or add it to the client config. Thanks for the answer. I will try it as described.

@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.

In my attempt to debug the network issue i ran netstat -see on the ubuntu server before and after download test. Keep in mind that i don't actually know what they mean or how to fix them but this is the values that popped out: TCPSackRecovery: 1107 TCPLostRetransmit: 927 Fast retransmits 4410 Retransmits in slow start 402 TCPTimeouts: 403 TCPLossProbes: 808 TCPSackRecoveryFail: 402 TCPSackMerged: 332 TCPSackShiftFallback: 1120 The entire network is virtual and there cannot be a problem of congestion so, again, it was a dead end. This morning i made a backup of the configuration and installed pfsense development version daily snapshot 2.7.0 from 06.01.2023 and.....it worked! I still don't know the cause but i think i can run the development version until the stable one comes out.

@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

@viragomann is not the same ip. i can't understand why if i put the internal ip from the server 000.000.00.:9000 the site open but if i put only the fqdn it don't works

@pippin The link was very infomative ... but before I change my LAN & Tunnel IP:s there is one thing confusing me. In my old case I had Tunnel IP:s 192.168.2.1/24 and therfore OpenVPN should get an IP 192.168.2.x. When I connected my laptop to OpenVPN server I got following ... [forsete@rk-dell: ~]> ip address 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp4s0u2u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 3c:e9:f7:b6:68:ae brd ff:ff:ff:ff:ff:ff inet 192.168.158.232/24 brd 192.168.158.255 scope global dynamic noprefixroute wlp0s20f3 valid_lft 3574sec preferred_lft 3574sec inet6 fe80::f6d2:b32f:7645:2fda/64 scope link noprefixroute valid_lft forever preferred_lft forever 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 192.168.2.5/24 brd 192.168.2.255 scope global noprefixroute tun0 valid_lft forever preferred_lft forever inet6 fe80::61e7:5d0:9b6d:2810/64 scope link stable-privacy valid_lft forever preferred_lft forever Making ping gave me following ... [forsete@rk-dell: ~]> ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=43.5 ms ^C --- 192.168.2.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2004ms rtt min/avg/max/mdev = 32.680/36.557/43.492/4.915 ms [forsete@rk-dell: ~]> ping 192.168.2.2 PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data. From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 192.168.2.2) 64 bytes from 192.168.2.2: icmp_seq=10 ttl=63 time=130 ms ^C --- 192.168.2.2 ping statistics --- 10 packets transmitted, 10 received, +10 errors, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 84.506/146.639/258.837/52.247 ms [forsete@rk-dell: ~]> ping 192.168.2.3 PING 192.168.2.3 (192.168.2.3) 56(84) bytes of data. From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 192.168.2.2) ^C --- 192.168.2.3 ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3005ms [forsete@rk-dell: ~]> ping 192.168.2.4 PING 192.168.2.4 (192.168.2.4) 56(84) bytes of data. From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 192.168.2.2) ^C --- 192.168.2.4 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms [forsete@rk-dell: ~]> ping 192.168.2.5 PING 192.168.2.5 (192.168.2.5) 56(84) bytes of data. 64 bytes from 192.168.2.5: icmp_seq=1 ttl=64 time=0.089 ms ^C --- 192.168.2.5 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3109ms rtt min/avg/max/mdev = 0.029/0.066/0.098/0.028 ms [forsete@rk-dell: ~]> ping 192.168.2.6 PING 192.168.2.6 (192.168.2.6) 56(84) bytes of data. ^C --- 192.168.2.6 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2002ms Additional information [forsete@rk-dell: ~]> sudo route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 50 0 0 tun0 0.0.0.0 192.168.158.81 0.0.0.0 UG 600 0 0 wlp0s20f3 98.128.190.194 192.168.158.81 255.255.255.255 UGH 50 0 0 wlp0s20f3 192.168.2.0 0.0.0.0 255.255.255.0 U 50 0 0 tun0 192.168.158.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp0s20f3 192.168.158.81 0.0.0.0 255.255.255.255 UH 50 0 0 wlp0s20f3 So what is my laptop IP in the Tunnel ... 192.168.2.1 or 192.168.2.5? Ping to other 192.168.2.x gave ... Redirect Host(New nexthop: 192.168.2.2)

Thanks @jimp - I found bug 13424 referenced at https://blog.nuvotex.de/pfsense-crl-has-expired/ and the patch fixed it.

@uknewituncle [image: 1672852421143-error-pfsense01.jpg] [image: 1672852426574-error-pfsense02.jpg]

@viragomann thank you once again; I've made it. I deleted all my previous configs and started again. The problem was declaring the VPN tunnel on my pfsense client configuration. Since the server has been set to dynamically provide IP addresses through the VPN tunnel, I think it conflicted somehow. Just for anybody else facing this issue, I've managed it in this way: SERVER SIDE: [image: 1672831161583-schermata-2023-01-04-alle-12.17.36-resized.jpg] (note the dynamic IP address network) then I declare the subnet to which all clients should be given access (I previously named this subnet LAN B) Then, on specific USER PERMISSION (OPENVPN ACCESS SERVER) I set: [image: 1672831332682-schermata-2023-01-04-alle-12.21.28-resized.png] So that the user I'm connecting from will be capable of reaching both my client side LANS (the pfsense's ones) CLIENT SIDE (pfsense) No tunnel ip has been declared (because it is dynamically provided by the server) [image: 1672831462177-schermata-2023-01-04-alle-12.23.45-resized.png] The remote LAN I want to reach has instead been declared (192.168.1.0/24 - SERVER SIDE LAN) NO GATEWAY NOR STATIC ROUTE HAS BEEN MANUALLY SET; THEY GOT CREATED BY OPENVPN CLIENT ITSELF [image: 1672831589134-schermata-2023-01-04-alle-12.26.02-resized.png] Everything's working now: I can ping the external LAN (server side - 192.168.1.0/24) from both my pfsense LANs (192.168.3.0/24 and 192.168.4.0/24). Thank you once again!

@viragomann That was one of the first things I did when I rebuilt the network (static assignment). It wasnt DHCP, I just assigned it from a new block of addresses I'd reserved for a few devices. It just didn't remotely occur to me there would be dependencies on that IP within that client box. That just goes back to my lack of familiarity with the internals of the OpenVPN server box he is using. Hey, at least I learned something.....

I think it's got to be some sort of asymmetric issue. What would I look at to investigate that? I think it's not a pfsense firewall being cleared during testing because a) I'm not clearing it and I'm theonly admin and b) if I try the test a few hours later I get the same results. Just before retrying the test later I confirm the openVPN has no sessions on it. That being said maybe I should try clearing the sessions of both the LAN and WAN? I do have my clients when testing on my LAN just before disconnecting and joining the openVPN over the WAN.