Re: Remote telnet through firewall failing - SOLVED

• Previous message: John: "Re: Remote telnet through firewall failing - SOLVED"
• In reply to: John: "Re: Remote telnet through firewall failing - SOLVED"
• Next in thread: Jeff Liebermann: "Re: Remote telnet through firewall failing - SOLVED"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Mon, 20 Dec 2004 07:56:45 -0500

John wrote:
>
> Mike Brown wrote:
>
> > John wrote:
> >>
> >> Mike Brown wrote:
> >>
> >> > John wrote:
> >> >>
> >> >> Mike Brown wrote:
> >> >>
> >> >> > John wrote:
> >> >> >>
> >> >> >> I have built a replacement 5.0.5e server from a fresh install,
> >> >> >> which is now
> >> >> >> working on my LAN. Telnet from within the LAN to the SCO system
> >> >> >> works fine, however if I attempt to telnet to it from outside (the
> >> >> >> GNet IP0006 router is forwarding port 23 to the SCO system) then
> >> >> >> the attempted
> >> >> >> connection times out with no evidence of contact. I can telnet
> >> >> >> from outside to other (Linux) systems on the LAN, so it appears to
> >> >> >> be a SCO
> >> >> >> configuration issue. Any suggestions (other than using SSH) would
> >> >> >> be welcome.
> >> >> >>
> >> >> >> Routing tables
> >> >> >> Destination Gateway Flags Refs Use
> >> >> >> Interface
> >> >> >> 127.0.0.1 127.0.0.1 UH 2 24 lo0
> >> >> >> 192.168.1 192.168.1.2 UC 1 0 net1
> >> >> >> 192.168.1.2 127.0.0.1 UGHS 4 26 lo0
> >> >> >> 224 192.168.1.2 UCS 0 0 net1
> >> >> >>
> >> >> >> Terminal type is wyse60
> >> >> >> $ telnet xx.15.1x6.52
> >> >> >> Trying xx.15.1x6.52...
> >> >> >> telnet: Unable to connect to remote host: Connection timed out
> >> >> >> $
> >> >> >> (IP numbers have been changed for obvious reasons)
> >> >> >>
> >> >> >> --
> >> >> >> John Turner
> >> >> >
> >> >> > Some suggestions ...
> >> >>
> >> >> Thankyou for these ...
> >> >>
> >> >> > have someone run the "netstat -an" command right after the WAN
> >> >> > telnet attempt to see if the remote packets are getting to the SCO
> >> >> > box. Your should see a line with your server IP in the local column
> >> >> > and the remote IP in the remote column.
> >> >>
> >> >> There is no such entry. If I telnet internally then entries do
> >> >> appear, but nothing from a telnet attempt from outside.
> >> >>
> >> >> > reduce the MTU, "ifconfig net1 mtu 1320". This can be set up without
> >> >> > a reboot, and can be reset back " ifconfig net1 mtu 1500".
> >> >>
> >> >> No change from doing this. ifconfig -p net1 shows the change was
> >> >> effective, but it does not affect the telnet problem, and still
> >> >> nothing from netstat -an with mtu at 1320.
> >> >>
> >> >> > check to make sure the netmasks are all set correctly, looks like
> >> >> > the should be 255.255.255.0 or 24 bits from your other posts.
> >> >>
> >> >> ifconfig and netconfig show 255.255.255.0 or ffffff00 as expected
> >> >>
> >> >> > configure DNS, create/edit a file called /etc/resolv.conf
> >> >> >
> >> >> > hostresorder local bind
> >> >> > nameserver 24.153.22.141
> >> >> > nameserver 24.153.22.142
> >> >>
> >> >> /etc/resolv.conf was empty so I have added entries on this pattern
> >> >> using the name servers from the gateway, and even added 192.168.1.1
> >> >> for a brief while
> >> >> just in case. It does not seem to help, and an attempt at traceroute
> >> >> out is unaffected:
> >> >>
> >> >> # traceroute x6.1x8.2x9.230
> >> >> traceroute to x6.1x8.2x9.230 (x6.1x8.2x9.230), 30 hops max, 40 byte
> >> >> packets
> >> >> 1 gateway (192.168.1.1) 0 ms 0 ms 0 ms
> >> >> 2 * * *
> >> >>
> >> >> I have left the changes to /etc/resolv.conf in case they form a
> >> >> component of the eventual solution.
> >> >>
> >> >> > I see that the network is net1, not net0. You may be one of those
> >> >> > rare
> >> >> > sites that have a messed up netconfig. To test, and a host route
> >> >> > for the remote IP to your local router ( 192.168.1.1 ) and see if
> >> >> > the telnet starts working.
> >> >>
> >> >> I don't think this can be tried, since the router is a simple
> >> >> configurable
> >> >> hardware firewall that does not allow the addition of routes. I
> >> >> switched it to static and put the remote IP in as nameserver, probably
> >> >> a useless effort anyway, and it made no difference, so I promptly put
> >> >> it back to normal.
> >> >>
> >> >> > if all else fails, use a packet sniffer. You will have to configure
> >> >> > the sniffer, SCO and the Gnet all on a hub. The Linux box likely
> >> >> > could run ethereal.
> >> >>
> >> >> This is an interesting idea. I am thinking that I would have add a
> >> >> NIC to a Linux box and temporarily reconfigure it to be the router,
> >> >> then run
> >> >> ethereal to see what is passing through. I'll see about giving this a
> >> >> try later in the week when time and opportunity coincide.
> >> >>
> >> >> --
> >> >> John Turner
> >> >
> >> > The additional host route would be on the SCO box, something like
> >> >
> >> > route add -host x6.1x8.2x9.230 192.168.111.1
> >> >
> >> > Your Linux box likely does not need a dedicated NIC, fire up ethereal
> >> > and
> >> > start a capture to see if it works. All your need to do is plug it,
> >> > SCO and the internal connection of the Gnet to a hub ( not a switch )
> >> > and your in business.
> >>
> >> I used a local Linux machine to open a telnet on a remote machine and
> >> then initiated a telnet from it back to the local SCO machine (which
> >> would work
> >> if it was to another local Linux machine). After the initial
> >> negotiations involving TELNET Telnet Data ... and TCP telnet [ACK]
> >> associated with starting the session, I see a repeating theme of ARP Who
> >> has 192.168.1.2? Tell 192.168.1.1 broadcasts that bear the WAN MAC
> >> address of the GNet
> >> router. Interesting ? I don't know what the implications of this might
> >> be, but it looks vaguely relevant.
> >>
> >> --
> >> John Turner
> >
> > Very interesting. An ARP broadcast would make sense when the router is
> > looking for a NIC by IP address, as it would at the begining of a telnet
> > negotiation. The SCO server should respond to the request, even if the
> > router is giving the WAN MAC in the packet. Does the SCO box respond to
> > the ARP request at all?
> >
> > You could check the ARP table on SCO to see if there is anything strange
> >
> > arp -an
> >
> > and maybe in the router.
>
> Your final words were magic. I thought it would be a waste of time to look
> for arp in the router since it is just a simple configurable hardware
> firewall device. However I poked around anyway and discovered that there
> is a function to manage IPs by MAC address that can be enabled.
>
> Sure enough, it was enabled, though I have no idea why - it makes no sense
> to me without wireless capabilities on the LAN. It also had the wrong MAC
> address in it for 192.168.1.2. This was because the SCO machine is a
> previous Linux box I had ripped apart to put SCO on. SCO had not liked the
> NIC, which I therefore changed out for a 3C905C it would accept.
>
> As soon as this function was disabled 192.168.1.2 was able to traceroute
> out, and promptly responded to telnet requests.
>
> Thank you Mike, for your winning suggestion. Thanks also to all you others
> who responded in an effort to help me with this problem and provided me
> with useful education for the future. I doubt if this will prove to be a
> common problem, but perhaps some other poor demented soul will eventually
> benefit from the record of this epic struggle.
> --
> John Turner

Fixed between 11PM and 7AM, pretty good hours you work! Lucky customer.

You should be able to config DNS now and have it work.

Mike

-- 
Michael Brown

• Previous message: John: "Re: Remote telnet through firewall failing - SOLVED"
• In reply to: John: "Re: Remote telnet through firewall failing - SOLVED"
• Next in thread: Jeff Liebermann: "Re: Remote telnet through firewall failing - SOLVED"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]