1

So I'm so lost on what to do to debug right now. I've spent a couple of weeks on this issue without understanding what is happening.

I'm trying to have the ssh server to only work with connections from the admin subnet but this shouldn't stop routed traffic from any subnet to the admin subnet.

So here is the setup. I have a VM under debian 9. This VM has two interfaces, eth0 in on the user subnet and eth1 is on the admin subnet. Both subnets have a DHCP/DNS server which is pfsense. Hostnames are automatically added to the DNS.

My sshd config file is the default on, with root login disabled and ListenAddress set to eth1 IP.

So far this is the behavior that I have seen:

Both interface up, ListenAddress enabled:

  • ssh from the user network through the pfsense router: connection established, can act for a short amount of time then the terminal freezes and times out. On wireshark I have some TCP retransmissions at this time
  • ssh from the admin network directly: Everything works
  • ssh from a computer with both network: Everything works
  • ssh from a 3rd network (with rule to forbid access to the user network): Everything works

Both interfaces up, ListenAddress disabled :

  • Everything works, but of course ssh is available through the user network interface

Interface eth0 down, ListenAddress enabled:

  • Everything works

There isn't any firewall on the server on purpose. I use the IP address to ssh and not the hostname, but both have the same result no matter if both interfaces have the same or a different hostname.

I really don't know where the issue is coming from. For me it can't be the pfsense because right now it simply allows all network traffic from the user network to go to the admin network. But maybe i'm wrong. And no error in the sshd logs either.

closed as unclear what you're asking by Scott, Rui F Ribeiro, Stephen Rauch, Romeo Ninov, Anthon Aug 14 '17 at 10:41

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Your question does not really explain what your problem is. Are you trying to forbid ssh connections from the user network? Please explain what you are trying to achieve, and how it is not working. – Johan Myréen Aug 13 '17 at 18:17
  • 1
    @Johan-Myréen i'm just trying to ssh into my server. but the connection drop out when my client can access the 2 interface of the server and i don't know why – Vlycop Doo Aug 13 '17 at 18:23
  • @JohanMyréen You don't even have to read the question; even the title does explain that... – Hauke Laging Aug 13 '17 at 18:25
  • 1
    @VlycopDoo Still unclear to me. You say you can ssh the server from the admin network, "Everything work". So what is the problem? Is it that you get a "connection established" from the user network, even though you shouldn't? – Johan Myréen Aug 13 '17 at 18:36
  • @JohanMyréen no i should be abble to connect because i my network stream is rerouted into the admin network. the issue is that the terminal froze and time out for no apparent reason – Vlycop Doo Aug 13 '17 at 18:40
3

Your problem is that the TCP packets sent by your server use another path than the TCP packets you send to it, and your pfsense then thinks the connection is not established and removes it from its table of established connections, subsequently rejecting any incoming packets.

The TCP packets that go from your machine on the user network to your server are sent to the pfsense router which forwards them to your ssh server. Since your ssh server has an interface on your user network, the return packets are sent directly to your machine through its interface on the user network. Consequently, pfsense only sees the packets going from your machine to the server, and since the first TCP SYN frames have not been ACKnowledged, it then decides that the connection is dead after some time and drops subsequent packets.

A quick workaround on the pfsense would be to SNAT the ssh packets going from the user network to the admin network. Thus the ssh server would use the pfsense for its return path. The ssh server would then be unable to know the actual source address of course.

A better approach is to use source based routing. See this question for example.

  • Sounds good but as I understand it both interfaces are connected to the router and the source address of the reply packets should be the same as the target address. – Hauke Laging Aug 13 '17 at 19:14
  • @HaukeLaging I believe it is the same actually. That's just that the packets use the shortest path, which is the interface to the user network. – xhienne Aug 13 '17 at 19:18
  • Wow. That good thinking. i will check if it's really that in a moment, but i'm a bit shook that the packet don't follow the same root as the incoming one. – Vlycop Doo Aug 13 '17 at 19:35
  • @xhienne i can confirm with a tcpdump -i any that the server ack the syn but because it simply use the ip, the shorts route is through the eth0 ... i will have to search how to fix that without nating, because i will have issue with other stuff i'm sure – Vlycop Doo Aug 13 '17 at 20:53
  • 1
    @VlycopDoo Do not worry about this. This site is open to everyone but English is a prerequisite, that's why we don't expect every question to be written in perfect English. – xhienne Aug 13 '17 at 21:23

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