Forum Discussion
fluzocapacitor
Altocumulus
AltocumulusIssue with Capturing SYN-ACK Packets on F5 BigIP Virtual Server
Hello everyone,
I have a virtual server set up on an F5 BigIP. I captured traffic on a client (IP: 10.16.x.x) of the balanced service and on the virtual server itself (IP: 10.16.y.y). On the client capture, I can see that it sends the SYN packet to establish the connection and receives the SYN-ACK packet from the server. However, in the capture from the server, I do not see the SYN-ACK packet.
I am trying to understand why the SYN-ACK packet does not appear in the server capture and if the command I used to capture the traffic was incorrect. Here is the command I used:
/usr/sbin/tcpdump -s0 -ni any:nnn -w /var/tmp/proxy80.pcap host 10.16.y.y and host 10.16.x.x
Syncookie was enabled on the server and it sent a RST to the client. Anyway, I wonder why there is no SYN-ACK packet despite the fact that the client received it.
Could someone please help me understand what might be going wrong or suggest the correct way to capture this traffic?
Thank you!
wendelyesAltostratus
Hello,
The traffic in the packet captures could be hidden if it is offloaded. This use to happen in fastL4 virtual servers and you can disable it by changing to Standard modifying the fasL4 profile.
Anyway, in this case I would bet that the SYN-ACK is goign through other device and the F5 is not seeing it. The F5 is forwarding the SYN packet and blocking the other traffic coming from the client because the session is not established yet. The reset you have at the end is created by the f5 because the session could not be established.
I think the best way to know where this SYN-ACK is going through is to capture the traffic in the client and check the source mac. This way you can probably check who is sending it.
Regards
- zamroni777
Nacreous
f5 bigip is basically proxy.
client side and server side are handled separately.
you probably has oneconnect enabled so bigip may reuse a server side tcp connection for multiple client sessions
fluzocapacitorThank you for your response.
I understand that F5 BigIP acts as a proxy, handling client-side and server-side connections separately. However, my concern is that, even with this behavior, the F5 should establish the connection with the client.
In the client-side traffic capture, I see the SYN packet from the client, but I do not see the SYN-ACK packet from the F5 to the client. Given this situation:
- Shouldn't I see the SYN-ACK packet from the F5 to the client in my server-side capture?
- Is there any specific reason why the SYN-ACK packet might not appear in the capture?
For reference, here is the command I used to capture the traffic:
/usr/sbin/tcpdump -s0 -ni any:nnn -w /var/tmp/proxy80.pcap host 10.16.y.y and host 10.16.x.x
Could it be possible that my capture command is incorrect, or is there something else I should consider?
Thank you for your assistance!
boneyardMVP
not sure if this will be it, but any isn't something suggested for captures on all interfaces.
i would give 0.0 a go, also see the K article on this: https://my.f5.com/manage/s/article/K411
also check if you just filter on the client IP, assuming it doesnt hit multiple virtual servers it is interesting to see if that changes something.
- fluzocapacitor
Hello,
I have tried capturing with various options, but I have not been able to capture any SYN-ACK packets. Here are the commands I used:
tcpdump -i /Common/vlan_name:nnnp -n -w /var/tmp/bl_px_01.pcap -v 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and host client_ip and port 80' tcpdump -i 0.0:nnnp -n -w /var/tmp/bl_px_01.pcap -v 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and host client_ip and port 80'Despite these attempts, I still do not see the SYN-ACK packets in the capture. Maybe as wendelyes suggested, some traffic is hidden because of offloading.
Thank you for your assistance.
- fluzocapacitor
Hello,
By the way, offload is enabled:
PVA TCP Offload State
Specifies the TCP state at which the ePVA performs hardware offload.
- SYN: Specifies that the ePVA performs hardware offload at the first client SYN. It also performs the EST-time snoop if the previous SYN-time snoop fails.
- EST: Specifies that the ePVA performs hardware offload at the client ACK when in SYN/ACK state, when the connection is transitioning towards established.
Regards,
- wendelyes
Hello,
Yes, with this configuration the session is going to be candidate to offload after the first SYN packet. You can change the TCP offload state to EST and you will be sure that the SYN-ACK packet is not going to be offloaded.
Anyway, I don't think the offload is the root cause of your issue. If the client-to-server flow is offloaded then you should also not see the ACK or GET packet.
I think you issue is related with asymmetric traffic and that the SYN-ACK does not go through the f5
Regards
- fluzocapacitor
Hello everyone,
Thank you for your suggestions. I have confirmed that there is no asymmetric traffic since the F5 is the default gateway for the pool nodes of the virtual server. Therefore, all packets must pass through the load balancer as the clients are on a different network.
Anyway, I agree with you that if the client-to-server flow were offloaded then I should also not see the ACK or GET packets.
Additionally, I wanted to provide more context for the issue. The problem arises when the SYN Cookie mechanism is enabled on the virtual server. Some servers are unable to connect to the service because they receive a server-reset (RST) packet. I was trying to capture traffic on both the client and the server (F5) to understand what was happening.
If you have any further suggestions or insights, I would greatly appreciate it.
Thank you!
- boneyard
Can you give changing those PVA settings a go? On a different non production VIP of course, see if it makes a different without offloading.
