Re: PF slowing down file copies
On 2007-02-23 02:36, RW [EMAIL PROTECTED] wrote: On Thu, 22 Feb 2007 23:45:06 +0100 J65nko [EMAIL PROTECTED] wrote: The OP did not keep state on TCP connections using flags S/SA. That can cause problems for TCP window scaling (defined in RFC 1323) and result in stalling connections. From http://undeadly.org/cgi?action=articlesid=20060928081238 under Create TCP states on the initial SYN packet How can a TCP connection start with anything other than an initial SYN packet? Misconfigured load-balancers are a common culprit for this sort of bug :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On Wed, 21 Feb 2007 19:38:39 +0100 J65nko [EMAIL PROTECTED] wrote: For keeping state on TCP connections you should only create state on the first packet of the 3 way TCP handshake. Using flags S/SA will ensure this. This will prevent problems with TCP windows scaling.. Why? Creating a state entry causes subsequent packets, in the same tcp connection, to bypass the rules altogether. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On 2007-02-22 14:30, RW [EMAIL PROTECTED] wrote: On Wed, 21 Feb 2007 19:38:39 +0100 J65nko [EMAIL PROTECTED] wrote: For keeping state on TCP connections you should only create state on the first packet of the 3 way TCP handshake. Using flags S/SA will ensure this. This will prevent problems with TCP windows scaling.. Why? Creating a state entry causes subsequent packets, in the same tcp connection, to bypass the rules altogether. Because a state entry is a rule by itself. A special 'rule', but still a rule. As such, each state-table entry requires a finite amount of resources. Conserving resources, whenever possible, is a good idea. Creating 10 packets for a connection whose 'traffic' requires 10 TCP segments to be transmitted, and 9000 state entries for a TCP connection whose data payload needs 9000 segments to be transmitted is kind of silly. Especially since it is entirely legal and easy to do the same thing with only 2 state entries (one for each connection). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On Thu, 22 Feb 2007 17:04:18 +0200 Giorgos Keramidas [EMAIL PROTECTED] wrote: On 2007-02-22 14:30, RW [EMAIL PROTECTED] wrote: On Wed, 21 Feb 2007 19:38:39 +0100 J65nko [EMAIL PROTECTED] wrote: For keeping state on TCP connections you should only create state on the first packet of the 3 way TCP handshake. Using flags S/SA will ensure this. This will prevent problems with TCP windows scaling.. Why? Creating a state entry causes subsequent packets, in the same tcp connection, to bypass the rules altogether. Because a state entry is a rule by itself. A special 'rule', but still a rule. As such, each state-table entry requires a finite amount of resources. Conserving resources, whenever possible, is a good idea. Creating 10 packets for a connection whose 'traffic' requires 10 TCP segments to be transmitted, and 9000 state entries for a TCP connection whose data payload needs 9000 segments to be transmitted is kind of silly. Especially since it is entirely legal and easy to do the same thing with only 2 state entries (one for each connection). The way PF works is that it first checks if there is a state entry matching the packet's address, port and protocol , if there is the state entry is used to determine what is done with the packet. Only if there is no matching entry is the script used instead. As I already said Creating a state entry causes subsequent packets, in the same tcp connection, to bypass the rules altogether. The point of testing for s/sa is to avoid creating long-lived state entries for illegal or out-of-sequence packets. The state created by s/sa has a very short lifetime. This conserves resources and protects against some DOS attacks. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On 2007-02-22 15:52, RW [EMAIL PROTECTED] wrote: On Thu, 22 Feb 2007 17:04:18 +0200 Giorgos Keramidas [EMAIL PROTECTED] wrote: On 2007-02-22 14:30, RW [EMAIL PROTECTED] wrote: On Wed, 21 Feb 2007 19:38:39 +0100 J65nko [EMAIL PROTECTED] wrote: For keeping state on TCP connections you should only create state on the first packet of the 3 way TCP handshake. Using flags S/SA will ensure this. This will prevent problems with TCP windows scaling.. Why? Creating a state entry causes subsequent packets, in the same tcp connection, to bypass the rules altogether. Because a state entry is a rule by itself. A special 'rule', but still a rule. As such, each state-table entry requires a finite amount of resources. Conserving resources, whenever possible, is a good idea. Creating 10 packets for a connection whose 'traffic' requires 10 TCP segments to be transmitted, and 9000 state entries for a TCP connection whose data payload needs 9000 segments to be transmitted is kind of silly. Especially since it is entirely legal and easy to do the same thing with only 2 state entries (one for each connection). The way PF works is that it first checks if there is a state entry matching the packet's address, port and protocol , if there is the state entry is used to determine what is done with the packet. Only if there is no matching entry is the script used instead. As I already said Creating a state entry causes subsequent packets, in the same tcp connection, to bypass the rules altogether. The point of testing for s/sa is to avoid creating long-lived state entries for illegal or out-of-sequence packets. The state created by s/sa has a very short lifetime. This conserves resources and protects against some DOS attacks. I see. I've recently discovered that IPFilter v4.0.2 on Solaris 10 had a bug in the state expiry code. States for packets without S/SA expire after 10 days, instead of a few seconds like the S/SA states. I haven't verified that this doesn't apply to PF, but since PF is a very different firewall I'll extract my foot from my mouth and go read the source now :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On 2/22/07, RW [EMAIL PROTECTED] wrote: On Wed, 21 Feb 2007 19:38:39 +0100 J65nko [EMAIL PROTECTED] wrote: For keeping state on TCP connections you should only create state on the first packet of the 3 way TCP handshake. Using flags S/SA will ensure this. This will prevent problems with TCP windows scaling.. Why? Creating a state entry causes subsequent packets, in the same tcp connection, to bypass the rules altogether. The OP did not keep state on TCP connections using flags S/SA. That can cause problems for TCP window scaling (defined in RFC 1323) and result in stalling connections. From http://undeadly.org/cgi?action=articlesid=20060928081238 under Create TCP states on the initial SYN packet --- quote -- pf does know about window scaling and supports it. However, the prerequisite is that you create state on the initial SYN, so pf can associate the first two packets of the handshake with the state entry. Since the entire negotiation of the window scaling factors takes place only in these two packets, there is no reliable way to deduce the factors after the handshake. Window scaling wasn't widely used in the past, but this is changing rapidly. Just recently, Linux started using window scaling by default. If you experience stalling connections, especially when problems are limited to certain combinations of hosts, and you see 'BAD state' messages related to these connections logged, verify that you're really creating states on the initial packet of a connection. -- end of quote --- To prevent these TCP windows scaling issues, the current pf version of OpenBSD-4.1 BETA defaults to flags S/SA keep state for TCP pass rules. Don't know when this feature will make it into FreeBSD ;) Other issues the OP should look into are the optimizing tips given in http://undeadly.org/cgi?action=articlesid=20060927091645 Adriaan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On Thu, 22 Feb 2007 23:45:06 +0100 J65nko [EMAIL PROTECTED] wrote: On 2/22/07, RW [EMAIL PROTECTED] wrote: On Wed, 21 Feb 2007 19:38:39 +0100 J65nko [EMAIL PROTECTED] wrote: For keeping state on TCP connections you should only create state on the first packet of the 3 way TCP handshake. Using flags S/SA will ensure this. This will prevent problems with TCP windows scaling.. Why? Creating a state entry causes subsequent packets, in the same tcp connection, to bypass the rules altogether. The OP did not keep state on TCP connections using flags S/SA. That can cause problems for TCP window scaling (defined in RFC 1323) and result in stalling connections. From http://undeadly.org/cgi?action=articlesid=20060928081238 under Create TCP states on the initial SYN packet How can a TCP connection start with anything other than an initial SYN packet? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On Wednesday 21 February 2007 01:21, José Pablo Fernández wrote: My problem is that when I copy a file from one network to the other, the first 128KB seems to be copied instantaneously, the second 128KB take more than two minutes and I've seen the third 128KB being copied very rarely. This might be an MTU problem. Is the MTU set to 1500 everywhere? You can try using a smaller MTU - like 1400 - on two computers, try a transfer and if that works, you'll have to check the switches involved. This is using Secure CoPy. Do you mean scp(1)? Also, what's going on when you disable pf? Nikos ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On Wednesday 21 February 2007 05:39, Nikos Vassiliadis wrote: On Wednesday 21 February 2007 01:21, José Pablo Fernández wrote: My problem is that when I copy a file from one network to the other, the first 128KB seems to be copied instantaneously, the second 128KB take more than two minutes and I've seen the third 128KB being copied very rarely. This might be an MTU problem. Is the MTU set to 1500 everywhere? You can try using a smaller MTU - like 1400 - on two computers, try a transfer and if that works, you'll have to check the switches involved. Where is/should the MTU be set? This is using Secure CoPy. Do you mean scp(1)? Yes. Also, what's going on when you disable pf? When I disable PF I can't reach outside because that is what is in charge of NATing, but I can reach the other network, and the copy just works. Thank you. -- José Pablo Fernández [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
In response to José Pablo Fernández [EMAIL PROTECTED]: On Wednesday 21 February 2007 05:39, Nikos Vassiliadis wrote: On Wednesday 21 February 2007 01:21, José Pablo Fernández wrote: My problem is that when I copy a file from one network to the other, the first 128KB seems to be copied instantaneously, the second 128KB take more than two minutes and I've seen the third 128KB being copied very rarely. This might be an MTU problem. Is the MTU set to 1500 everywhere? You can try using a smaller MTU - like 1400 - on two computers, try a transfer and if that works, you'll have to check the switches involved. Where is/should the MTU be set? ifconfig interface mtu 1400 (for example) This is using Secure CoPy. Do you mean scp(1)? Yes. Also, what's going on when you disable pf? When I disable PF I can't reach outside because that is what is in charge of NATing, but I can reach the other network, and the copy just works. Have you tried stripping your pf rules down to JUST nat to see if the problem changes? -- Bill Moran Collaborative Fusion Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On Feb 21, 2007, at 9:41 AM, José Pablo Fernández wrote: This might be an MTU problem. Is the MTU set to 1500 everywhere? You can try using a smaller MTU - like 1400 - on two computers, try a transfer and if that works, you'll have to check the switches involved. Where is/should the MTU be set? You can do ifconfig re0 mtu 1400 directly from the command line (replace re0 with whatever nic's you have), or configure it in the ifconfig line(s) in your /etc/rc.conf. Also, what's going on when you disable pf? When I disable PF I can't reach outside because that is what is in charge of NATing, but I can reach the other network, and the copy just works. Perhaps try commenting out your scrub in line, and see whether PF's re-writing of the packets is screwing something up -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On Wednesday 21 February 2007 14:50, Bill Moran wrote: When I disable PF I can't reach outside because that is what is in charge of NATing, but I can reach the other network, and the copy just works. Have you tried stripping your pf rules down to JUST nat to see if the problem changes? If I put pass in quick pass out quick just below the nat and rdr rules in pf.conf, then the copy happens ok, at normal (fast) speed. -- José Pablo Fernández [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On 2/21/07, José Pablo Fernández [EMAIL PROTECTED] wrote: Hello, I have a FreeBSD 6.2 acting as router between two LANs and the internet. I am using PF on it for filtering and I am allowing all the traffic to pass by between the two LANs: pass from $lan0:network to $lan1:network keep state pass from $lan1:network to $lan0:network keep state My problem is that when I copy a file from one network to the other, the first 128KB seems to be copied instantaneously, the second 128KB take more than two minutes and I've seen the third 128KB being copied very rarely. This is using Secure CoPy. If I copy the file to the router and from the router to the other computer, it just works. And it seems people copying files with SMB (Window's protocol) have found the same problem. Any ideas what might be going on? Thanks. For keeping state on TCP connections you should only create state on the first packet of the 3 way TCP handshake. Using flags S/SA will ensure this. This will prevent problems with TCP windows scaling.. For a more detailed explanation and some suggestions see the 3 part series about the pf firewall starting at http://undeadly.org/cgi?action=articlesid=20060927091645 BTW The author of these 3 articles is Daniel Hartmeier, principal developer of pf. ;) [big snip] =Adriaan= ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
In response to José Pablo Fernández [EMAIL PROTECTED]: On Wednesday 21 February 2007 14:50, Bill Moran wrote: When I disable PF I can't reach outside because that is what is in charge of NATing, but I can reach the other network, and the copy just works. Have you tried stripping your pf rules down to JUST nat to see if the problem changes? If I put pass in quick pass out quick just below the nat and rdr rules in pf.conf, then the copy happens ok, at normal (fast) speed. Well, it's definitely pf that's doing it, then. Some basic diagnostics would be to add parts back into the pf one or two rules at a time to see exactly what rules are causing the issue. You could also post your entire ruleset to the list. It's possible that some pf guru will see an obvious mistake in the way they're laid out. -- Bill Moran Collaborative Fusion Inc. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On Wednesday 21 February 2007 15:38, J65nko wrote: On 2/21/07, José Pablo Fernández [EMAIL PROTECTED] wrote: Hello, I have a FreeBSD 6.2 acting as router between two LANs and the internet. I am using PF on it for filtering and I am allowing all the traffic to pass by between the two LANs: pass from $lan0:network to $lan1:network keep state pass from $lan1:network to $lan0:network keep state My problem is that when I copy a file from one network to the other, the first 128KB seems to be copied instantaneously, the second 128KB take more than two minutes and I've seen the third 128KB being copied very rarely. This is using Secure CoPy. If I copy the file to the router and from the router to the other computer, it just works. And it seems people copying files with SMB (Window's protocol) have found the same problem. Any ideas what might be going on? Thanks. For keeping state on TCP connections you should only create state on the first packet of the 3 way TCP handshake. Using flags S/SA will ensure this. This will prevent problems with TCP windows scaling.. Thank you. That solved it. For a more detailed explanation and some suggestions see the 3 part series about the pf firewall starting at http://undeadly.org/cgi?action=articlesid=20060927091645 Thank you! -- José Pablo Fernández [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PF slowing down file copies
On Wednesday 21 February 2007 15:49, José Pablo Fernández wrote: For keeping state on TCP connections you should only create state on the first packet of the 3 way TCP handshake. Using flags S/SA will ensure this. This will prevent problems with TCP windows scaling.. Thank you. That solved it. Unfortunately no, a mistake in the test. -- José Pablo Fernández [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
