Server wont allow access outside of subnet 1

[rleflore]

I am rather new to SCO unix, however not to Unix in general. I've done all things imaginable to correct this problem.

Problem: Server not allowing requests to telnet from outside the subnet, but is working fine within the subnet.

Hardware - Dell Gxa1, O.S. SCO 5.0.5
Our network has been recently reconfigured and all servers have been placed on the new subnet and are now working with the exception of the SCO server.

the following files have been confirmed to be absolutely correct.
/etc/hosts
/etc/resolv.conf
/etc/S99route
/etc/default/tcp

ifconfig displays information properly.

netstat -rn shows default route correctly.

netconfig information is also correct.

The following are pingable:
dns, router, the hosts itself, other hosts on the same subnet.


the 'ifconfig' file displays ip,netmask, and broadcast being correct.

What has been done to rectify?
-moved machine to different switch to isolate problem; same problem exists.

-reinstalled the NIC driver.

The only way to the machine is to telnet to a machine on the same subnet and then telnet to the machine in question.
Any help would be appreciated!

 

[PHV]

And what about traceroute ?

Hope This Help
PH.

 

[rleflore]

Traceroute to router, dns, - ok.

 

[Wonboodoo]

How about "ping" & "traceroute" to/from the workstations that are trying to telnet?

Also, are you running TCPWrappers? You can normally check by the existence of an /etc/hosts.allow & /etc/hosts.deny file and your /etc/inetd.conf entry for telnet has a "tcpd" entry in the sixth field for "telnet". TCPWrappers can be used to block/allow traffic from specified subnets.

 

[rleflore]

I've checked and there aren't any /etc/host.allow nor deny files. I'm pretty sure there weren't ever any TCP wrappers configured on this machine. I've checked and neither of the those files exists.
I've also tried changing the ip address but to no avail.
I'm skeptical about pointing at the router because other servers access the router without a problem. I'm also looking for patches that relate to this problem.

 

[stanhubble]

What are the symptoms of "not allowing requests to telnet".

Is it just hanging or does it say connection refused?

 

[rleflore]

to answer your question stanhubble,

telnetting to a server outside the subnet shows the following...
Trying ###.##.#.##...

Then after several minutes it displays the following message.

telnet: Unable to connect to remote host: Connection timed out

 

[stanhubble]

ok, to clarify then:

you are trying to telnet FROM the sco system TO another system outside of the subnet.

it thinks it knows how to get to the target system
( it doesn't come back with no route to host)

"The following are pingable:
dns, router, the hosts itself, other hosts on the same subnet."

When you say "the hosts itself" do you mean the other system on the remote subnet?

 

[Wonboodoo]

What about traceroute to/from the SCO server from/to the workstations?

Is the last hop from the SCO server to the workstations the default router?

Is the last hop from the workstations to the SCO server the default router?

 

[rleflore]

"The host itself" meaning the host in question. The "Host itself" meaning the SCO machine that is having the problems.

clarification...
there is a default route to the host as displayed with netstat -rn.

The router is pingable.
other hosts on this subnet can ping the SCO server that is having the problem. other hosts servers can telnet, ftp, and all other things, but servers on other subnets can't reach the SCO machine. The netmask, ip, broadcast, and gateway information has been confirmed to work fine. This server was working fine on a different subnet. I'm tempted to put it back on the subnet where it was working and then if it works I can definitely point it back to the router configuration for that subnet.
I'm pretty much open to all suggestions. Right now the users can access the server by telnetting to a server on the subnet where the SCO machine resides, However that's not very practical. I'm running out of options. Any and all suggestions are definitely being considered at this point.
thanks!

 

[stanhubble]

So in answer to my previous question:

your clients on the remote subnet are trying to telnet TO the sco server.

see what the results of the traceroute are, from both directions.

are the "clients" pingable FROM the sco system?

 

[rleflore]

So in answer to my previous question:

your clients on the remote subnet are trying to telnet TO the sco server.

see what the results of the traceroute are, from both directions.

From a client machine, The first and last hop is the router, and after that it never reaches the server.

To the client from the server, the first hop is NOT the router. The first hop is the server that I'm tracerouting to.

are the "clients" pingable FROM the sco system?

The clients on the remote subnet are not pingable.

 

[stanhubble]

ok....routing is definitely the problem.

on the sco system, use the netstat -nr command.
Is there a "Destination" that matches the remote subnet?

if there is remove it.
route delete <destination> <gateway>

then try to ping/traceroute the client machine.
if this works then you probably have a line in S99route that you will want to remove.

hth

 

[rleflore]

ok....routing is definitely the problem.

on the sco system, use the netstat -nr command.
Is there a &quot;Destination&quot; that matches the remote subnet?

NO there isnt!

if there is remove it.
route delete <destination> <gateway>

then try to ping/traceroute the client machine.
if this works then you probably have a line in S99route that you will want to remove.

 

[stanhubble]

ok.....hmmm

can you post the output of the netstat -nr ?

can you post the subnet mask of the local network and the subnet mask of the remote network?

 

[rleflore]

# netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface
default 1#2.##.2.1 UGS 0 0 net0
127.0.0.1 127.0.0.1 UH 1 2 lo0
1#2.## 1#2.##.1.36 UC 1 0 net0
1#2.## 1#2.##.1.36 UC 0 0 net0
224 1#2.##.1.36 UCS 0 0 net0


248 is the netmask for the SCO
The netmask for the unreachable portion of the network is different.

 

[stanhubble]

Are lines 3 and 4 identical in destination and gateway?

I also don't understand your reference of 248 for the netmask of the local network.

your table above says that your local network is
1#2.##.0.0 with a mask of 255.255.0.0
how different is the remote network?

you also should have an entry that looks like:

1#2.##.1.36 127.0.0.1 UGHS x x lo0

Other random things to confirm:
rs505a, oss471, oss497, oss600

 

[rleflore]

Are lines 3 and 4 identical in destination and gateway?

I also don't understand your reference of 248 for the netmask of the local network.

your table above says that your local network is
1#2.##.0.0 with a mask of 255.255.0.0
how different is the remote network?

255.255

you also should have an entry that looks like:

1#2.##.1.36 127.0.0.1 UGHS x x lo0

there aren't any entries like this.

Other random things to confirm:
rs505a, oss471, oss497, oss600

not sure what these are.

 

[stanhubble]

Other random things to confirm:
rs505a, oss471, oss497, oss600

These are updates to the base sco 5.0.5 system that need to be installed.
You can confirm these are loaded with the &quot;custom&quot; utility.

The other thing to consider is routed itself. If you don't need dynamic route discovery ( and you probably don't with your router ) you should prevent routed from starting.
The following link describes a similar but not exact problem.

http://support.caldera.com/rn_cgi/p...=1&p_search_type=2:faqs.faq_id&p_sort_by=dflt

(ps I hate sco's new taquery)

 

[rleflore]

I stopped the routed and all is well. It just seems awfully pecuuliar that the system worked fine all the time on a different subnet with the routed enabled. I've removed it from /etc/rc2.d as well. All servers can now access the SCO server from any subnet.

Thanks for your patience and support STANHUBBLE!