Service / Network segregation

[rainman]

Hi,

I've been a QNAP user for some years and one of the features missing on Asustor (as far as I can tell) is the ability to select which service uses which ethernet port. I think that at present the interfaces can only be aggregated/bonded/whatever and if that feature isn't used then all protocol are 'in band' across all ports - this really isn't useful.

I've recently purchased the AS-608T and I want to service my home network on one interface (into one switch which services all hosts on my home network) and then service my ESXi SAN on a seperate interface which is patched into a seperate switch which only carries dedicated iSCSI traffic . I don't want iSCSI traffic on my home network segment, and likewise I don't want SMB/CIFS/HTTP/whatever on my iSCSI network. I need them physically isolated from each other. I can do this on my QNAP device, I just tick a box to select which service I want going down which interface, easy.

Why isn't this possible? I would have thought it was pretty basic. Is it a feature coming soon? I don't mind waiting for it, or if I've missed it somewhere then I'd love for someone to tell me where I can configure it.

If I can't do it then it will have to go back where I bought it from, as I don't see that this is fit for the puspose of virtualisation. I don't want to cause latency on my iSCSI segment with unwanted protocols going onto it, and I don't want to HAVE to secure my iSCSI connections because they are all now exposed to the rest of my network. It really isn't satisfactory and I would have expected an 8 drive NAS to have significantly more control over the configuration.

Phil

[Auberon2k]

I understand what you are saying but there would be equally effective methods of acquiring the same segregation as it stands. being that you are saying you have two separate network segments, each LAN port has an independant IP address. iSCSI being what it is you are targetting a specific IP and even a dual homed system would only direct traffic to the one you specified. I have my 608T with independant LANs connected to my router and switch. The switch is shared with my ESX host downstream from the router, while the router is shared with all my laptops & media devices. All my connections, iSCSI, NFS and Drive mappings from the ESX host are directed to the LAN2, while LAN1 enjoys clear skies for sharing media. Even thought they are not physically isolated in my case, any traffic directed at LAN2 will not hit the home segment.

One very easy solution also could be to set a different IP schema for your iSCSI LAN. ie, 192.168.0.x for home, 10.0.0.x for iSCSI ports on the ESX/NAS.

The nature of switching means that your packets should not be broadcasting everywhere, you may be thinking of old broadcasting hubs. Switches, even dumb home network ones only pass packets between the source and destination. Thus if your NAS iSCSI IP is on the switch the ESX is plugged into the traffic *should* never leave that switch to the rest of your home network.

I just tested this on my ESX host and NAS, I confirmed that while I could potentially add an iSCSI target that pointed at the LAN1 IP of the NAS, I did create the target pointing at the LAN2 IP which shares a common switch with the host.


Something more I just considered. Based on your description (and unlike my setup) you have no direct uplink between SwitchA and SwitchB. But both the NAS and ESX are dual homed currently, one port on each switch. This would very easily lend itself to an IP based schema like I mentioned above. Then you would be 100% sure that no iSCSI traffic is flowing across the home network. You have to specify the iSCSI host by IP, not hostname. It would not be able to communicate with 10.0.0.x across the 192.168.0.x network at all.

[rainman]

I understand what you are saying but there would be equally effective methods of acquiring the same segregation as it stands.

Well no, there isn't. It simply isn't the same level of segregation that I currently get out of my QNAP device.

being that you are saying you have two separate network segments, each LAN port has an independant IP address. iSCSI being what it is you are targetting a specific IP and even a dual homed system would only direct traffic to the one you specified.

By not being able to turn off iSCSI on a specific port it is effectively there and available for anyone and anybody to access your iSCSI traffic. By it's very nature iSCSI traffic is not encrypted and adding a layer of athentication (such as CHAP) then it's another protocol to maintain and administer - if the network is physically isolated then it's not an issue. What you're describing is 'security by obscurity' and thats simply not good enough. All I would need is for someone to hack my wireless connection and they would potentially be able to access my iSCSI resources. If you have a household with a lot of people that come and go and you share your wireless key with people then it will always be a weakness on your network. You MUST be able to explicitely consign iSCSI traffic to a port of your choosing, anything else flys in the face of every 'best practice' iSCSI guide ever written.

I have my 608T with independant LANs connected to my router and switch. The switch is shared with my ESX host downstream from the router, while the router is shared with all my laptops & media devices. All my connections, iSCSI, NFS and Drive mappings from the ESX host are directed to the LAN2, while LAN1 enjoys clear skies for sharing media. Even thought they are not physically isolated in my case, any traffic directed at LAN2 will not hit the home segment.

