Bug #2650
closed
FTP helper breaks TCP sequence numbers on 2nd WAN
0%
Description
I am running a dual WAN setup. WAN1 is type WAN and is the default WAN, while WAN2 is type OPT. I have a FTP server on the LAN. For this FTP server I have set up port forwards for port 21 on each of the 2 WANs, relying on the built-in FTP helper to translate the control messages.
In this setup, a client connecting from the Internet via WAN1 IP + port 21 works as expected. A client connecting from the Internet via WAN2 IP + port 21 is able to authenticate, but once the PASV command is sent by the client, the TCP stream for port 21 breaks on the WAN2 side resulting in lots of TCP retransmissions and TCP session termination. This is the fault of the pfSense box that skips a sequence number when rewriting the packets received on the LAN interface towards the WAN2 interface.
Once WAN1 goes down, a client connecting from the Internet via WAN2 IP + port 21 works as expected.
I can reproduce this problem 100% of the time.
Updated by Chris Buechler over 11 years ago
- Assignee set to Ermal Luçi
- Target version set to 2.1
Updated by Ermal Luçi about 11 years ago
- Status changed from New to Feedback
Can you try with later snapshots.
This should be fixed.
Updated by Anonymous about 11 years ago
I tried with the latest build:
2.1-BETA1 (amd64)
built on Wed Jan 30 04:52:20 EST 2013
The bug is still present with the same behavior.
Updated by Ermal Luçi about 11 years ago
You have to try a today snapshot or 31st one because that one does not have the patches applied.
Updated by Anonymous about 11 years ago
Unfortunately there's no change with today's snapshot.
2.1-BETA1 (amd64)
built on Sat Feb 2 21:38:38 EST 2013
FreeBSD 8.3-RELEASE-p5
Updated by Ermal Luçi about 11 years ago
Can you show me what kind of rules you ahve configured on your OPT WAN?
Also the contents of /tmp/rules.debug and pfctl -vvsr would be useful.
Updated by Anonymous about 11 years ago
I have sent you the requested information.
Updated by Renato Botelho about 11 years ago
- Status changed from Feedback to New
Updated by Ermal Luçi almost 11 years ago
- Status changed from New to Feedback
Latest snapshots should behave better for this situation.
Updated by Anonymous almost 11 years ago
With the latest build there is no change:
2.1-BETA1 (amd64)
built on Mon May 6 16:54:02 EDT 2013
Updated by Ermal Luçi almost 11 years ago
You see the same mismatched sequence number or you see traffic goign out of WAN rather than WAN2?
I know there are still some issues there due to some problem i am figuring to solve but in most situations it should work correctly.
Updated by Anonymous almost 11 years ago
I see the same mismatched sequence number going out of WAN2. I have not checked for any traffic going out of WAN1, but will check tonight.
Updated by Anonymous almost 11 years ago
There is no FTP traffic going out of WAN1.
Updated by Tobias Wigand almost 11 years ago
Could it be that those recent fixes broke passive FTP in some setups? Mine does not work anymore, details are here:
http://forum.pfsense.org/index.php/topic,62237.msg336445.html#msg336445
Updated by Chris Buechler almost 11 years ago
- Status changed from Feedback to New
Updated by Tobias Wigand almost 11 years ago
I did a more in-depth analysis with tcpdumps (LAN/WAN) here:
http://forum.pfsense.org/index.php/topic,62237.msg342024.html#msg342024
It seems to me the source port for the DATA connection is changed on passive FTP connections but the state table does not know about the new source port.
Updated by Ermal Luçi almost 11 years ago
Can you try with tomorrows snapshots.
Updated by Doktor Notor almost 11 years ago
Please, revert these patches ASAP. They hard crash the box with FTP! http://forum.pfsense.org/index.php/topic,64144.0.html
@
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x70
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc04c96c1
stack pointer = 0x28:0xe31e6c20
frame pointer = 0x28:0xe31e6c2c
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 7 (pfpurge)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 1d1h13m36s
Cannot dump. Device not defined or unavailable.
Automatic reboot in 15 seconds - press a key on the console to abort
@
Updated by Anonymous almost 11 years ago
The problem is still there, but now I have noticed an additional behavior. I have taken the liberty to email you some packet captures.
Attempt #1 is the new behavior (TCP ACKed unseen segment).
Attempt #2 is the normal behavior up until now.
Updated by Chris Buechler over 10 years ago
- Target version changed from 2.1 to 2.2
- Affected Version changed from 2.1 to All
Updated by Rene Churchill over 10 years ago
I've also run into this problem. I didn't want it to get so buried in the pile that it never got looked at again.
Updated by Chris Buechler over 9 years ago
- Assignee changed from Ermal Luçi to Chris Buechler
- Target version deleted (
2.2)
assigning to me for further testing. Unchanged in 2.2 from prior releases, not a common enough issue to hold up and potentially destabilize 2.2.
Updated by Chris Buechler almost 9 years ago
- Status changed from Feedback to Closed
FTP helper in question no longer exists.