0

I'm trying to allow ssh access to a computer behind a firewall from a computer in another subnet. The computer behind the firewall is at 10.66.1.1/255.255.0.0, while the other computer is at 10.99.1.1/255.0.0.0.

I tried to add the following rule to iptables, but I still cannot access the firewalled computer.

iptables --append INPUT --match tcp --protocol tcp --src 10.99.1.1 --sport 22 --dst 10.66.1.1 --dport 22 --jump ACCEPT
1
  • 1
    That rule seems like it is close, but iptables rules are processed in order. It is impossible for us to know if it will work without knowing the rest of your rules. If this rule is added after an explicit drop, then it wouldn't do anything. Also, without more details about your network, I am not sure if you are going o the right chain. IE, are you sure you should be on INPUT and not forward? Please add more details.
    – Zoredache
    May 31, 2017 at 21:56

4 Answers 4

3

Remove --sport 22

The source port is random.

see explanation in: https://stackoverflow.com/questions/30616527/are-ssh-destination-and-source-ports-identical-symmetric-ports

2

Solution :

Delete the source port in your rule, you will have a rule like :

iptables -A INPUT -p tcp -s 10.99.1.1 -d 10.66.1.1 -m tcp --dport 22 -j ACCEPT

Explanations:

First we will assume that there is no routing problem but only firewall configuration.

The computer 10.99.1.1 (client) want to open a SSH session on the 10.66.1.1 (server).

The server must:

  • Have an operational & configured ssh server
  • Have its firewall open for SSH port (22 by default) :

iptables -A INPUT -p tcp -s 10.99.1.1 -m tcp --dport 22 -j ACCEPT

The intermediate firewall should have a iptable rule like :

iptables -A INPUT -p tcp -s 10.99.1.1 -d 10.66.1.1 -m tcp --dport 22 -j ACCEPT

The error you have committed is to specify the source port. Only the destination port on the server is required.

The client do not use the 22 port as source port for the SSH connection. The client ask the server for a new ssh session on the port 22 but use a local random port.

You can check that with the netstat -taupenl|grep ':22' , you should see at leat :

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          11242       540/sshd
tcp        0      0 ip.server:22        ip.client:35332    ESTABLISHED 0          570915      12917/0

The first line matche the listening port of the ssh server, the second line match the current ssh connection with the client you can see the used ports, 22 for the server, 35332 for the client.

[Client]:35332 <----> [Server]:22

As the client ports are used randomly depending on the availability on the client you should not specify the source port.

0

If the subnet masks are really like you describe in your post, especially 10.99.1.1/255.0.0.0, you cannot do anything with IPTables about this.

The subnet mask of 255.0.0.0 tells the computer that every IP address beginning with 10. is in the same L2 broadcast domain as the computer itself. This means that 10.99.1.1 will try to send all packets destined to 10.66.1.1 directly on the same network, without trying any routing.

Meanwhile, since 10.66.1.1 has netmask 255.255.0.0, the packets from that computer will be routed to 10.99.1.1.

You need to fix your routing first.

2
  • so if I change the subnet masks to both be 255.255.0.0, would iptables be able to do the routing?
    – waspinator
    Jun 9, 2017 at 17:34
  • IPTables does not do routing, Linux kernel does routing. Changing subnet mask fixes that part, but then there can be other issues in your setup. Jun 9, 2017 at 20:11
0

You have to define the mask bits:

iptables --append INPUT --match tcp --protocol tcp --src 10.99.1.0/8 --dport 22 --jump ACCEPT

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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