1

I am trying to establish an nfs connection through an openvpn tunnel. It really anoying and i dont know what to try next. The connectein test has been made on several platforms now. used debian/centos/openwrt. Changed server<>client

A "direct" nfs connection alway works instant by doing: (DEMO IP HERE)

mount -t nfs 192.168.2.1:/extroot test

but an:

mount -t nfs 10.0.0.1:/extroot test

always fails with: (takes forever to timeout)

mount.nfs: Connection timed out

Also i did that on a remote vps and the connection is established instant. The openvpn tunnel seems fine. Ping ok iperf greather 100mbits soo .....

My configs atached, any help is verry welcome!

NFS:

/etc/exports: ( '*' is just for debugging here )

/extroot *(rw,all_squash,insecure,async,no_subtree_check)

/etc/hosts.allow

portmap: ALL

openvpn:

server.conf:

port 6565
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh2048.pem
server 10.0.0.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
keepalive 5 30
verb 3

client.conf:

client
tls-client
dev tun
proto udp
remote hostname.of.server portnum
resolv-retry infinite
nobind
pkcs12 /etc/openvpn/nfs.p12
verb 3
remote-cert-tls server

tcpdump from nfs server while trying to connect: http://pastebin.com/2PJ2w7vB

i know its hard ti read, sorry.

  • Just a thought, but you might want to do a capture on your server primary interface. Is your NFS server attempting to do reverse DNS lookups for 10.0.0.6 and failing perhaps? Sure all the communication between the client and server should be across the tunnel, but don't assume that is what is happening. I would be tempted to do something like tcpdump -ni any on the server. BTW are you certain you have ruled out any firewalls? Are you certain routing is correct, do you see client sending packets out the non-tunneled interface? – Zoredache Oct 31 '14 at 21:50
  • You are right! This is happening all the time, till it times out. >> pastebin.com/9sTwk3mb << But why the hell is happening that? while route -n shows: >> pastebin.com/QqKX8Eze << Why packets are going confused in a clean routing table ? ;) – derdigge Nov 1 '14 at 6:18
  • Ok, i am getting closer. >> /sbin/mount.nfs -v 10.0.0.1:/extroot test -o addr=10.0.0.1,clientaddr=10.0.0.6 << produces the right tcdump output and mounting works in Debian/ubuntu. but in initramfs state i am getting >_>_> mount.nfs: rpc.statd is not running but is required for remote locking. <_<_< Any ideas on this ? – derdigge Nov 1 '14 at 8:18
1

Ok i got it. @Zoredache pointed me into the right direction. Thank you my friend :) !! Its indeed the case that mount.nfs is trying to point to localhost instead of the vpn ip. You can solve this by using the following mountopts.

/sbin/mount.nfs -v 10.0.0.1:/$remotepath /$localpath -o addr=10.0.0.1,clientaddr=10.0.0.6

Debug Output of mount.nfs

mount.nfs: timeout set for Sat Nov  1 08:49:42 2014
mount.nfs: trying text-based options 'clientaddr=10.0.0.6,vers=4,addr=10.0.0.1'

If You want to solve this inside initramfs, you need to add /sbin/mount.nfs to your initramfs. The generic command mounting nfs during boot for nfsroot will fail otherwise.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.