You can't guarantee that. You only need one device to initiate a connection, even if not done deliberately but more likely accidentally, and you have iSCSI traffic smashing up the backplane bandwidth of your network switch.

One very easy solution also could be to set a different IP schema for your iSCSI LAN. ie, 192.168.0.x for home, 10.0.0.x for iSCSI ports on the ESX/NAS.

I already do exactly that, and whilst the NAS device itself won't route traffic between the networks, again you only need an errant windows host connected to your iSCSI network to end up with other traffic on that segment with the potential to cause latency on your iSCSI segment.

The nature of switching means that your packets should not be broadcasting everywhere, you may be thinking of old broadcasting hubs. Switches, even dumb home network ones only pass packets between the source and destination. Thus if your NAS iSCSI IP is on the switch the ESX is plugged into the traffic *should* never leave that switch to the rest of your home network.

I'm not talking about broadcast, as you say it's not an issue - but if you have a host connected to your iSCSI network (such as a multihomed Windows host where you want to use iSCSI on one NIC) then there is the possibility of have two connection end points which will send CIFS/SMB traffic to and from each other - which isn't broadcast. It's a scenario which CAN happen. I could pull iSCSI traffic out of your NAS on your home media segment from a Windows 7 host in about 4 mouse clicks, since I already know the IP address of the host. It's way too easy.

I just tested this on my ESX host and NAS, I confirmed that while I could potentially add an iSCSI target that pointed at the LAN1 IP of the NAS, I did create the target pointing at the LAN2 IP which shares a common switch with the host.

Right, well you just hit the nail on the head when you used the word 'potentially'. It is that potential which really needs to be iradicated. If you have a number of VM's all using a datastore connected via iSCSI then one errant host could impact all of your iSCSI based VM's. I have around 10 running at any one time, some of which run things like mail servers, etc, and I'm not prepared to expose those hosts to that potential risk. Period. This is my lab environment that I also use for testing, so things change and get added and tweaked and played with. I need to know that the integrety of my iSCSI segment cannot be undermined, and with the Asustor NAS it can be. It's not good enough for the task of virtualisation.

Something more I just considered. Based on your description (and unlike my setup) you have no direct uplink between SwitchA and SwitchB. But both the NAS and ESX are dual homed currently, one port on each switch. This would very easily lend itself to an IP based schema like I mentioned above. Then you would be 100% sure that no iSCSI traffic is flowing across the home network. You have to specify the iSCSI host by IP, not hostname. It would not be able to communicate with 10.0.0.x across the 192.168.0.x network at all.

As I said, thats exactly as I have it configured, and it's not a guarantee of segregation. You MUST be able to physically isolate iSCSI traffic entirely just as you can on QNAP and on others ... there is a reason why they facilitate this.

I took delivery of an AS-608T yesterday and after realising that this device is missing just so much basic functionality I've sent it back for a refund, as it's not fit for purpose. It's even missing some really basic functionality at the volume management level. It's very sad and I would have expected much more from Asus to allow such an immature product to reach the market in it's current condition. I wondered why this device was £200 cheaper that it's closest QNAP rival, and now I understand why.

[Auberon2k]

I agree, it's a feature that should be added in. I actually wasn't using an iSCSI store until I was testing it here. You are correct, all I'm doing is "hiding" it's presence, not actually locking it out from one LAN segment. One solution that most definitely works though is NFS. I have all my ISOs on my NAS shared for my use on various other machines. Not wanting to duplicate and waste space I shared the same CIFS/SAMBA share over NFS and mounted the whole thing as another datastore in ESX. NFS mounts do allow targetting, but this could still be "broken" if a machine were to bridge the LAN segments. NFS permissions allow you to specify allowed host IPs to access the NFS mount point.

I'm sorry you had to return the device but understand what you are saying. My ESX isn't running anything "production", it's a server I managed to grab from the retirement pile at work to setup a home lab and do some self improvement. This is why I personally felt OK with the implementation right now. There is room for improvement though and Asustor is very good about that.

[Godlike]

I agree with rainman. I didn't see this post before I got my new AS-608T. It SHOULD be possible to select the iSCSI interface (LAN1, LAN2 or both). I had to use CHAP as a "quickfix". Real annoying.