Please excuse the judicious crossposting, my excuse is that I have a
problem with Client Access that covers a wider than usual latitude.
I am having a problem relocating a client from a site with no firewall
(but with NAT) to one with a Symantec Network Firewall/ VPN Appliance
(the rebadged Nexland boxen).
In all cases, the target host is on the internet, itself operating
behind a firewall with a whitelist for security, accepting
conventional connections on port 23. (Please don't flame me about the
security of this configuration - I didn't build it!)
Googling produced no significant answers, so I'm hoping someone here
has seen something similar, either specifically with this appliance or
with something similar.
Basically, I can get Client Access v5.1 to work from Site A, the
original site. I can also use Mochasoft, standard Microsoft Telnet,
and Procomm Plus (!) to work.
Moving to Site B, the same hardware or similar hardware does not
attach to the host using Client Access - but it can connect using all
the other terminal emulators!
The reason why I don't cut my losses and switch to another brand is
that (apart from Mochasoft *apparently* - haven't checked personally
yet) none of the others do printing - i.e. I cannot specify a second
session to go to the printer.
I have also tried the alternative printing method of printing direct
from the host to a TCP/IP printer *inbound*, but that fares no better
- I can telnet to a HP Jetdirect box on port 9100 internally and use
it as a typewriter, but the firewall at this end seems to block it.
The firewall at the new site is currently as open as it will go, as
the site is currently in testing phase. All outbound ports are open,
and virtual hosts for email & web are running fine.
Anybody think of anything I've missed? :o)
Greg Lawton
Penacasata IT & Communications Resources.
Tel: 07767 623098
Fax: 07767 629037
Email: gr...@penacasata.REMOVETHIS.demon.co.uk
Jim
"Greg Lawton" <gr...@penacasata.REMOVETHIS.demon.co.uk> wrote in message
news:3f2mdv4b21sofgsrf...@4ax.com...
Hello, Jim. Thanks for responding.
>Start by ensuring that ports 445 to 449 are forwarded to the AS400. There is
>one more port to ensure that NetServer is accessible, but I cannot remember
>that port right now.
If you mean ports 445-449 on my local firewall, they already are - all
ports are open. I will lock down the local firewall once all
installation is complete and I get a report from the firewall telling
me what ports are being used on a regular basis.
I'm not trying to access anything fancy on the host server, just
telnet - why would these need opening, when every other terminal
emulator can attach without them? There's no SSH being done. (sadly!)
Port 445 is Microsoft-DS according to my docs - under what
circumstances would this ever be needed to be opened anyway when
talking to an AS400?
Find APAR II12227 - It's a complete list of all the ports that CAE uses !
/PGU
"Greg Lawton" <gr...@penacasata.REMOVETHIS.demon.co.uk> skrev i en
meddelelse news:3f2mdv4b21sofgsrf...@4ax.com...
> The firewall at the new site is currently as open as it will go, as
> the site is currently in testing phase. All outbound ports are open,
And inbound? Client Access uses many ports for it's different
services.
E.g. 449, 84xx. Maybe there's a list somewhere in the manual or the
web.
Just start it and watch the firewall log.
Walter
Thanks to everyone who helped, with particular thanks to Jim Thedorf
who was kind enough to email me with the port listing that others
mentioned.
The solution, for Google posterity is...
Client Access indeed is *much* fussier over the ports that need to be
opened *inbound* before it'll work. It didn't matter that all the
outbound ports were open (during testing phase), it sill needed them
opening.
I configured a virtual server to funnel the inbound ports to the
workstation - fortunately they are ports not in common use elsewhere.
I still intend to play about it a bit further, since I need to
sanitize the outbound port list, and see if the firewall supports
multi-forwarding etc.
The ports inbound that need to be opened are 449, 5061, 5110,
8470--8479, 9600-9601. (All TCP)
Again, many thanks everyone.
I am going to guess, the TELNET and IP printing will probably required
static routes if your doing NAT.
>I am going to guess, the TELNET and IP printing will probably required
>static routes if your doing NAT.
Indeed they did, solved by configuring virtual servers on the
firewall.