@bob-dig Thank you so so much :)

Use topology subnet. One can set static tunnel IP in Client Specific Overrides. Common Name of the client cert must match username. Fill in the user static tunnel IP in IPv4 Tunnel Network, f.e.: 172.16.0.2/24 gives username1 a static tunnel IP .2 172.16.0.3/24 gives that username1 a static tunnel IP .3 172.16.0.1 is for the server and cannot be used. .0 .254 .255 cannot be used either.

@scroll_dp said in redirecting local network to openvpn network: OpenVpn network -- 192.168.1.0/24 local network -- 192.168.0.0/24 Best practice would be to not use these networks, since they are default on many routers and hence widely used. But yes, it's possible to workaround the routing issue with an additional IP on the OpenVPN interface, which lies outside of these networks. To set this up, assign an interface to the OpenVPN server instance and activate it, say it's OPT1. Then go to Firewall > Virtual IPs and add an a new IP of type "IP alias" to this interface, e.g. 10.47.23.41/32. Then add a port forwarding rule to OPT1 for the destination IP 10.47.23.41 and target it to the concerned server. So you can use 10.47.23.41 to connect to the server from the OpenVPN. If you don't have "redirect gateway" in the OpenVPN server settings you have to add the virtual IP to the "Local networks", 10.47.23.41/32 in this example. If you have multiple IPs to be redirected you can use a /24 subnet mask for the virtual IP and add a NAT 1:1 rule to redirect the whole subnet.

@hendi You have no Ping because that's ICMP and not TCP.

@jimbo123 I've since found this Redmine that seems to confirm that the option adds "remote-cert-tls server" in the config for the client: https://redmine.pfsense.org/issues/11865 This is the option that has been added to the "Cryptographic Settings" in OpenVPN client configuration options. [image: 1661825614470-screenshot-from-2022-08-30-03-13-20.png]

@litlelee9 Your first ping test seemed to be pinging itself - is that why it seemed to work but actually wasn't? If you are policy routing and the FW rules are still using the old gateway can you just go change it? You should see in the gateway column on the LAN etc interface which rules have a GW defined. Sorry if that's stating the obvious.

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/#!/ [image: 1661484840358-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