0

Currently I have VPN client access set up on OpenSuSE 13.1 server to third-party remote Cisco VPN IPSec server. VPN Server is set up to provide access for a host only and to provide access for a local network I set up iptables NAT with masquerading. Additionally I set up routing on other workstations to route traffic to remote subnet through server with NAT(iptabes).

Let the network map be:

Client alice(192.168.1.2) -- Gateway moon (192.168.1.1/10.0.0.2) | Remote host(10.0.0.3) -- Cisco (10.0.0.1)

Currently I was troubleshooting ssh authentcation failures using different methods and found out that instead of remote host sshd of Gateway responds.

I was listening to the traffic using wireshark and I see packets with correct ips, for example: 192.168.1.2 >> 10.0.0.3 10.0.0.3 >> 192.168.1.2

When I enter correct login/password for gateway when trying to ssh user@10.0.0.3, I enter gateway.

How this could be possible and why gateway answers as if it is host? How to fix this?

Ilya
  • 101
  • VPN is supposed to make it impossible for intermediate nodes (including the gateway) from hijacking connections. So unless the gateway was misconfigured with the IP address 10.0.0.3 on the LAN, what you see should not be possible. Moreover the ssh client was supposed to complain and refuse to login when it sees the wrong host key. Anyway once you are logged in, you can type `echo $SSH_CONNECTION`, the output of that command should give additional hints. – kasperd May 22 '14 at 11:23
  • @kasperd, After `ssh user@10.0.0.3` from 192.168.1.2 `echo` prints that connection is established with 192.168.1.1. Concerning the host key, I confirm that I receive key from gateway, but trying to find out what happens, I allowed to connect. Remote host does not receive any packets from this ssh login attempt, thus I believe it happens before VPN. – Ilya May 22 '14 at 11:53
  • What is the full output from `echo $SSH_CONNECTION`? – kasperd May 22 '14 at 13:09
  • @kasperd `192.168.1.2 49080 192.168.1.1 22`, I found which iptables(SuSEfirewall2) rule produced such case, but it is still unclear why sshd answered on another ip. – Ilya May 22 '14 at 13:26
  • The information you have given so far appears inconsistent. To me it sounds impossible that everything would be as you have described. You should go back and check the network traffic again to confirm that it really looks like you described in your question. Also provide a bit more information. Which interface did you capture those packets from, which protocol was it, which port numbers, which flags? – kasperd May 22 '14 at 14:42
  • @kasperd I did't find out why it happened but I could deretmine that was a result of specific SuSEfirewall2 masquerading setup, that was done through GUI. When I disabled it, gateway stopped to answer, but the question remained, how this could be possible. – Ilya May 22 '14 at 17:00

0 Answers0