LTM Policy Port redirect

[Kalido]

Hi Guy's

I currently have a VS listening on 443, all our backend servers work on 443.

We have a new requirement where we have a backend server already operating on 443 so we need to use a different port.

So the backend server is:

Test.com:8443/xyz

I need to browse to:

Production.com/xyz

I need to connect externally to the F5 on port 443 and I need the policy to forward the connection to the backend server using 8443.

I have the URI rewrite configured already.

Please see my policy rule:

I get connection reset every time I browse to the url

[Paulius]

@Kalido To make sure I understand the request. You have a virtual server (VS) with lets say IP 10.10.10.10 and listening on port 443 performing SSL termination with a client SSL profile. You also have a pool associated to this VS and it has pool memebers lets say 10.10.11.20:443 and 10.10.11.21:443 and the VS has a server SSL profile to encrypt the traffic and send it to those pool members. Now you would like requests for URI path /xyz to go only to a 10.10.11.21 but on port 8443 instead of 443 which it is already listening on? If that is the case I would create another pool with a name that makes sense to you with the pool member 10.10.11.21:8443 and then choose the "Forward Traffic" to be pool and select the new pool that you created for this purpose. I would like to note that you must have both client and server SSL profiles configured under the VS and an HTTP profile in order for this to work. If you do not have those three pieces configured this will not work.

[Kalido]

Hi Paulius,

You have it 90%.

So I don't use pool's I use LTM policy to forward traffic depending on a specific URI in the URL.

For example:

/abc/ -> forward to node 10.10.11.20

/def/ -> forward to node 10.10.11.21

Etc.

This server is running something on 443 already as you mentioned so the new application will need to run on 8443.

So as you can see from my ltm policy above, I have told it when a external user connects to the VS on 443 as they should the F5 to the backend should be 8443.

However I just get connection reset, I am not 100% sure what you mean by client and server SSL profile, I believe I have that setup correctly because for 443 the SSL works fine. 

Not sure I have a HTTP profile configured, what would this do for this situation ?

[Paulius]

@Kalido Understood on your configuration setup. I would recommend moving away from sending traffic to a specific node because this messes with any persistence that you might want to configure. You really should have a pool configured for each path that you are going to balance traffic for and use the forward to pool option instead. Using pools will ensure that persistence functions as expected, allows you to add additional members for a specific URI path or Host field without much of a change to the virtual server, and finally this allows you to run health monitors at a level that doesn't effect the entire node if by chance this node is working for one URI path or Host field but not others.

In regards to client and server SSL profile, this configuration can be found under the VS with labels SSL Profile (Client) and the other as SSL Profile (Server). For the HTTP profile you can also see that under the virtual server and the configuration box says HTTP Profile next to it. Based on your previous statment you would have to have 1 or both SSL profiles and an HTTP profile configured already for it to be working for other URI paths so probably something you don't have to worry about but you can verify what is configured.

Now in regards to 8443 if you run the following tcpdump you should be able to see if the F5 is issuing the reset or if it's the server. Most likely based on your description it is the server issuing the reset which typically means the server is either blocking because of a local OS firewall rule, the server isn't listening on 8443, or the server isn't expecting HTTPS traffic on port 8443. By "<f5_selfIP_closest to serverIP>" this would be the interface the traffic leaves the F5 on when attempting to reach the destination node. Replace the entirety of the pieces below from < to > for the appropriate IP.

tcpdump -nni 0.0:nnp host <f5_selfIP_closest to serverIP> and host <nodeIP> and port 8443

The following is an example of what the command would look like if the selfIP of the F5 was 10.10.10.1 and the destination node IP is 10.10.20.30.

tcpdump -nni 0.0:nnp host 10.10.10.1 and host 10.10.20.30 and port 8443

Hopefully this all makes sense and helps you resolve the issue at hand.

[Kalido]

I can also see that traffic is getting to the backend server, I can see packets in but I can't see packets out:

So the inital connection is getting there, what would your thought be regarding this situation?

[Kalido]

Sorry for my stupidity, I managed to get it working.

I got the following:

