@greentea Did you forward the VPN packets on the ISP router? I suspect, that the packets don't reach pfSense WAN interface. To investigate run a packet capture (Diagnostic > Packet capture) on WAN and set the port filter to 1194, while you try a connection from outside.

@viragomann The routing table showed the problem. The VPN site I don't control started using the same IP subnet that I'm using which is causing conflicting routes. Thanks for the idea.

@viragomann Hi - it works but then stops working :( I think its causing some kind of loop somewhere - behaves strangely Regards

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

@unsichtbarre I do it all the time. Put your "remote" box behind your primary box LAN and build the OpenVPN instance that way. Make sure both boxes have different LAN subnets.

@danielino1981 Could be. Depends on the HW and the level of encryption....

@viragomann Thank you. This is when it comes out that I am a self-taught amateur. It solved the issue - I did not have a NAT rule for the OpenVPN server interface. To answer your second question: That is my mobile phone - the source is there to set it up on one device since other are connected. (I allow access to a bunch of friends via my OpenVPN server (and FreeRadius) accounts to those that host my RPI or live in totalitarian states - they get to watch Netflix and/or read uncensored news). Thanks and I am closing this post.

@mike_7947 Take a look at the following for guidance regarding address selection. https://routersecurity.org/ipaddresses.php Ted Quade

@jknott I just noticed ULA is covered by the RFC 1918 rule, so I deleted my ULA rule.

Hi @viktor_g, thx this one solved issue.

Thanks worked, its just put the same CA Name in Common name client specific override.