no outbound traffic pool

[sbroulaye]

Hello, 

Kindly help me solve this issue please.

My pool member is not getting any outbound traffic. Inbound traffic is ok.

--Below the vs config 

ltm virtual VS_force {
destination xxxxxxxx:443
ip-protocol tcp
mask 255.255.255.255
pool POOL_force
profiles {
clientSSL {
context clientside
}
http { }
tcp { }
}
source 0.0.0.0/0
source-address-translation {
type automap
}
translate-address enabled
translate-port enabled
vs-index 87
}

--Below the pool config

ltm pool POOL_force {
members {
NOD_force {
address xxxxxx
session monitor-enabled
state up
}
}
monitor tcp
}

Thanks in advance.

[buulam]

Hey @sbroulaye , you're trying to configure the ability for your pool members to initiate traffic destined outbound?

[sbroulaye]

Hi @buulam, NO !

The problem is that when clients are web browsing to the VS, the page is showing ERR_CONNECTION_RESET

When I check the statistics of the pool, there is inbound hits but no oubound traffic (0)

Hope you understand, I'm new in BIG-IP management.

[Kevin_Stewart]

Let us analyze this from a traffic flow perspective. As a proxy, and in this configuration, the BIG-IP is going to both NAT and SNAT the traffic to the pool member. So let's use some comcrete examples:

• BIG-IP external self-IP: 188.188.1.1
• VIP address: 188.188.1.100
• BIG-IP internal self-IP: 192.168.1.1
• Pool member: 192.168.1.100

Traffic arriving at the BIG-IP VIP has the true client IP and a destination IP of 188.188.1.100 (the VIP). The VIP takes the traffic, decrypts, selects a pool member, NATs (changes the destination address to 192.168.1.100), and then SNATs (changes the source address to 192.168.1.1). So at the pool member, it sees a destination IP of itself, coming from the internal self-IP of the BIG-IP. If you tcpdump at that internal VLAN between the BIG-IP and the pool member, you should see exactly this:

tcpdump -lnni <internal vlan>

It would be useful to do this tcpdump to observe what's actually happening. You might see the client requests coming in, but maybe not going out? Or you might only see health monitor traffic? Either of these will increment the inbound traffic counters.

If you see client traffic coming in, but nothing coming back:

• Is it because the pool member is expecting TLS but you're not re-encrypting? In this case you might see a completed TCP 3-way handshake but then a RST directly after.
• Is it because the pool member is not correctly configured to respond? You could do a curl request from the BIG-IP shell to the server to see if it can respond.

[sbroulaye]

Thanks Kevin for this insightful explanation.

Please find in attachment the logs I collected from the tcpdump input you asked to do.

I would like to know why the pool member (172.17.31.254) is communicating both with the self ip (172.17.31.18) and the floating ip (172.17.31.16). Because our BIG-IPs are in HA active/active mode, so the traffic to the pool member is going through the floating ip.

Thanks in advance.

[Kevin_Stewart]

it's hard to say for sure, but since the .18 (presumably) monitor traffic is doing well, it would seem as if the server never completes the TCP 3WH for the .16 request. I also see two different ports (32255 and 32270). Are you certain the server can respond on that port, or isn't in any way configured to block .16? If this is a web app, can you curl to it from the BIG-IP?

curl -vk http://172.17.31.254:32255

[sbroulaye]

32270 is another service deployed on the same pool member; it has the same issue as 32255.

Yes the service works perfectly if we bypass the BIG-IP by directly accessing the pool member ip address.

It's a web app, kindly find in attachment the snapshot of the curl fom big-ip to pool member.

[Kevin_Stewart]

When you access directly are you using http or https?

Are you using a server SSL profile on the BIG-IP?

[sbroulaye]

We're accessing directly using http://172.17.31.254:32255/#/sessions

No server SSL profile configured in this specific VS, only client SSL profile.

[Kevin_Stewart]

You indicated earlier that you were testing curl with https. So then if you do this from the BIG-IP shell, you see a good HTTP response?

curl http://172.17.31.254:32255/#/sessions

If you do, this request would be coming from the self-IP (.18). Is the monitor showing good for the 32255 pool member? I'm assuming here that you're only using a tcp half-open monitor, which just checks to see if the server returns an ACK. So then if you switch to a full tcp monitor, does that still show green? And you have no rules on the server to block traffic from floating .16?

If you tcpdump on both on both BIG-IPs, do you see TCP handshake ACK traffic going to the other box?

[mihaic]

The self ip is used for monitoring . i see you use tcp mionitor.

The floating  ip should be used for the traffic between BIGIP and servers.