0

I'm seeing a weird network behaviour with my TCP 3-way handshake in my home lab.

Setup is from my Windows 10 host on one network, through pfSense, and into an Ubuntu VM on a different one. Firewalls are all off, or set to ANY-ANY - for sanity-checking, logs show no firewall block rules are being triggered.

  • If I try to connect to a listening TCP service on a host in a different subnet, I send a SYN, receive a SYN-ACK, but the ACK never goes back out. This is from direct monitoring on my Win10 host using Wireshark.
  • If I create the packets using raw sockets in scapy (using this script), I have no issues with network connectivity - I can do a full 3-way handshake, and indeed, download web pages using that script.
  • This issue only seems to happen across subnets; whereby it routes through my pfSense. However given that I can manually craft the packets in scapy, my hunch is that this is not an issue at the pfSense level, since it seems to be my host that is not sending the ACK.
    • If the target machine is on the same subnet, I see no odd behaviour.
    • Windows firewall is completely off.

Does this problem sound familiar to anyone more versed in networking? Are there any other things I should be trying?

Improve this question
3
  • 1
    Does the SYN-ACK arrive with the correct source & destination IP addresses? Do its parameters (seq#s, etc.) actually match the SYN that was sent? (Try disabling "PF scrubbing" in /system_advanced_firewall.php.) Does the host have multiple interfaces and might be sending the reply through the 'wrong' interface? Does the same problem occur for both IPv6 and IPv4, or only one of them?
    – grawity_u1686
    Commented May 16, 2020 at 8:41
  • 1
    This is honestly the sort of thing I'd typically use dtrace for, but I'm not well versed in how to do this sort of thing on a windows box, but dtrace is available. What I'd be looking for is specifically what decisions tcp was making when it receives the SYN-ACK. There are conditions that need to be met in order to process it, so it is possible one of those is not being met and the packet is discarded.
    – MaQleod
    Commented May 16, 2020 at 18:41
  • Thanks for the guidance - pointed me in the right direction (and made me learn some things too). Much appreciated!
    – Smashery
    Commented May 17, 2020 at 8:52

1 Answer 1

Reset to default
0

For me, this ended up being TCP Checksum Offloading being enabled (which it seems to be by default on pfSense). I guess my NIC doesn't support it, so it was sending out packets with bad checksums. I disabled that in pfSense and everything's working as expected.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .