0

I'm on my workstation at home. I've connected to the VPN for my company. I ran a dig on "server01.test.int" and it gives me the address 10.0.1.15. I ran a dig on "server02.test.int" and it gives me the address 172.16.20.30. From my workstation, I can telnet to both of those servers on port 22 and get the response from ssh. I don't have ssh creds for either server. I would like to confirm I can connect to 172.16.20.30:22 from 10.0.1.15, and vice-versa. I know these are different private networks, but there might be routes in place to allow these servers to reach each other. Is this doable if I can't log in to either server and try opening a connection directly? Can it be done indirectly from my workstation?

(Related question: how am I able to reach both subnets from my VPN?)

Thanks!

Improve this question
6
  • 1
    Since this is your company network, you should ask your network administrators.
    – Ron Trunk
    Oct 23, 2015 at 17:35
  • Ok, but this is an example. I don't actually have a company, I just want to learn the answer to my question.
    – cat pants
    Oct 23, 2015 at 20:01
  • Out of curiosity, where did you come across this scenario for which you want to learn from?
    – Eddie
    Oct 23, 2015 at 23:31
  • It is not a cop out since one of the specifically off-topics is end-users of corporate networks. If you are not an end-user of the network, but a network admin, you would know the answer to your hypothetical question. The answer is to ask an administrator of the network if it isn't you, and, if it is you, then you should know the answer.
    – Ron Maupin ♦
    Oct 26, 2015 at 20:23
  • If you feel your post has been closed incorrectly or that a topic should not be considered off topic, the best place to address this question is Network Engineering Meta.
    – YLearn
    Oct 27, 2015 at 0:53

2 Answers 2

Reset to default
1

You would like to confirm If you can connect to 172.16.20.30:22 from 10.0.1.15, and vice-versa?

ANS: We can use IP spoofing technique to identify that.

Is this doable if I can't log in to either server and try opening a connection directly?

ANS: Yes this is doable if you have ASA firewall in between these two servers but if meets below condition

  1. ASA should be running with IOS 9.X

  2. Packets between these severs should only go through this firewall and servers should not communicate directly.If above conditions are met, we can use ping tcp command to confirm this, the actual command would be,

ping tcp 172.16.20.30 22 source 10.0.1.15 5678

ping tcp 10.0.1.15 22 source 172.16.20.30 7885

You will get "!" If port 22 is open between these two IP's

Can it be done indirectly from my workstation?

Yes, there is one old logic of IP spoofing to identify this but not sure about its success percentage.. This technique is doable only if there shouldn't be any traffic to these servers from any other IP's apart from your workstation..

This could be identified by obseving IP Identification field in IP header..

(Identification(16 bits): This field is used for uniquely identifying the IP datagrams. This value is incremented every-time an IP datagram is sent from source to the destination. This field comes in handy while reassembly of fragmented IP data grams.)

Here is how,

  1. You have to send TCP SYN packet to 172.16.20.30(host A) in port 22 with spoofed source IP as 10.0.1.15(host B) from your workstation. Of course as you know, the reply from B will be to A but not to your workstation.

  2. IPID is the the unique identification number of IP packet and that will get increment to each packet.

  3. The reply from A to your SYN packet would be as below,

    • A reply SYN/ACK to SYN if tcp 22 port is open, reply RST/ACK if tcp 22 port is closed. This packet will reach B if routes are present as you mentioned
    • You can know the number of packets that hosts are sending using IP ID in header field.
    • B reply RST to SYN|ACK, reply nothing to RST/ACK.

  4. Flow will be as below

    • You send SYN packet to Host B in port 22 with your original workstation IP as source. You will get SYN/ACK from B with IP ID as 1(for example)

    • You send SYN packet to host A with spoofed Host B IP as source in port 22 from your workstation.

    • If port 22 is open at Host A for Host B, A replies with SYN/ACK to B.

    • Then B replies to A with RST and IP ID as 2, since B didn't sent TCP SYN originally to have TCP session (originally you sent it from your workstation which both parties dont know about it).

    • After few sec you send one more SYN to B then you will get SYN/ACK from B with IP ID as 3. (So there is one more addional increment comparing the previous reply from B)

This confirm that you can connect to A from B in port 22.

If port 22 is closed at A for B, then the flow will be as below

  • You send SYN packet to Host B in port 22 with your original workstation IP as source. You will get SYN/ACK from B with IP ID as 1(for example)

  • You send SYN packet to host A with spoofed Host B IP as source in port 22 from your workstation.

  • If port 22 is closed at Host A for Host B, A replies with RST/ACK to B.

  • Then B discards the RST from A, wont send any reply to A.

  • After few sec you send one more SYN to B then you will get SYN/ACK from B with IP ID as 2.

This confirms that you cannot connect to Host A from Host B in port 22.

Improve this answer
5
  • Since the OP is asking this as an end user, they won't have access to network devices including the firewall on which you based your answer.
    – YLearn
    Oct 27, 2015 at 0:59
  • @YLearn Please refer my answer to his question - Can it be done indirectly from my workstation? (3rd, answer)
    – G K
    Oct 27, 2015 at 3:09
  • The OP is a VPN end user and has no login on either server. Your spoofed packet from workstation to A will cause A to reply to B. The workstation won't see this return traffic, so the OP would need access to something in the network infrastructure or one of the two servers to see if this occurs. That is all without considering that any network configured reasonably securely would drop traffic from workstation with an "invalid" source IP address.
    – YLearn
    Oct 27, 2015 at 3:37
  • The logic is not based on return packet... it is based on observing IPID and I mentioned certain limitations.. This is just one way to identify if the scenario meets those limitations... Please considering refering my answer again for better understanding..
    – G K
    Oct 27, 2015 at 18:19
  • Could we define "certain limitations"? Let's start with a network with weak security. Then add in an ancient server (at least prior to Windows Server 2003 or Linux kernel 2.2). Throw in that nothing else can be communicating with said servers (or they with something else). Also, make sure there is no device that is doing IP header rewrites along the path (NAT, load balancing, etc). Sounds like "certain limitations" means "a real long shot" unless you have access to those return packets and as such doesn't really add much value to the discussion.
    – YLearn
    Oct 28, 2015 at 2:12
3

I'll answer the second question first: When you use a VPN, you can get to all the networks your administrator has granted you access to.

If you have no information on the topology or policies of your network, then you don't have enough information to determine if the servers can talk to each other or not. If you want to know, you would naturally ask your network administrator.

If you can't get the information you need, it's probably because the administrator doesn't think you need to know it.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.