PeraHoman
asked on
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?
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?
ASKER
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)
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)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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?
With that said, can you ping the clock from the switch?
ASKER
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.
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.
ASKER
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?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
Hi Author,
Could you share what exactly fixed your issue?
Could you share what exactly fixed your issue?
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