Samba is inaccessible from VPN

Hi to all I have faced with issue that Samba share is not accessible through OpenVPN.
Please share your thoughts.

1 Like

I vaguely remember an issue about a system with multiple green interfaces.
What’s in /etc/samba/smb.conf?

I have:

interfaces = 127.0.0.1 192.168.x.0/24 (green network)
hosts allow = 127.0.0.1 10.9.9.0/255.255.255.0 192.168.x.0/255.255.255.0

(10.9.9.0 is the vpn network)

# Only bind to allowed NIC's
bind interfaces only = yes
interfaces = 127.0.0.1 10.1.1.0/24 10.1.114.0/24 
hosts allow = 127.0.0.1 10.1.1.0/255.255.255.0 10.1.114.0/255.255.255.0 10.10.1.0/255.255.255.0 192.168.78.0/255.255.255.0

[root@nethserver log]# netstat -plane | grep smbd
tcp        0      0 127.0.0.1:445               0.0.0.0:*                   LISTEN      0          219350     1753/smbd
tcp        0      0 10.1.1.11:445               0.0.0.0:*                   LISTEN      0          219348     1753/smbd
tcp        0      0 10.1.114.11:445             0.0.0.0:*                   LISTEN      0          219344     1753/smbd
tcp        0      0 127.0.0.1:139               0.0.0.0:*                   LISTEN      0          219351     1753/smbd
tcp        0      0 10.1.1.11:139               0.0.0.0:*                   LISTEN      0          219349     1753/smbd
tcp        0      0 10.1.114.11:139             0.0.0.0:*                   LISTEN      0          219347     1753/smbd
unix  3      [ ]         STREAM     CONNECTED     219331 1753/smbd

VPN network is 10.10.1.0/24 :

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.10.1.1  P-t-P:10.10.1.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:1832 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1861 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:121855 (118.9 KiB)  TX bytes:578347 (564.7 KiB)

Try to add 10.10.1.0/24 to the interfaces parameter and re-try

Already tried, samba could not bind on this interface

I suppose it is a bug in Samba that it could not bind on tun interface

I have to report the same issue. Also tried to add the tunnel network to the interfaces and restart Samba but it didn’t help.

Any news on this from the Dev Team?

As far as I know, nobody else has this bug (still, I currently don’t have a valid environment to reproduce it).
@nrauso, did someone report the same bad behavior?

It was ME :slight_smile:

@giacomo as for Samba it is a known issue with Tun interface, that samba can not bind to it, but on TAP it should bind. maybe some port forward or port tunnel from VPN can be a workaround. It should be tested.

Hi @stephdl maybe You have some thoughts regarding this ?

Workaround could be IP forwarding, :

iptables -t nat -A POSTROUTING -s <your.vpn.network.0>/24 -o <ethX> -j MASQUERADE
service iptables save

in /etc/sysctl.conf add:

net.ipv4.ip_forward = 1 

apply sysctl:

sysctl -p

(in the case of @Nas <your.vpn.network.0> = 10.10.1.0)

samba share shoud be found at

\\<static ip server>\<share>

As we use Shorewall, it can be done through masq file :slight_smile: But it could cause another issues with other services :slight_smile:

Still have to read in to Shorewall… (and Nethserver/Centos as a mather of fact);

Hw about this ?

Sorry @Nas not enough time to play at the minute, I’m changing my main server (aubrac-medical.fr) and reconfiguring my build machine for el7.

1 Like

@stephdl it is not a matter of minutes, but we should make some research regarding this.

Out of topic, but aubrac-medical.fr is like a a good friend that I’m leaving after an adventure of six years about free software ( smeserver, stephdl, nethserver, archlinux repositories) and a lot of (old) scripts everywhere. Today I’m a bit sad :smile:

But the new server is a monster (comparatively from the old) -> https://www.soyoustart.com/fr/offres/e3-sat-3.xml

3 Likes

Yep, Xeon + DDR3 = Rocket

Could you show how this can be done through shorewall? I am just familiar with iptables and I would like to check this workaround.