It isn't an option that is negotiated, it doesn't know or care if the remote side does DCO. It only changes how the system locally handles crypto. If it's enabled, it's used.

@npsgpsv6zt simple policy route, setup your vpn client on pfsense. But don't pull routes from the vpn service, then just policy route whatever device or network you want to use the vpn connection.

https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html

When you fill your pipe on the VPN with a DL then packetloss will occur.

Everything else is getting throttled.

Also a normal DL on the connection that fills the pipe will see packetloss.

Thats why people tend to use bandwidth limiters for the services so this doesnt occur.

@edwardnizz said in Sick of Plex:

with the Nvidia shield, I couldn't find a way to sign in to the server portion.

Oh from like the shield interface to plex - yeah that is prob limited sort of interface. For some more advanced server stuff you prob better access the plex from your fav browser.

And via the plex.tv url because if you access it direct via ip or local name, etc. that web gui interface is normally a few revisions behind what is available when you use https://app.plex.tv/desktop/#!/

webinterface1.jpg

@johnpoz Yup all of that is true.

Additionally the server is on the same hyper-v machine that all the other servers are on. So it's not a real world networking problem at all. All the Vms are on the same 10Gb virtual switch.

The only odd thing about this particular server is that it has a 6TB volume on it.

Also, this was not a problem with another firewall system that also used openvpn.

I switched to pfsense because the ipsec support is somehow better- this was trying to resolve an issue with a customer we need to connect to.

Now I can't get to testing the ipsec link until I resolve this. I've got a $10,000 Checkpoint sitting here which I want to return.

If you have a CRL and used the default expiry (9999 days), it might be this.

This appears in the openvpn server log as something like:

VERIFY ERROR: depth=0, error=CRL has expired

@jimp Yes, that is right.

Thanks

It's strange that it didn't show up before. This VM is over a year old. It was constantly on/off.

@spyder0552

Thanks, I will be going through some debugging and might go for a new netgate appliance 6100 Max with new pfsense+ version, i will update the thread once i have some updates

@yellowphoenix18 no reason to delete - its a valid sort of question that others might have.

Glad you got it sorted.

@jarhead

interesting, in every demo i saw or procedure i read, it was all about /24 for the tunnel but ok lets try /30

here is my server side Tunnel config
2c3a40fd-7d4f-402c-92dc-928ad5252ec1-image.png

This is the client side Tunnel config
4289c6ec-11a7-4f59-9030-f566bf6357b0-image.png

@rico Hi
Yes, seemed like the "key validation" in the form was disturbed by something. Now I can save (changed and unchanged key) but the client still does not connect.

Aug 19 13:36:42 openvpn 43990 Cipher negotiation is disabled since neither P2MP client nor server mode is enabled Aug 19 13:36:42 openvpn 43990 OpenVPN 2.5.4 amd64-portbld-freebsd12.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jan 12 2022 Aug 19 13:36:42 openvpn 43990 library versions: OpenSSL 1.1.1l-freebsd 24 Aug 2021, LZO 2.10 Aug 19 13:36:42 openvpn 44249 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Aug 19 13:36:42 openvpn 44249 Initializing OpenSSL support for engine 'rdrand' Aug 19 13:36:42 openvpn 44249 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400) Aug 19 13:36:42 openvpn 44249 TUN/TAP device ovpnc1 exists previously, keep at program end Aug 19 13:36:42 openvpn 44249 TUN/TAP device /dev/tun1 opened Aug 19 13:36:42 openvpn 44249 /sbin/ifconfig ovpnc1 10.0.8.2 10.0.8.1 mtu 1400 netmask 255.255.255.255 up Aug 19 13:36:42 openvpn 44249 /usr/local/sbin/ovpn-linkup ovpnc1 1400 1472 10.0.8.2 10.0.8.1 init Aug 19 13:36:42 openvpn 44249 TCP/UDP: Preserving recently used remote address: [AF_INET]yy.yy.yy.yy:1194 Aug 19 13:36:42 openvpn 44249 UDPv4 link local (bound): [AF_INET]xx.xx.xx.xx:0 Aug 19 13:36:42 openvpn 44249 UDPv4 link remote: [AF_INET]yy.yy.yy.yy:1194 Aug 19 13:36:59 openvpn 35928 MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock Aug 19 13:36:59 openvpn 35928 MANAGEMENT: CMD 'status 2' Aug 19 13:36:59 openvpn 35928 MANAGEMENT: Client disconnected Aug 19 13:36:59 openvpn 35928 MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock Aug 19 13:36:59 openvpn 35928 MANAGEMENT: CMD 'status 2' Aug 19 13:36:59 openvpn 35928 MANAGEMENT: Client disconnected Aug 19 13:37:05 openvpn 35928 MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock Aug 19 13:37:05 openvpn 35928 MANAGEMENT: CMD 'status 2' Aug 19 13:37:05 openvpn 35928 MANAGEMENT: Client disconnected Aug 19 13:37:14 openvpn 35928 MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock Aug 19 13:37:14 openvpn 35928 MANAGEMENT: CMD 'status 2' Aug 19 13:37:14 openvpn 35928 MANAGEMENT: Client disconnected Aug 19 13:37:25 openvpn 35928 MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock Aug 19 13:37:25 openvpn 35928 MANAGEMENT: CMD 'status 2' Aug 19 13:37:25 openvpn 35928 MANAGEMENT: Client disconnected Aug 19 13:37:25 openvpn 35928 MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock Aug 19 13:37:25 openvpn 35928 MANAGEMENT: CMD 'status 2' Aug 19 13:37:26 openvpn 35928 MANAGEMENT: CMD 'quit' Aug 19 13:37:26 openvpn 35928 MANAGEMENT: Client disconnected

@johnpoz It would be because of a software configuration.

Thank you very much for your attention. Now everything is ok.