WAN to LAN tcp connection always drop



  • Hi guys, need help with something. I have pfSense 2.1.3 running on an ALIX box. I added a rule to the firewall to allow tcp connections from WAN to LAN to certain port. At the beginning I thought the problem was in the software I was running but then I tested FTP and other software and it also failed. All these software has something in common, they establish the tcp connection (WAN to LAN in my case, reverse works fine) and right after the connection is established they start sending data from WAN to LAN (as fast as they can). The problem is that the connection is instantly dropped by pfsense. If I check the tcp packets capture the connection is always drop when the sequence number is near 65K. Could it be something related with 65536? Maybe is nothing to do with this but I just wanted to make the point just in case. I have tried to send data in smaller and bigger packets and always the same problem (near sequence number 65K the connection is drop) What I can see in the dumps is how the sender (WAN) sends a packet (to someone inside the LAN) that is never registered in pfsense packet capture, so I guess is the packet is being dropped, the sender tries a TCP retransmission few times, pfsense does not show these retransmissions, meaning that it keeps dropping them, then the sender closes the connection due to retransmission timeout.

    If I have tried to send less than 65K bytes and it never fails. I have also tried it on m0n0wall (on an ALIX board) and it also fails!

    Has anyone any idea what's the problem? I have attached the packet captures of the sender (WAN), pfsense WAN interface and receiver (LAN). I can provide by email also a small java command line application I wrote to test it if required.

    Thanks in advance!!







  • Your sender is claiming frame sizes of 5k and your receiver is claiming sizes of 1460. MTU mismatch somehow?

    I don't have much background in troubleshooting these kind of issues, so take my idea with a grain of salt.



  • Thanks for your reply,

    But the sender MTU is actually 1500. If you see the packet capture of pfsense you will see that the packets that sender is sending is actually 1500.

    I have checked all the sender, pfsense and receiver all of them has a MTU of 1500.



  • @appshare:

    Thanks for your reply,

    But the sender MTU is actually 1500. If you see the packet capture of pfsense you will see that the packets that sender is sending is actually 1500.

    I have checked all the sender, pfsense and receiver all of them has a MTU of 1500.

    I did a little digging. Seems Wireshark can report large frames for TCP because LSO can break them up for TCP into smaller frames.



  • Few things

    1. Sender attempts to resend seq 66773 5 times over 9 seconds

    2. I do not see these resends on your WAN capture

    3. Your receiver capture cuts off at 2.7sec and I can't see if any ACKs were actually sent, but from the the perspective of the other two captures, it doesn't look like it.

    4. The sender eventually gave up because of no ACKs and timed-out the TCP connection with a RST, which the WAN capture did show, even though it didn't show the prior resends



  • @Harvy66:

    Few things

    1. Sender attempts to resend seq 66773 5 times over 9 seconds

    2. I do not see these resends on your WAN capture

    3. Your receiver capture cuts off at 2.7sec and I can't see if any ACKs were actually sent, but from the the perspective of the other two captures, it doesn't look like it.

    4. The sender eventually gave up because of no ACKs and timed-out the TCP connection with a RST, which the WAN capture did show, even though it didn't show the prior resends

    Thanks again for your reply,

    1. Sender attempts to resend seq 66773 5 times over 9 seconds
    2. I do not see these resends on your WAN capture

    Yeah, the receiver has ACK'd up to seq 66773, so sender needs to send it again. But these packets are not reflected in the pfsense WAN capture so I guess pfsense is dropping these retransmission packets for some reason (which I don't really understand and that is the problem here). The second time I run the software it works fine! but after few seconds or rebooting the firewall the first time I ran the software fails.

    1. Your receiver capture cuts off at 2.7sec and I can't see if any ACKs were actually sent, but from the the perspective of the other two captures, it doesn't look like it.

    Yeah, the receiver image shows the last ACK message it sends. Because pfsense rejected to send more data to the receiver as is shown in the pfsense capture. After the 20 second the firewall will send the RST to receiver to quit the connection. (which is not reflected on the receiver image cos' I stop capturing before)

    1. The sender eventually gave up because of no ACKs and timed-out the TCP connection with a RST, which the WAN capture did show, even though it didn't show the prior resends

    Exactly, that is actually the expected behaviour of a TCP connection of a sender, "try to send few retransmissions but if no ACK release the connection". What is really weird is why pfsense if not accepting these retransmissions packets but it does accept the RST one. That is the key of the problem. I have tried different computers as sender and I always got the same behaviour.

    Another thing to consider is the packet 72 from the pfsense capture which is 536 in length (the minimum MTU value I think) and that it takes 2 seconds to be forwarded from WAN to the LAN!!

    thanks


Log in to reply