On Fri, 11 Feb 2022 22:20:38 +0100, Gert Doering <g...@greenie.muc.de> wrote:
>Hi, > >On Fri, Feb 11, 2022 at 09:52:21PM +0100, Bo Berglund wrote: >> But still it seems like it is OpenVPN that breaks the functionality... > >Unlikely theory. This is something about "packets coming from a >different source net" or possibly "from a different interface" than >before. Not "OpenVPN breaking this" - that would look different >(like, data transfers getting stuck due to MTU issues). > ISSUE RESOLVED! --------------- I added a new client spec in /etc/exports file so it now looks like this (on one line): /home/bosse/www/MSNBC -rw,sync,no_subtree_check,insecure 192.168.116.0/22 10.8.139.0/24 The last one is the IP of the tunnel device used by the OpenVPN server. This change made all the difference! Now the nfs server can be connected to by the remote devices just fine! So bottom line is that the nfs call source gets changed by OpenVPN to an address in the tunnel, in this case it is set via a ccd directive to a fixed address in that range. And it looks like this is what nfs sees as the source address and thus it rejected it because it was not in the allowed range. But now it is and it works! Since the connections targeting other nfs servers on the home LAN worked fine without this change I assume that when these are received by OpenVPN they are sent out on the 119 network after being NATed into the 119 LAN range and thus do not suffer the rejection. But when the target is the OpenVPN server itself it does not do the NAT translation and the call does not get out on the 119 LAN but uses the tunnel address directly instead and failed because of that. Now working as intended! :) Thanks for the discussion, which led me in the right direction! -- Bo Berglund Developer in Sweden _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
