SSH client from static source port?

Ok I need some help with this.

I am trying to get an SSH server running on my box from behind a NAT firewall. So far I have been able to successfully test it on loopback. So I know the server is working. I can also see incoming packets to the server if I connect with my external address.

The problem is that the SSH client uses a dynamic, registered source port. So when my SSH server sends a SYN,ACK packet back to the SSH client I am running, it is sending it to the same a registered port, which the NAT firewall is not forwarding to my computer. I could set the firewall up to forward these ports, but the source port that the SSH client uses changes every time you run it.

So what I am looking for is a method to tell the SSH client exactly which source port I want to initiate the connection from so I can set the firewall up to forward it.

I am running openssh 3.7 on Slackware 9.1, kernel version 2.4.22.

Any ideas?

All you need to do is setup your firewall to port forward port 22 to your server.

Port 22 is forwarded.

However, as I explained, the SSH client uses a dynamic source port. So when the server sends SYN,ACK packets back to the client via my external address on some port like 33367, the firewall drops them since no rule is configured to forward those.

The SYN packets are forwarded quite properly, so I know the client can send them to the server. However, the server cannot send packets back to the client because the client is listening on 33367, or something like that.

The firewall cannot forward these packets, since no rule is set up to do it. The problem is that the port that the client listens on changes evey time it runs.

Do you absolutly have to stay behind the firewall?
You can create a DMZ and trust on your pc's firewall.

Yes, unfortunately I need the NAT to share Internet with my roommate, at least if I want him to foot half the bill for it. It's not the firewall that's dropping the packets, it's the NAT server that does that.

I think I should be able to connect to the SSH server from outside my network, since the server itself is running fine. I just need to figure out how to do this for local testing.

Imagine a firewall rule like this:

Allow inbound any source port (from 1024 to 65535) to ssh, using NEW, ESTABLISHED or RELATED, tcp protocol
Allow outbound source port 22 to any destination port, using ESTABLISHED or RELATED, tcp protocol

You should be able to do this using appropriate port forwarding.

The firewall is currently set to let everything through and log it, so I know it's not a firewall problem. It's a NAT problem. I sense that people aren't understanding the problem correctly, so I'll attach a capture file to this post.

Take a close look at frames 9 and 12, which are sent to my router with SYN and ACK flags set, to port 36474. This is in response to a previous SYN packet, which was successfully forwarded from the router to the server on port 22 from port 36474. When the server sends the SYN,ACK response back to port 36474, the NAT server doesn't know what to do with the packet and drops it. The firewall lets it through.

I could set the NAT server up to forward packets on port 36474, and that would work. But next time I run the SSH client the source port will change and the SSH server will be sending packets to another port, which the NAT server is not configured to forward. I need to set the SSH client to use a static source port.

Sigh. The NAT should be configured to look after establishing connections. What are you using for the NAT itself? What about setting up NAT to forward packets that are related to connections that are being established or that are established? And can you setup your nat so that any source port to port 22 is acceptable and the reverse?

MsMittens is right. If your router/firewall uses statefull inspection you shouldn't have to worry about the return connections. It'll all be taken care of by the firewall/nat engine.

On my FBSD+IPF firewall I use these rules:

/etc/ipnat.rules:

rdr on ng0 from any to 0.0.0.0/32 port 22 -> 192.168.1.22 port 22

/etc/ipf.rules:

pass in on ng0 from any to 192.168.1.22 port 22 flags S/SA keep state


* Note the keep state at the end of my rule. This will make it possible for the ssh server to respond without blowing a huge hole in my firewall.

I run a ssh server behind a NAT router (using Linux ipchains on Freesco).

I can assure you that the source port used on a TCP server connection is always the same port as the client connected to. It never comes from a different port.

A correctly configured dynamic NAT box will know this, and translate the port numbers correctly. I have been using a similar configuration successfully (under IP Masquerading on Linux 1.3 initially) since before 1997.

This is not a problem specific to ssh - ssh does not behave in a way different from anything else. It is your router's NAT rule configured incorrectly.

Setting your ssh client to use a static source port is not the answer - just get your NAT to work correctly.

Slarty

your setup is probably the confusing part here.

it appears you have INTERNET->FIREWALL->NAT DEVICE->LAN

if this is the case, as long as you follow msmittens firewall rules, and your nat device is an actual nat devices, not a masq device.. it should be working fine.

Unless however, you are trying to test the internet availability of your ssh server by sshing to your public ip from your LAN.. which will cause confusion and stop the connection from starting..

Again, you havn't stated your actual layout so ALLL of this is speculation. Tell us how your network is layed out and you'll probably get better answers.

question.. what the hell makes you think that you want a static source port for ssh? Do you realize the potential pitfalls that will cause for other applications that use dynamic source ports? I assure you is quite normal to use dynamic source ports.
The answer which has been stated twice already is this: forward ssh to your ssh server, and keep state on the pass rule. If your firewall does not do stateful inspection, or does not maintain state, open the port blindly and use tcpwrappers or something in /etc/ssh/sshd_config to restrict access.
Passing flags S/SA will allow the SYN packet to get through and keeping state on the connection will allow the sshd to respond to the clients request and let the connection continue..until said connection is established..and it will keep the session alive until it expires or the connection is closed. The rest should be transparent.

**cleanse senior member gene pool**
-hog

Quote:

---

Unless however, you are trying to test the internet availability of your ssh server by sshing to your public ip from your LAN.

---

Exactly.

Currently, when I test this, the firewall is disabled to keep things simple. So what I have is

INTERNET --> NAT DEVICE --> LAN
No firewall.

Yes, I am tring to ssh to my public IP from my LAN, and I believe this is what is causing the problem. I can ssh from within my LAN quite easily, even with the firewall up. I only need to do this temporarily to test the ssh server via my public address from behind the NAT.