NFS share access

JKnott

Will attach output from Wireshark ...

Is there any NFS traffic in that capture? I see lots of other stuff. When doing packet captures, you can use filters to get only the relevant packets. For example, in Wireshark, you'd use the capture filter with "port 2049". This will capture any NFS traffic, whether TCP or UDP, etc..

johnpoz

@jknott no there is no nfs traffic that I saw at all, but don't see how is IPs are going to talk when his listed IPs .3 and .13 - .13 arping for .3 and never gets an answer.. Kind of hard to do any sort of anything when devices atleast think they are on the same network and can not arp for each other ;)

zkab

@johnpoz said in NFS share access:

There is no way you are actually talking to devices via tunnel (normal openvpn) setup if your tunnel network is the same as your lan network..

But I have LAN and Tunnel Network separated ...

johnpoz

@zkab well then your laptop when connected remotely would have a 192.168.2 address.

Now if your vpn client is remote on another 192.168.1 network - then yeah that can be problematic - which is why is normally a good idea to stay away from the common 192.168.0 and 192.168.1/24 networks - those are the most common networks device might be on when at a remote location.

Good idea to use something not on those networks. My lan is 192.168.9/24 for example.. Some people like to use some 172.16-31 network those are not very common at locations like starbucks or wherever you might be using some local wifi network.

You could work around with some fancy natting, etc. But the simple solution is to just not use those common 192.168 networks for your networks.

zkab

@johnpoz OK ... I see the point to avoid 192.168.1-2 networks but changing my LAN and Tunnel to something different will not solve my problem. As you mentioned earlier my vpn client will have a ip from the Tunnel (192.168.2.0/24) and it was 192.168.2.5 which is shown below ..


ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp4s0u2u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether cc:96:e5:ca:3a:cc brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:e9:f7:b6:68:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.158.232/24 brd 192.168.158.255 scope global dynamic noprefixroute wlp0s20f3
       valid_lft 2427sec preferred_lft 2427sec
    inet6 fe80::f6d2:b32f:7645:2fda/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 192.168.2.5/24 brd 192.168.2.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::c6a8:1e1e:d35f:e9b1/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Is the bridge right way to go?

Happy New Year!

johnpoz

@zkab said in NFS share access:

LAN and Tunnel to something different will not solve my problem

huh.. Changing your lan to something other than 192.168.1.x would solve your problem..

Lets say the remote network your vpn client is on is 192.168.1/24 and your tunnel is 192.168.2/24 and your lan is 192.168.3/24

Now you don't have any overlapping networks..

Changing your tunnel will not fix the issue of the remote local network being the same as your local network no.. Which is why changing your local network to be less likely to overlap with remote network would work.

zkab

@johnpoz OK ... I will try to fix it next year (tomorrow)
Thanks for taking your time to help me.

JKnott

@zkab

I had the same problem several years ago. I did a lot of travelling in my job and found the LAN in the hotels occasionally collided with my home LAN, making it impossible to use a VPN. I noticed that subnets in the 172.16.0.0/12 range were rarely used elsewhere, so I moved my LAN to 172.16.0.0/24.

zkab

@jknott OK ... if I change IP:s like following:

TUNNEL
10.0.8.0/24

LAN
172.16.0.0/24

As I understand I will get one IP from my TUNNEL for my laptop when connecting with vpn.
But I had to know which IP I have received for my laptop since my NFS/NAS has to know the IP.
Can I decide that I always will get 10.0.8.1 every time a vpn connection is made?

JKnott

@zkab

Routing is normally done by a router, such as pfSense. The NAS only needs the default route to pfSense and it will know the route back through the VPN. However, the VPN should always have the same address, as you configure that when you set up the VPN.

Here's the config from my VPN:

Note where it says The first usable address in the network will be assigned to the server virtual interface. The remaining usable addresses will be assigned to connecting clients.

johnpoz

@zkab said in NFS share access:

since my NFS/NAS has to know the IP.

And why is that? Wouldn't your client be making the connection to the NAS - the nas is just going to answer. Why would the nas be trying to make the connection to the laptop?

But you can make sure a specific client gets a specific IP in your tunnel network with the client options.

I have my laptop always get this IP via client overrides and simple

ifconfig-push 10.0.8.100 255.255.255.0

Pippin

A diagram might help to understand:
https://community.openvpn.net/openvpn/wiki/AvoidRoutingConflicts

Best wishes!

zkab

@pippin The link was very infomative ... but before I change my LAN & Tunnel IP:s there is one thing confusing me. In my old case I had Tunnel IP:s 192.168.2.1/24 and therfore OpenVPN should get an IP 192.168.2.x. When I connected my laptop to OpenVPN server I got following ...

[forsete@rk-dell: ~]> ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp4s0u2u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:e9:f7:b6:68:ae brd ff:ff:ff:ff:ff:ff
    inet 192.168.158.232/24 brd 192.168.158.255 scope global dynamic noprefixroute wlp0s20f3
       valid_lft 3574sec preferred_lft 3574sec
    inet6 fe80::f6d2:b32f:7645:2fda/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 192.168.2.5/24 brd 192.168.2.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::61e7:5d0:9b6d:2810/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

Making ping gave me following ...

[forsete@rk-dell: ~]> ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=43.5 ms
^C
--- 192.168.2.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 32.680/36.557/43.492/4.915 ms

[forsete@rk-dell: ~]> ping 192.168.2.2
PING 192.168.2.2 (192.168.2.2) 56(84) bytes of data.
From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 192.168.2.2)
64 bytes from 192.168.2.2: icmp_seq=10 ttl=63 time=130 ms
^C
--- 192.168.2.2 ping statistics ---
10 packets transmitted, 10 received, +10 errors, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 84.506/146.639/258.837/52.247 ms

[forsete@rk-dell: ~]> ping 192.168.2.3
PING 192.168.2.3 (192.168.2.3) 56(84) bytes of data.
From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 192.168.2.2)
^C
--- 192.168.2.3 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3005ms

[forsete@rk-dell: ~]> ping 192.168.2.4
PING 192.168.2.4 (192.168.2.4) 56(84) bytes of data.
From 192.168.2.1 icmp_seq=1 Redirect Host(New nexthop: 192.168.2.2)
^C
--- 192.168.2.4 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1002ms

[forsete@rk-dell: ~]> ping 192.168.2.5
PING 192.168.2.5 (192.168.2.5) 56(84) bytes of data.
64 bytes from 192.168.2.5: icmp_seq=1 ttl=64 time=0.089 ms
^C
--- 192.168.2.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3109ms
rtt min/avg/max/mdev = 0.029/0.066/0.098/0.028 ms

[forsete@rk-dell: ~]> ping 192.168.2.6
PING 192.168.2.6 (192.168.2.6) 56(84) bytes of data.
^C
--- 192.168.2.6 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2002ms

Additional information

[forsete@rk-dell: ~]> sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    50     0        0 tun0
0.0.0.0         192.168.158.81  0.0.0.0         UG    600    0        0 wlp0s20f3
98.128.190.194  192.168.158.81  255.255.255.255 UGH   50     0        0 wlp0s20f3
192.168.2.0     0.0.0.0         255.255.255.0   U     50     0        0 tun0
192.168.158.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp0s20f3
192.168.158.81  0.0.0.0         255.255.255.255 UH    50     0        0 wlp0s20f3

So what is my laptop IP in the Tunnel ... 192.168.2.1 or 192.168.2.5?
Ping to other 192.168.2.x gave ... Redirect Host(New nexthop: 192.168.2.2)