12-02-2008 01:08 AM
Wherever iSCSI Storage locate in Trust or DMZ Zone, the iSCSI initiator always has problem in communicate with iSCSI Target?!
Does anyone know how to config iSCSI across firewall?
I use sniffer to capture packets, there were some packets pass through firewall but some packets seemed didn't pass?!
Anyone ever config iSCSI across firewall?
12-02-2008 07:10 AM
will try AndyT's suggestion then report back.
when I started iSCSI Initiator (from Internet across NetScreen MIP) to discover iSCSI Target, I could see iSCSI Initiator's name from Target side, it means iSCSI Initiator can across NetScreen and touch Target, but after this, when iSCSI Initiator tried to log on to iSCSI Target, the connection failed.
I wonder if NetScreen blocked some iSCSI packets?!
12-02-2008 07:21 AM - edited 12-02-2008 07:22 AM
sorry - i had assumed you were trying to initiate from a host on the trust zone into like a dmz or something such that port address translation could have been interfering... but by the sounds of it your still going to be going across a translated connection albeit via a mip.
have you verified that you can connect to the target when the initiator is on the same physical lan as the target? not even sure iscsi is supposed to work over a translated connection? what does technet have to say about it?
could you chuck a quick vpn across between the two sites so you are not going across a translated connection?
12-02-2008 07:47 AM
To see if the firewall dropped any of your iSCSI packets, you can do a "debug flow basic". Also a "snoop detail" can be very helpful. You can even do both at the same time so that you see exactly which packet is dropped, in case that happens.
This is what you can do in this case:
- make sure to log all text output from the console/ssh/telnet window to a text file set db size 4096 (to set the debug buffer to the max size of 4 MB) set ffilter dst-port 3260 set ffilter src-port 3260 set ffilter dst-port 860 (according to http://en.wikipedia.org/wiki/ISCSI this port may be used as well) set ffilter src-port 860 debug flow basic snoop filter ip dst-port 3260 snoop filter ip src-port 3260 snoop filter ip dst-port 860 snoop filter ip src-port 860 snoop detail snoop detail len 1514 snoop (answer 'y') snoop info (to check) get debug (to check) get ffilter (to check) clear db ...start the iSCSI connection and with untill it fails... press 'Esc' to stop the debug and the snoop. get db stream (to display the debug buffer content, can be long, up to 4 MB)
In the resulting text file, you can do a search for the words "drop" or "error" in the debug to find any problems.
To actually see the traffic dumped by snoop, you can open the text file containing the snoop and debug in wireshark (must be a recent version, like version 1.0 and higher). The packet capture will show the packets on both sides (interfaces) of the firewall.
I don't expect that the firewall drops any of the traffic after session creation, since for the firewall it is just a regular TCP service, which is just forwarded and NATed in this case. No special operations like ALG is done with it.
Let me know how it goes :-)
12-03-2008 01:47 AM - edited 12-03-2008 02:33 AM
I follow your suggestion and captured txt file as attached, no "drop" or "error" ?! any other suggestion?
12-03-2008 02:23 AM
The firewall is not dropping any packets. When looking at the packet capture (snoop) in wireshark you can see exactly what happens. I don't want to attach that pcap to this forum, since it contains some infirmation about your network (IP addresses etc). However you can easily get it by removing the --- more --- stuff and weird characters after that from the text file. Also remove the text that is above "ns5gt-> get db stream ". Then save the text file again. This new text file can be read in wireshark as a packet capture (pcap).
What can be seen in the pcap is a nice session with no packets dropped (all packets are passed by the firewall, since all packets are seen twice in the pcap). The session established fine (3-way handshake), then there is twice a Login Command and Response, which is successful.
After that we see a Text Command and Text Response, after which the client sends a Logout commandand the Server a Logout Response and the TCP session ends normally with a FIN handshake.
So it all looks fine, except that the client logs out and ends the session already after one second.
Now what could be the reason that the client ends the sesson? In frames 15 and 17 (the Text Command and Text Response) you can see what probably causes the problem. The internal IP adddress 192.168.x.x is mentioned in the Text Response from the server. Since that is in the application layer of the iSCSI protocol, this address is not changed in the NAT to the public IP address that the client sees.
Probably this leads the client software to logoff and end the connection gracefully.
12-03-2008 07:42 PM
I use 2 NetScreens to create VPN network and put iSCSI Initiator & Target on each side, then it work well, so I think it did look like what you said. I will continue try to find solution and see if without VPN, if you have any suggestion pls let me know, thank you for all your help!! ^_^
12-09-2008 02:20 AM
Using a VPN is an excellent idea. It solves two problems:
1) you avoid having to use NAT (which apparently is a problem for the protocol / client software)
2) you add security by encrypting the traffic.