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: connectionestablished, can act for a short amount of time then the terminalfreezes and times out. On wireshark I have some TCP retransmissionsat this timessh from the admin network directly: Everything worksssh from a computer with both network: Everything worksssh from a 3rd network (with rule to forbid access to the user network): Everything worksBoth interfaces up, ListenAddress disabled :Everything works, but of course ssh is available through the usernetwork interfaceInterface eth0 down, ListenAddress enabled:Everything worksThere 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.
SSH connection timeout after a couple of seconds when my second interface is up
ssh;networking;pfsense
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.