Telnet IP/port - Testing for connectivity question

I'm trying to install some timeclocks at a site, and the clock is having connectivity issues.  I'm thinking it's the clock because we've already installed 15 of them at different sites, but need to confirm why its the clock.  This switch is sitting behind a firewall and needs to go out the internet into the vendor's server in their DMZ (172.156.69.22, port 443).  

I did a telnet 170.146.69.22 443 from the switch and get the following output:

Core_Switch>telnet 170.146.69.22 443
Trying 172.156.69.22, 443 ... Open


Does this telnet test prove that the routing is good from my switch out to their server and back?  

Another question:  If I see traffic leaving my FW, but no hits on return traffic, what are some possible root causes?
PeraHomanAsked:
Who is Participating?
 
AkinsdNetwork AdministratorCommented:
Yes, from the core to the server.
It doesn't include connectivity from the clock to the switch - That wouldn't be a rout issue but a layer 2 issue
0
 
AkinsdNetwork AdministratorCommented:
It looks like connectivity is okay from the core switch if the telnet was successful
Is the vendor using a NATed address for the clock (verify address is typed and mapped correctly)
Verify the vlan on the port switch the clock is connected to as well
0
 
PeraHomanAuthor Commented:
To make sure, the telnet test is proof that the vendor's server is reachable and has a route back into my network.



We are using a private address in our network for the time-clock.  It then gets routed through our shared internet circut we use for small sites.  The clock is pingable within our network, but there's an issue reaching their server.  Our security guy said he sees traffic leaving, but not returning (not sure how this is happening)
0
Prepare for an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program curriculum features two internationally recognized certifications from the EC-Council at no additional time or cost.

 
frankhelkCommented:
The classic test for routing issues would be PING, if that failes, traceroute would be the next stop on the road.

If traffic goes out, but didn't come back, I presume the returning route is affected. Keep in mind:

Setting a route tells a station who will accept packets to be transported to a remote destination. That doesn't include information for the remote destination's station how to send packets back to you, so the clock on the other side needs routing info, too. And that's not a weakness, it's one of the strongest powers of the internet.

So be sure that the clock on the other side has a ruting entry that tells it how to reach your system .... most routing problems I stumble upon emerge from such config errors.
0
 
AkinsdNetwork AdministratorCommented:
The telnet results eliminates routing issue from core to the server as well as confirm that the port is open. If the test had failed, then a trace route or port testing would be necessary.

With that said, can you ping the clock from the switch?
0
 
PeraHomanAuthor Commented:
Ping and trace routes won't work on my case because they are disabled at the FW whenever traffic is trying to leave the network and out to the Internet.

I don't think routing is an issue because we are able to open a telnet session to the ADP server at the switch where the clock is hanging from. What I really wanted to know is: if I'm able to telnet from my switch to the vendors clock server then is it justifiable to say that IP routing is good between the two and the issue lies elsewhere.
0
 
PeraHomanAuthor Commented:
Yes. I can ping the clock. It's confusing because  the FW guy said he sees traffic leave but no return traffic. If it's the clock then shouldn't we see a hit on the return traffic at the firewall or does it have to hit the clock to count it as a hit?  The FW guy did say there was no NAT involved, but the ADP server is located out through the Internet so there should be NAT...right? -- maybe he doesn't know what he's saying?
0
 
PeraHomanAuthor Commented:
The clock to the switch is fine. We can ping it and it shows up on the arp table. I'm thinking it's the clock -- maybe that clock doesn't have certain ports opened or faulty.
0
 
AkinsdNetwork AdministratorCommented:
Ok
Was the clock pre programmed?
Check the configuration on the clock and maybe compare with one of the ones that are working.
There' a chance something is wrong on the clock config

If a known working clock is available for testing, it won't hurt to try that from that location as well
0
 
Ian ArakelNetwork Lead: Data and SecurityCommented:
Hi There,

A confusion.
i)

This switch is sitting behind a firewall and needs to go out the internet into the vendor's server in their DMZ (172.156.69.22, port 443).

Is 172.156.69.22 IP of the clock server that you refer to?

ii)
Core_Switch>telnet 170.146.69.22 443

The IP that you have updated out here is incorrect.


I somehow feel that there is some IP mismatch since the routing is appropriate and return traffic would fail primarily during routing issues.
0
 
Ian ArakelNetwork Lead: Data and SecurityCommented:
Hi Author,

Could you share what exactly fixed your issue?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.