tcpdump -nni 0.0:nnp host 10.205.1.106 and host 10.110.64.155 and port 8443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 0.0:nnp, link-type EN10MB (Ethernet), capture size 65535 bytes
16:25:30.986824 IP 10.205.1.106.55733 > 10.110.64.155.8443: Flags [S], seq 3607107882, win 4140, options [mss 1380,sackOK,eol], length 0 out slot1/tmm0 lis=/Common/VS-AZURE1-TT port=1.2 trunk= flowtype=128 flowid=400001593C00 peerid=400001593B00 conflags=4000024 inslot=63 inport=23 haunit=1 priority=3
16:25:33.986178 IP 10.205.1.106.55733 > 10.110.64.155.8443: Flags [S], seq 3607107882, win 4140, options [mss 1380,sackOK,eol], length 0 out slot1/tmm0 lis=/Common/VS-AZURE1-TT port=1.2 trunk= flowtype=128 flowid=400001593C00 peerid=400001593B00 conflags=4000024 inslot=63 inport=23 haunit=1 priority=3
16:25:36.986029 IP 10.205.1.106.55733 > 10.110.64.155.8443: Flags [S], seq 3607107882, win 4140, options [mss 1380,sackOK,eol], length 0 out slot1/tmm0 lis=/Common/VS-AZURE1-TT port=1.2 trunk= flowtype=128 flowid=400001593C00 peerid=400001593B00 conflags=4000024 inslot=63 inport=23 haunit=1 priority=3
16:25:39.985971 IP 10.205.1.106.55733 > 10.110.64.155.8443: Flags [S], seq 3607107882, win 4140, options [mss 1380,sackOK,eol], length 0 out slot1/tmm0 lis=/Common/VS-AZURE1-TT port=1.2 trunk= flowtype=128 flowid=400001593C00 peerid=400001593B00 conflags=4000024 inslot=63 inport=23 haunit=1 priority=3
16:25:42.986437 IP 10.205.1.106.55733 > 10.110.64.155.8443: Flags [R.], seq 3607107883, ack 0, win 0, length 0 out slot1/tmm0 lis=/Common/VS-AZURE1-TT port=1.2 trunk= flowtype=128 flowid=400001593C00 peerid=0 conflags=4800024 inslot=63 inport=23 haunit=1 priority=3 rst_cause="[0x2f12c21:14654] TCP retransmit timeout"
16:25:42.986521 IP 10.205.1.113.443 > 10.110.2.13.55733: Flags [R.], seq 2881807635, ack 2784234891, win 0, length 0 out slot1/tmm0 lis=/Common/VS-AZURE1-TT port=1.2 trunk= flowtype=64 flowid=400001593B00 peerid=0 conflags=4800024 inslot=63 inport=23 haunit=1 priority=3 rst_cause="[0x2f12c21:14654] {peer} TCP retransmit timeout"

Does anything here scream where the issue is here?

[Paulius]

@Kalido First I'm glad you got it work. What was the issue. To me it looks like the F5 is sending the standard amount of SYN requests with no response from the destination server on 8443 and because it doesn't receive a response the F5 sends a reset and then sends to the client who made the initial request on 443. Based on this information it could be one or more of the following.

1. Routing to the destination is not in place.
2. You are not allowing the connection from the F5 to reach the destination device either on a firewall or the servers OS firewall.
3. The server is not listening on 8443.

[Kalido]

@Paulius 

Firstly thank you very much for your repsonses and help on this :D.

So I believe the routing is fine as I can telnet to the backend server on port 8443.

telnet 10.110.64.155 8443
Trying 10.110.64.155...
Connected to 10.110.64.155.
Escape character is '^]'.

So you believe it could be the server dropping the connection? 

The above telnet proves that connectivity and routing to the device is configured correctly and there is a permit on the firewall that allows it.

That also confirms that the server is listening on port 8443, I've hit a stumbling block.

I am not sure, I tried to recopy the syntax you provided and modified it on the F5, must of left an extra space somewhere 😄

[Paulius]

@Kalido Try the following to see if it possibly copies differently from the previous post. I also believe this includes the IP in question.

tcpdump -nni 0.0:nnp host <client_IP>

If this errors for you please provide the error so that we can try to resolve that for you. Now if the server accepts a telnet from the F5 to the server on 8443 you know that the F5 can at least reach it. What is the connection flow if you don't mind providing that? Based on the previous tcpdump it seems to be coming in on the same interface that it's leaving which would require SNAT to be configured. I would assume you have SNAT configure already because this is working on 443. You might consider running a capture on the destination server as well on port 8443 to see if the server ever receives the request. Without having a large piece of your F5s configuration it makes it a bit difficult to troubleshoot this much further.