Deploying Zentyal as SMB server that is strictly VPN, no LAN, with Filesharing

[dezmd]

I'm trying to enable filesharing on a bare metal installation with only one NIC that is configured as WAN, but this may not be possible, especially without a lot of custom configuration that may break web admin functionality.  I'm considering just going with full virtualization of the system, so Samba will definitely work if it sees two physical interfaces configured.  Up front, I'd welcome a sense of if I should just virtualize the whole damn thing and fake a real LAN interface that way or if its worth pursing in the current form installed on the bare metal with one physical interface (WAN) for maximum performance.  I'm early enough in this line of exploration to make drastic changes.

The usage case is an OpenVPN based mobile office server with Filesharing/UserMgmt/LDAP/VOIP, where the server itself sits on a single WAN connection (public IP, no second physical interface, only a virtual interface on top of the eth0 WAN with firewall rules allowing all OpenVPN traffic netowrk).  All clients/workstations are 'mobile' and only offer connectivity to the server over OpenVPN.  Samba over OpenVPN for simplicity for the end users (Mac and Windows based clients).  My original hope was that I wouldn't need a physical LAN interface, just a virtual one with a 192.168.x.x ip for OpenVPN clients using 192.168.y.x to talk to the server on a 'LAN' filter set on the firewall.

Is this scenario basically fubar from the start? Does Samba have an absolute requirement for a 'physical' LAN interface as seen by the OS instead of using a virtual interface attached to the WAN interface?  Should this be possible with some minor modifications or is it likely more of a no-go for out of the box Zentyal3/Samba4 as it stands?  Also is that a legitimate way of routing traffic on the firewall with my virtual IP address on eth0 to OpenVPN ip or is that possibly exposing the 192.x address to the ISP despite firewall rules?

I'm at probably 90% complete on a test config for this usage case, this could be an interesting way to serve up Zentyal in a service provider capacity, but of course I've run into the Samba hiccup.

Error message when attempting to start Filesharing:
Failed to enable: Samba can't be provisioned if no IP addresses are set and the DNS domain is properly configured. Ensure that you have at least a IP address assigned to an internal interface, and this IP has to be assigned to the domain and to the hostname in the DNS domain.

I've tried several suggestions from this forum including approaching it as a DNS problem and reinstalling DNS, removing DNS domain and recreating, manually entering the virtual interface's IP address in the DNS IPs and A record host for the machine.  I've yet to attempt to just ram a configuration in by modifying the samba conf files directly hoping to find a solution with minimal impact to web based administration for the sake of third party administration after a deployment.

Zentyal 3.0 32-bit Community Edition (installed from ISO)
Applicable Module Versions:
ii  zentyal-common             3.0.6                                    Zentyal - Common Library
ii  zentyal-communication    3.0.1                                    Zentyal - Communications Suite
ii  zentyal-core                  3.0.11                                  Zentyal - Core
ii  zentyal-dns                   3.0.4                                    Zentyal - DNS Service
ii  zentyal-firewall               3.0.1                                   Zentyal - Firewall
ii  zentyal-gateway             3.0.1                                   Zentyal - Gateway Suite
ii  zentyal-l7-protocols         3.0                                     Zentyal - Layer-7 Filter
ii  zentyal-network              3.0.1                                   Zentyal - Network Configuration
ii  zentyal-ntp                    3.0                                     Zentyal - NTP Service
ii  zentyal-objects               3.0                                     Zentyal - Network Objects
ii  zentyal-office                 3.0.1                                   Zentyal - Office Suite
ii  zentyal-openvpn             3.0.2                                   Zentyal - VPN Service
ii  zentyal-samba               3.0.12                                  Zentyal - File Sharing and Domain Services
ii  zentyal-services             3.0.1                                   Zentyal - Network Services
ii  zentyal-software            3.0.3                                   Zentyal - Software Management
ii  zentyal-usercorner          3.0.3                                   Zentyal - User Corner
ii  zentyal-users                 3.0.7                                   Zentyal - Users and Groups
ii  zentyal-webserver          3.0.2                                   Zentyal - Web Server
ii  zentyal-zarafa                3.0.2                                   Zentyal - Groupware (Zarafa)

Cheers.

[half_life]

For the cost of a $15 nic you are fighting with it?  Why not just install the card and not bother hooking it up to a switch?  That would achieve (I assume) your goal of having an airgap while making the config scripts happy.  Just my two cents please don't take this as a slight.  I know how it is when a person gets determined to make it work

[christian]

Either you or me have wrong understanding of what "virtual IP" provides.

To me, your physical interface (your single NIC) is either connected to internal or to external network but you can't achieve both with one single NIC (yes, I do know you could do something with VLAN but let's try to make it simple  )
The fact that one can add additional IPs (virtual IP) to this NIC doesn't mean that you create an interface that can be seen as internal (LAN).

What can perhaps be achieved is to run VM on to of your hardware and declare multiple NIC at VM level relying on same external (physical) NIC, and set one internal and the other external.

