Hello gents ,
i have deploymetnt as following :
client > FW > F5 > [Node 1 and Node 2] >F5 > FW > Srv
both F5 are the gateways of the two nodes .
f5 configured with performance l4 to match all traffic passing from client to server .
everything work properly . but the case as following :
the nodes act as inspection devices which is not support ssh traffic and they need to modify the port on f5 and forward the trffic to them with another port
for example client connect 18.104.22.168:22 > vs
req 22.214.171.124:22022 for example .
is there suggesstion or i rule can do it .
@Mustafa_elAbd Can you please confirm the following?
1. Virtual server is 126.96.36.199:22?
2. What are the pool members for the VS in number 1?
Once we have that information we should be able to resolve this. At face value without those questions being answered I would say the pool associated to the VS should have pool members listening on <server_IP>:<server_port> which should look something like 10.10.10.10:22 and 10.10.10.11:22 if you had two pool members so you can simply change the pool member port to be 22022 and the F5 will balance the received port 22 traffic to port 22022 on the pool members without any iRule.
thaks for your reply .
the virtual serer is 0.0.0.0/0 and also the pool match on all port .
the problem here is that the pool member devices can't inspect the ssh traffic and need it to be changed so not drop it .
@Mustafa_elAbd If you can please share your configuration for the VS and the associated pool that would be helpful because typically you do not configure a catchall VS and associate a pool to it. In almost every case the catchall is used to pass routed traffic from one side of the F5 to the other with minimal manipulation. If you have a pool associated to it this becomes a bit more difficult to modify on the F5. The easiest thing you can do will most likely be to create a PAT on the firewall that maps port 22 on the mapped (what everyone else sees) to 22022 on the real side (what your servers are actually listening on) but this still isn't the ideal way of handling this. Typically security by obscurity isn't a great solution for security but instead you leave it as port 22 and then lock down that port as much as possible via firewall, IPS, and server security configuration.