Bug #2650
closed
FTP helper breaks TCP sequence numbers on 2nd WAN
Added by Anonymous over 11 years ago.
Updated almost 9 years ago.
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.
- Assignee set to Ermal Luçi
- Target version set to 2.1
- Status changed from New to Feedback
Can you try with later snapshots.
This should be fixed.
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.
You have to try a today snapshot or 31st one because that one does not have the patches applied.
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
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.
I have sent you the requested information.
- Status changed from Feedback to New
- Status changed from New to Feedback
Latest snapshots should behave better for this situation.
With the latest build there is no change:
2.1-BETA1 (amd64)
built on Mon May 6 16:54:02 EDT 2013
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.
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.
There is no FTP traffic going out of WAN1.
- Status changed from Feedback to New
Can you try with tomorrows snapshots.
- Status changed from New to Feedback
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
@
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.
- Target version changed from 2.1 to 2.2
- Affected Version changed from 2.1 to All
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.
- 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.
- Status changed from Feedback to Closed
FTP helper in question no longer exists.
Also available in: Atom
PDF