Forum Discussion
NimbostratusTCP Connection Failed After Adding New Members
TCP Connection Failed After Adding New Members. We have an HTTPS VIP that targets a pool. The VIP is open to the internet and the SSL cert is on the LTM. Formerly the pool had 2 members within the same compartment as the LTM. We recently added 2 new members to the pool. The new members are actually in a different compartment. The traffic has to go out our compartment's firewall and into the other compartment's firewall. (The other compartment is physically located just across the hall.) When we have these two new members activated, our monitoring tools are reporting "TCP connection failed" errors on 5 to 10% of the connections. We also received at least one complaint from customers about receiving intermittent connection errors. As soon as we deactivate the new members, the TCP issues go away. I am thinking we need to tweak the tcp profile but I am open to any suggestions. We are currently using the default tcp profile. The LTM is currently running 11.4.1 hf8. Thanks!
5 Replies
Vijay_ECirrus
What is the latency between F5 and the old/new pool members ? Normally, you can use WAN profile for the client side and LAN profile for the server side. If the latency is too high, you can try and use the WAN profile on both client and server side as a check.
If you disable the old pool members, are all connections successful ? I am wondering if your network set up may require SNAT by any chance.
wlopez_98779If I understand correctly, you have a virtual server with a client ssl profile (ssl cert on the F5) with a pool including 2 pool members on a separate vlan that's directly connected to the F5, but different the virtual server's vlan. Traffic flows from the internet to the ssl virtual server who then distributes traffic between the two servers on the vlan behind the F5. If you add servers to the pool that are not on a directly connected vlan behind the F5 with a return route through the F5's floating IP, you will have several situations, the main one being asymmetric routing. If that is the case you will probably need to do several things. The first one can be to activate SNAT Automap. This will require you to allow access through your firewalls from the F5's egress floating IP address to the pool members. This will also change the source IP address you'll see on your pool members from the client's IP address to the egress floating IP addresses of the F5s.
By asymmetric routing I mean the following: Client connects to the F5's virtual and establishes an ssl session F5 forwards traffic to selected pool member leaving the client's source address intact Pool member on the new separate vlan receives the request from the client and sends response back directly to client Client gets an error as it gets a response that's not encrypted and from a different IP address he sent the request to
For the connections to work correctly the requests and responses need to flow through the F5's ssl virtual server.
Polarglock_3568Thanks for the reply! Yes, you are correct about the flow. The two new members in the other compartment do get SNATed. The old members in the same compartment do not. We do get successful traffic to all 4 members however it appears to be an intermittent issue occurring only when the new members have been activated. We don't see the failures within our environment. We only see the failures coming from the Alertsite monitors with agents external to our environment. We also received complaints from clients.
Thanks!
wlopezCirrocumulus
If I understand correctly, you have a virtual server with a client ssl profile (ssl cert on the F5) with a pool including 2 pool members on a separate vlan that's directly connected to the F5, but different the virtual server's vlan. Traffic flows from the internet to the ssl virtual server who then distributes traffic between the two servers on the vlan behind the F5. If you add servers to the pool that are not on a directly connected vlan behind the F5 with a return route through the F5's floating IP, you will have several situations, the main one being asymmetric routing. If that is the case you will probably need to do several things. The first one can be to activate SNAT Automap. This will require you to allow access through your firewalls from the F5's egress floating IP address to the pool members. This will also change the source IP address you'll see on your pool members from the client's IP address to the egress floating IP addresses of the F5s.
By asymmetric routing I mean the following: Client connects to the F5's virtual and establishes an ssl session F5 forwards traffic to selected pool member leaving the client's source address intact Pool member on the new separate vlan receives the request from the client and sends response back directly to client Client gets an error as it gets a response that's not encrypted and from a different IP address he sent the request to
For the connections to work correctly the requests and responses need to flow through the F5's ssl virtual server.
- Polarglock_3568
Thanks for the reply! Yes, you are correct about the flow. The two new members in the other compartment do get SNATed. The old members in the same compartment do not. We do get successful traffic to all 4 members however it appears to be an intermittent issue occurring only when the new members have been activated. We don't see the failures within our environment. We only see the failures coming from the Alertsite monitors with agents external to our environment. We also received complaints from clients.
Thanks!
