Hello,
I am having the following topology (both networks are /24):
<sorry, I got formatting problems to show the topology correctly>
<I included the pictures as attachment>
In one scenario, the client (192.168.101.40) sends HTTP traffic towards the load-balancer (192.168.101.30).
The load-balancer forwards it (via 192.168.105.30) to any of the backend-servers (192.168.105.21 / 192.168.105.22).
At the servers is a route specified for return-traffic:
server-1: 192.168.101.40 via 192.168.105.30 dev eth0 src 192.168.105.21
server-2: 192.168.101.40 via 192.168.105.30 dev eth0 src 192.168.105.22
Subsequently the load balancer sends the return-traffic back to the client, with 192.168.101.30 as source address.
So far, so good ....
But .... for administration purposes, the client shall also be able to login directly to the servers, using SSH:
<sorry, I got formatting problems to show the topology correctly>
<I included the pictures as attachment>
Here, the problem arises that return SSH-traffic is also routed back via to the load-balancer due to these routes:
server-1: 192.168.101.40 via 192.168.105.30 dev eth0 src 192.168.105.21
server-2: 192.168.101.40 via 192.168.105.30 dev eth0 src 192.168.105.22
After some Googling I figured out that policy based routing / port based routing might tackle this issue.
The general idea would be to 'filter' SSH-traffic (originating from port 22) destined for host 192.168.101.40/32 and use the route:
192.168.101.40 dev eth1
I followed the steps from this page:
https://www.sparksupport.com/blog/20...based-routing/
Based on that description I did the following at server-1 (Linux RHEL 7.3):
echo "100 sshtable" >> /etc/iproute2/rt_tables
ip route add 192.168.101.40 dev eth1 table sshtable
ip rule add fwmark 0x22 lookup sshtable
This last command results in the following:
ip rule list
32000: from all lookup local
32765: from all fwmark 0x22 lookup sshtable
32766: from all lookup main
32767: from all lookup default
Now, the parts comes where I have my doubts: adding a rule in iptables.
Since in my case it is concerns return SSH-traffic, I assume it shall not be identical to as is described in the above link:
iptables -t mangle -A OUTPUT -p tcp –dport 22 -j MARK –set-mark 0x22
I supposed in my case the filter shall be on the source-port (22).
Besides, to ensure that the route is only applied for the client, also the destination needs to be set.
iptables -t mangle -A <CHAIN> --destination 192.168.101.40/32 --protocol tcp --sport 22 -j MARK --set-mark 0x22
I have tried the command with the following chains, but without any luck:
PREROUTING
INPUT
FORWARD
OUTPUT
POSTROUTING
If I login with SSH from the client (192.168.101.40) towards server-1 (192.168.101.21), I get a hanging session, with eventually the response:
ssh: connect to host 192.168.101.21 port 22: No route to host
iptables -t mangle -L -v -n ,shows no packet-increase for MARK 0x22 for any of the chains.
If I remove the route (192.168.101.40 via 192.168.105.30 dev eth0 src 192.168.105.21) from server-1:
Then packet-increase is observed for OUTPUT and POSTROUTING, but the SSH connection times out:
ssh: connect to host 192.168.101.21 port 22: Connection timed out
So, it seems that, if I have defined the route (192.168.101.40 via 192.168.105.30 dev eth0 src 192.168.105.21) then packets destined for 192.168.101.40, with source port 22 is not hit.
Where do I go wrong?