The other option, as suggested by half_life, would be to install additional NIC so that you can configure Samba and access it through VPN. To me this is easier than VM. Furthermore, it will provide you with capability to access Zentyal GUI for administration in a safer way in case your VPN fails. (BTW, how do you achieve this right now ?

[dezmd]

For the cost of a $15 nic you are fighting with it?  Why not just install the card and not bother hooking it up to a switch?  That would achieve (I assume) your goal of having an airgap while making the config scripts happy.  Just my two cents please don't take this as a slight.  I know how it is when a person gets determined to make it work

Deploy anywhere scenarios with the minimum hardware requirements, ie Raspberry Pi and other minimal footprint devices.  I was thinking ahead.

That's also why I'm open to deploying is as a VM if I absolutely must, but that affects such a deploy anywhere scenario.

[christian]

I still don't understand 100% what you intend to achieve but Zentyal is definitely not what I would deploy "anywhere".
This is not light (in term of resource footprint) and has some constraints (like Samba requiring LAN).

This said and understood, Zentyal is a nice solution.... where it fits 

[dezmd]

Either you or me have wrong understanding of what "virtual IP" provides.

To me, your physical interface (your single NIC) is either connected to internal or to external network but you can't achieve both with one single NIC (yes, I do know you could do something with VLAN but let's try to make it simple  )
The fact that one can add additional IPs (virtual IP) to this NIC doesn't mean that you create an interface that can be seen as internal (LAN).

What can perhaps be achieved is to run VM on to of your hardware and declare multiple NIC at VM level relying on same external (physical) NIC, and set one internal and the other external.

The other option, as suggested by half_life, would be to install additional NIC so that you can configure Samba and access it through VPN. To me this is easier than VM. Furthermore, it will provide you with capability to access Zentyal GUI for administration in a safer way in case your VPN fails. (BTW, how do you achieve this right now ?

VLAN on the WAN connected eth0 is exactly how I'm trying to achieve this right now, I'm just trying to describe it in a way I want it to be used to facilitate Samba config.  I suppose I'm making it way more of a pain in the ass with this scenario, I just got dug in and was trying to hammer a way through it with one physical interface.

Right now, I have VPN configured as 192.168.16.x and I have virtual IP on eth0 as 192.168.25.x, in firewall I have default rule of all traffic enabled on Internal networks to Zentyal and it just 'works' with my unorthodox config out of the box.  Ultimately I will specify blocking traffic from the public network, but right now the WAN is part of a /28 that is behind a pfsense box on a public /30 ip, so there is a firewall in place on the network edge.

[dezmd]

I still don't understand 100% what you intend to achieve but Zentyal is definitely not what I would deploy "anywhere".
This is not light (in term of resource footprint) and has some constraints (like Samba requiring LAN).

This said and understood, Zentyal is a nice solution.... where it fits 

Thanks for the perspective.

Don't sell it short, Zentyal is definitely a strong candidate for an 'anywhere' scenario from an IT consulting point of view (where a $250-500 deployable appliance with PoE is insanely more simple and affordable than a hosted or even on-premise $3-5k Windows SBS server for 2-20 users) , and its resource footprint is not a concern unless VOIP is in use.  I've been a lurking fan since the earliest eBox releases and have a decent idea of the hardware needs, I'm just looking for a workaround in this instance.

[Sam Graf]

The thought of Zentyal running on a Pi is a very cool idea. I enjoy stuff like that from a tinkering point of view. And yet ... I don't immediately connect the idea of a Zentyal appliance (which makes perfect sense to me) with Pi-class hardware. Most of us who've used Zentyal on traditional server hardware in typical SMB scenarios do have some idea of the footprint, and the dynamic nature of that footprint in routine office operations (thinking especially of RAM and caching activity).

That's not to say that I think you have a bad idea, thinking ahead. Who knows what a handful of hardware can do in a handful of years. But today, it's a little hard to think in those terms in a typical office situation. It's not a matter of selling Zentyal short or a lack of optimism about the future so much as a matter of being realistic about keeping the boss happy today. File sharing over VPN already isn't a lot of fun, for instance; just ask the boss.

[christian]

File sharing over VPN already isn't a lot of fun, for instance; just ask the boss.

Especially also because CIFS protocol has been designed for LAN "only".  Without specific device fooling this protocol with local "ack", achieving good performance over WAN is a pure dream 

Regarding footprint, I did try long time ago eBox on FitPC and finally went for my own Debian deployment because even eBox footprint was to big for this hardware or at least I was not able to tune it.

[half_life]

If you are working on a PI,  try using one of the wifi usb dongles and set it up as a fixed IP.  It doesn't matter that it won't be connecting to things.  It only needs to be present.  I am pretty sure that once Samba is setup you can power down the interface.

About the VOIP comment,  as long as you don't do any media translation you can run an asterisk server on a PI .  Nerdvittles has a ready made image to do just that.