RE: Remote mathkernel through firewall behind NAT
- To: mathgroup at smc.vnet.net
- Subject: [mg46743] RE: [mg46737] Remote mathkernel through firewall behind NAT
- From: "Virgilio, Vincent" <Vincent.Virgilio at itt.com>
- Date: Fri, 5 Mar 2004 01:46:44 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
Hello, Only an idea: Your problem sounds similar to the 'secure ftp' (soluble) problem in ssh. Where, it is desired to tunnel ftp traffic through ssh. The initial ftp control session is made to a well-known port (21) - and thus works well with ssh. But that control session establishes data sessions at other, essentially random, ports - which does not work well with ssh. There are solutions to this, which I don't have at my fingertips. I think the O'Reilly book on ssh contains those solutions and might serve as a template for you. As might its coverage of NAT issues (if memory serves). Regards, Vince Virgilio -----Original Message----- From: =?ISO-8859-1?Q?Antti_Penttil=E4?= at smc.vnet.net [mailto:=?ISO-8859-1?Q?Antti_Penttil=E4?= at smc.vnet.net] To: mathgroup at smc.vnet.net Subject: [mg46743] [mg46737] Remote mathkernel through firewall behind NAT Hi, I have quite a tricky problem with remote kernels. I have used remote Mathematica kernel (on windows machine) with a front end on Macintosh OS9. This used to work with Mathematica 4 and (possibly) different network environment, but it does not work anymore after upgrading to Mathematica 5. The problem is the following: Front end and kernel are in different subnets, and there is a firewall between them. I can negociate with the network administrator that certain IP-ports will be open in the firewall for Mathematica-traffic. I can force Mathematica to use certain port, for example port number 30000 by starting the kernel with these options: math -mathlink -linkprotocol TCPIP -linkmode listen -linkname 30000 and giving these options as "Arguments to MLOpen:" in the kernel configuration menu in the front end: -LinkProtocol TCPIP -LinkMode Connect -LinkOptions MLDontInteract -LinkName 30000 at server.address.here This configuration works fine when both the machines are in the same subnet and there is no firewall. However, it does not work when the firewall is between. I have used a network traffic monitor program to analyze the problem, and I found out that Mathematica is mostly using the port 30000, but it also sends some packets using different port. This will happen after the front end and kernel have exchanged a TCP/IP-packet, which includes the text "msg_port=number", where the number changes from session to another. Because the first packet to this port is send from the front end, it can not pass the firewall, and thus the connection fails. Is there any option to define also the other port number to Mathematica? I could solve the firewall problem by launching the connection other way around, and invoking the kernel by: math -mathlink -linkprotocol TCPIP -linkmode connect -linkname 30000 at frontend.address.here and giving "Arguments to MLOpen:": -LinkProtocol TCPIP -LinkMode Listen -LinkOptions MLDontInteract -LinkName 30000 because in this configuration all the IP-tunnels are first opened from the kernel side, and thus OK for the firewall. The problem with this is, that the front end machine is behind an ADSL-box and has only a private IP-address which is NAT-translated. This could be resolved with adding some routings to ADSL-box or obtaining a public IP-address, I think? Any other ideas? -- Antti Penttilä Antti.I.Penttila at helsinki.fi.removethis ************************************ This email and any files transmitted with it are proprietary and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of ITT Industries, Inc. The recipient should check this email and any attachments for the presence of viruses. ITT Industries accepts no liability for any damage caused by any virus transmitted by this email. ************************************