This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I'm trying to connect to my ReadyNAS from my server at work via iSCSI. The server discovers the target but when I try to connect it hangs for about two minutes and finally errors "Connection Failed". This happens regardless with CHAP enabled or disabled.
I have port forwarded and even put the NAS in a DMZ in case there were any NAT'ing issues but have the same issue.
Looking at Event Viewer on my server I see two errors when tying to connect:
"Initiator failed to connect to the target. Target IP address and TCP Port number are given in dump data."
"Error occurred when processing iSCSI logon request. The request was not retried. Error status is given in the dump data."
Am I missing something? Can you not use an iSCSI connection over WAN with this ReadyNAS?
Re: Connecting a ReadyNAS iSCSI to a remote server
I did a quick test with a RN214 and, just for the record, it does return the IP address assigned to its LAN interface in response to a 'SendTargets' from the initiator. So in the case of your home router, the DMZ setup on it (at least per the quick glance I took at the manual for it) still peforms NAT (as StephenB explained) as the IP address assigned to the devices on the DMZ are still private IP addresses. In order for this to work over the Internet without a VPN or other tunnel you'd need to have the ReadyNas on the same segment as the 'Internet' interface with an IP address in the same subnet as the Internet interface of your home router. Also, as StephenB mentioned, I'd not do that with anything I even remotely considered valuable.
I think you'll have success with the VPN connection method and your use-case for this sounds feasible (small files/infrequent use) given the bandwidth you have provided your Internet connections aren't being heavily used otherwise.
Re: Connecting a ReadyNAS iSCSI to a remote server
When you placed the ReadyNAS in your DMZ it was assigned routable/public IP address, correct? If that is the case I do not see, off-hand, why that would not at least connect. How well iSCSI would actually work over the WAN would, of course, depend on available bandwidth, QoS, etc... as iSCSI isn't typically used in WAN environments or on routed networks in general (unless we are speaking of L3 switches). Being a block-level protocol it requires high-throughput/low-latency connectivity to work reliably.
The other scenario you describe (with NAT/port-forwarding) typically fails as, even though the initial connnection seems to work, the logon fails because the target will return its private IP to the initiator and the initiator will use that private IP to attempt to complete the logon and the attempt will fail. You can see this if you use Wireshark or other network packet/protocol analyzer software to capture the iSCSI session attempt and look at the decoded traffic.
Using a site-to-site VPN or other tunnel between the two networks would be the easiest way to get this going if that is an option for you at all.
My honest recommendation though (not that you asked for any recommendations), unless you are doing this just for acedemic purposes or to see if it will work just for fun, is to not use iSCSI in this scenario unless you have a 1Gbps or better WAN connection and can guarantee dedicated bandwidth for the iSCSI traffic via QoS. Best case scenario if you get it working is that it will still probably leave you disappointed with the performance. Worse case is you'll get more data corruption that you bargained for.
I'm interested in hearing about how you get on with this though if you decide to pursue it further though.
- When an iSCSI discovery connection is to be used through a port
redirector, a target will have to be configured to return a domain
name instead of an IP address in a SendTargets response, since the
port redirector will not be able to map the IP address(es)
returned in the iSCSI message. It is a good practice to do this
anyway.
If such a configuration change on the RN424 iSCSI target is possible for the SendTargets response you could then place an entry in your local DNS or server host file for the host/domain that is returned and point that to your external IP on your home router. I have a feeling such a change is beyond the scope of 'normal usage' for the RN424, but perhaps someone who knows a bit more about the underlying iSCSI functionality of the device could shed more light on that.
When you placed the ReadyNAS in your DMZ it was assigned routable/public IP address, correct?
Not exactly. In home routers, the NAS still is assigned a private IP address, and NAT is still done by the router. As far as the NAS knows, it only has a local IP address.
What changes is that all unsolicited inbound IP packets are automatically forwarded to the NAS, unless there is a forwarding rule defined for them in the router. Some folks who put their ReadyNAS in the DMZ lost their data to ransomware, because they did also had anonymous access enabled on their shares. SSH and https might also reach the NAS (and allow someone to hijack the NAS). So it's not something I recommend.
The other scenario you describe (with NAT/port-forwarding) typically fails as, even though the initial connnection seems to work, the logon fails because the target will return its private IP to the initiator and the initiator will use that private IP to attempt to complete the logon and the attempt will fail.
Not sure, but something like that is possibly going on. If an IP address is returned in response to the SendTargets command, then it would be a private address (since that is all the NAS knows). If the initiator were to use that returned IP address, then of course that would fail to connect. Though RFC 3720 doesn't require SendTargets to return an IP address (and there are some examples in the RFC when it does not). In those cases the existing connection is used by the initiator (which ought to work).
As you say, wireshark would show whether the NAS is returning a private address (and you'd also see if the initiator was trying to use it).
Using a site-to-site VPN or other tunnel between the two networks would be the easiest way to get this going if that is an option for you at all.
I agree that a VPN would eliminate any possibility that the connection is failing because SendTargets is returning a private address (as it might well be doing). It wouldn't need to be a site-to-site VPN - a remote access VPN from the client PCs (running the initiators) to the home network would also work. Either way, a VPN also provides better security than port forwarding.
FWIW, I agree that iSCSI won't perform very well over most internet (WAN) connections.
When you placed the ReadyNAS in your DMZ it was assigned routable/public IP address, correct?
Not exactly. In home routers, the NAS still is assigned a private IP address, and NAT is still done by the router. As far as the NAS knows, it only has a local IP address.
What changes is that all unsolicited inbound IP packets are automatically forwarded to the NAS, unless there is a forwarding rule defined for them in the router. Some folks who put their ReadyNAS in the DMZ lost their data to ransomware, because they did also had anonymous access enabled on their shares. SSH and https might also reach the NAS (and allow someone to hijack the NAS). So it's not something I recommend.
Agreed, however, the OP didn't mention what kind of router they used at home so I did not want to assume they were using a 'home' router right-off and was looking for them to clarify. For example, I do not. So if I were to place something in the 'DMZ' on my home network it would indeed be using an Internet routable IP and no NAT is involved. I do realize that is probably not typical, but didn't want to discount the possibility they are doing somethig similar. Especially since their logic seemed to imply that by putting the RN424 in their home network's DMZ it was removing the factors of NAT and port-forwarding.
Re: Connecting a ReadyNAS iSCSI to a remote server
Sorry I was out of town this weekend. It sounds like I'm trying to do is possible.
To answer your questions:
Yes this is more for having a secure access for moving small files that I want to offload from my server from time to time. Both sites have a pretty quick connection (office 300Mbps upload/home 100Mbps download). A VPN is something I had considered.
The router at home is a cheaper Cisco Linksys EA3500 (plan to replace soon). Right now the NAS is configured in the DMZ so port forwarding from the home shouldn't be an issue. I wonder if I need to forward any ports on my firewall at my office (Sonicwall TZ300)?
Both sites are statically assigned on the WAN. The NAS is statically assigned on the router.
For now I'm going to look into any port forwarding that needs to be done from my office. Thanks for the replies.
Re: Connecting a ReadyNAS iSCSI to a remote server
I did a quick test with a RN214 and, just for the record, it does return the IP address assigned to its LAN interface in response to a 'SendTargets' from the initiator. So in the case of your home router, the DMZ setup on it (at least per the quick glance I took at the manual for it) still peforms NAT (as StephenB explained) as the IP address assigned to the devices on the DMZ are still private IP addresses. In order for this to work over the Internet without a VPN or other tunnel you'd need to have the ReadyNas on the same segment as the 'Internet' interface with an IP address in the same subnet as the Internet interface of your home router. Also, as StephenB mentioned, I'd not do that with anything I even remotely considered valuable.
I think you'll have success with the VPN connection method and your use-case for this sounds feasible (small files/infrequent use) given the bandwidth you have provided your Internet connections aren't being heavily used otherwise.
Re: Connecting a ReadyNAS iSCSI to a remote server
Thanks for the information.
As an update I ended up building an L2TP VPN, seems like everything is working this way so far. When I get this router replaced I'll probably configure a site-to-site VPN instead with the new firewall. I'm going to mark this as resolved for now.
