Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[stevewa]

Well it's been a frustrating 36 hours of moving the office over to our new location. We are using the same server machines, but we have a new dedicated ip address and a new firewall device (D Link DFL-200).

I can connect to the telnet server from inside the LAN, but I cannot connect to it from the WAN.  I am using a D Link DFL-200 firewall, and I had to do port forwarding because the Firewall does NAT, so I could not create an "Allow/Deny" policy.

I forwarded all telnet traffic (port 23) to the internal LAN ip of the machine that is serving as the telnet host, but nothing happens when I try to connect... actually I get a timeout, connection failed message (new telnet failed)

I did port forwarding for remote admin (mapping a port number to an internal ip address of a machine on the LAN, and that worked, so I am pretty sure that I did the port forwarding correctly...

The admin licenses reside on a different server (a windows 2003 box that is the same one that worked before in our other office at a different ip address), so I don't know if I need to map a different port to that machine so it can validate the license when the telnet session starts, but i think I would have gotten some sort of license error message from dejavu.exe if that was the case...

Any suggestions? I think it may be the telnet server itself needs to have a setting changed, since our internet gateway ip on the LAN changed from .254 to.1 when we moved over...

[Bob]

Well it's been a frustrating 36 hours of moving the office over to our new location. We are using the same server machines, but we have a new dedicated ip address and a new firewall device (D Link DFL-200).

I can connect to the telnet server from inside the LAN, but I cannot connect to it from the WAN.  I am using a D Link DFL-200 firewall, and I had to do port forwarding because the Firewall does NAT, so I could not create an "Allow/Deny" policy.

I forwarded all telnet traffic (port 23) to the internal LAN ip of the machine that is serving as the telnet host, but nothing happens when I try to connect... actually I get a timeout, connection failed message (new telnet failed)

I did port forwarding for remote admin (mapping a port number to an internal ip address of a machine on the LAN, and that worked, so I am pretty sure that I did the port forwarding correctly...

Something is wrong with getting port 23 through. From your description above it sounds like you have done the right thing to get it to work. You are of course telnetting to the outside address of the dlink box, right?. You obviously cannot telnet to the same address you use on the lan.

Try MS telnet (start->run in the command box type in telnet and the public ip address of the dlink box). See if you get a connection. I bet you will not.

If you've configured the dlink box right, something else is blocking port 23 through that path. Perhaps you have port filtering turned on a router on the remote side or some other firewall on the server side or a firewall on the unix box (probably not if it's SCO).

The admin licenses reside on a different server (a windows 2003 box that is the same one that worked before in our other office at a different ip address), so I don't know if I need to map a different port to that machine so it can validate the license when the telnet session starts, but i think I would have gotten some sort of license error message from dejavu.exe if that was the case...

Any suggestions? I think it may be the telnet server itself needs to have a setting changed, since our internet gateway ip on the LAN changed from .254 to.1 when we moved over...

The iceadmin server doesn't matter at all with regards to this problem. Since the server is static it has nothing to do with any connection once you've obtained a license.

[stevewa]

well I should update this thread...

all is well, the unix software that people were trying to access from outside the firewall needed to have it's gateway ip value changed, which the vendor was supposed to do but they did not, so i wasted some time over the weekend playing with a problem that was quickly resolved on monday morning.

it was not related to tcp pro at all...