Re: PF NAT and Oracle/Linux mystery
> Return-Path: [EMAIL PROTECTED] > Delivery-Date: Fri Jan 17 14:46:14 2003 > If the client supports the extention, it will add a TCP option to its > initial SYN packet, indicating its support (and supplying its own scale > factor). If the peer also supports the extention, it will add its own > TCP option to the SYN+ACK, supplying its scale factor (the two factors > can be different). If only one of the peers understands the extention, > the ignorant one will not add the TCP option, and the proposing one must > not scale its window values. We could add a "strip-wscale" option to scrub. It doesn't solve the state pickup issue, but could prevent clients communicating through the firewall from negotiating this option. -kj
Re: ftp with pf has problems here
On Fri, Jan 17, 2003 at 06:53:38PM -, Mikael wrote:
> Any idea ???
Your filter rules are too restrictive. You can debug such things
yourself by logging all blocked packets, and then comparing the blocked
packets with your pass rules. They don't match, and the question is why.
> # Passive ftp
> pass out quick on fxp0 proto tcp from $ext_iface to any port { 55000 ><
> 57000 } keep state
The destination ports used for passive ftp data connections are not
limited to this range. The server listens on a random port, you can't
influence that. Basically, you have to allow outgoing connections to all
ports, if you want to support passive data connections to arbitrary
servers.
> #Active ftp
> pass in quick on fxp0 proto tcp from any port 20 to $ext_iface port { 55000
> >< 57000 } keep state
The source port for active data connections (server -> client) doesn't
have to be 20. Many servers are run as non-root, so they have to use
random high ports as source ports for data connections.
Log all blocked packets, then retry and check /var/log/pflog (see
pflogd(8)). You'll see what source and destination ports the blocked
packets have. Default blocking is good, but it will always cause
breakage that you'll have to investigate like this :)
Daniel
ftp with pf has problems here
Hi,
I'm desperate to make this work.
I read a lot of different papers but the informations aren't the same
anywhere.
Everything is working except ftp
Here's what i've done
#cat /etc/inetd.conf|grep proxy
127.0.0.1:8081 stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -n -
V -D3 -u nobody -m 55000 -M 57000 -t 300
#cat /etc/pf.conf|grep nat
nat on fxp0 from 192.168.8.0/24 to any -> fxp0
#cat /etc/pf.conf|grep rdr
rdr on fxp1 proto tcp from any to any port 21 -> 127.0.0.1 port 8081
fxp0 is my external iface
fxp1 internal
Without applying the filter rules it works
# Outgoing traffic
pass out quick on fxp0 proto tcp from $ext_iface to any port { 21, 22, 23,
25, 53, 80, 443 } flags S/SA keep state
pass out quick on fxp0 proto udp from any to any port = 53 keep state
# Passive ftp
pass out quick on fxp0 proto tcp from $ext_iface to any port { 55000 ><
57000 } keep state
# Traffic allowed to come in
pass in quick on fxp0 proto tcp from any to $ext_iface port { 22, 25, 113 }
flags S/SA keep state
#Active ftp
pass in quick on fxp0 proto tcp from any port 20 to $ext_iface port { 55000
< 57000 } keep state
When I use my ftp client it get stuck when listing.
Any idea ???
I have /usr/libexec/ftpd on my system, i read somewhere that i might have
to set somethig more tomy configuration.
Could anyone describe me the setps to make this work.
Thank you
Re: PF NAT and Oracle/Linux mystery
Daniel Hartmeier wrote/schrieb/scripsit: > I guess we could add support for the case where pf does see the > handshake, but this is the first time I see this problem reported, maybe > RFC 1323 adoption isn't that broad. Let's not do the ECN mistake again. -Stefan
Resolved: PF NAT and Oracle/Linux mystery
Hi Daniel, hi Mike, and the others.
Thank you very very much for your help!
Now I know what caused the problem (TCP Window Scaling) and how
to fix it ("echo 0 > /proc/sys/net/ipv4/tcp_window_scaling" on
the clients), all without requiring access to the Oracle server
machine, and without measureable performance loss for the client
in the private network!
In one word, perfect. What a way to end a week.
Thanks again!
Cheers, Steve
_
MSN 8: advanced junk mail protection and 2 months FREE*.
http://join.msn.com/?page=features/junkmail
Re: PF NAT and Oracle/Linux mystery
On Fri, Jan 17, 2003 at 02:01:39PM +, Steve Schmitz wrote:
> Any idea why they do this?
The TCP header has only space to hold a 16-bit unsigned number to hold
the window value, so windows are traditionally limited to 65535 bytes,
which can limit performance on fast networks.
RFC 1323 (http://www.faqs.org/rfcs/rfc1323.html) defines the Window
Scale Option as an extention to TCP (RFC 793).
If the client supports the extention, it will add a TCP option to its
initial SYN packet, indicating its support (and supplying its own scale
factor). If the peer also supports the extention, it will add its own
TCP option to the SYN+ACK, supplying its scale factor (the two factors
can be different). If only one of the peers understands the extention,
the ignorant one will not add the TCP option, and the proposing one must
not scale its window values.
So, you don't necessarily have to modify the external server, it would
be sufficient to make your client not add the TCP option. Because it
adds the option ('wscale 0' in your tcpdump), the server is free to use
'wscale 9'. If your client doesn't add the option, the server won't try
to scale its windows, either.
The problem with adding support for this extention to pf is that the
needed information is communicated only in the initial SYN and SYN+ACK
packets of a connection. If pf sees those, it could note the two factors
in the state entry and multiply each subsequent window value accordingly,
without much difficulty.
But if pf creates a state entry from packets after the TCP handshake
(like when you flush your state entries, and don't limit state creation
to 'flags S/SA', so pf 'picks up' existing connections), there's no (simple)
way to deduce the factors from subsequent packets, so such state entries
would still cause stalled connections.
I guess we could add support for the case where pf does see the
handshake, but this is the first time I see this problem reported, maybe
RFC 1323 adoption isn't that broad.
Daniel
Re: PF NAT and Oracle/Linux mystery
You mentioned the behavior depends on the OS (and application) of the server. When Oracle runs on Solaris, it works. And when you connect to the Linux Oracle to another service (ssh, etc.), it works, too? I am not allowed to log into Linux/Oracle server. I tried with netcat on a sister machine of the L/O server and this worked okay. Could you run a tcpdump -nvvvSpi to catch all packets of a new connection up to the point where it stalls? You can use a filter expression (like 'host 192.168.101.14') to only capture packets of a single connection, as the stall occurs after around 130 packets, the log shouldn't get too large. Find the log attached. The client this time was 192.168.101.9. Cheers, Steve _ Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail oracle-hang.log Description: Binary data
Re: PF NAT and Oracle/Linux mystery
> You mentioned the behavior depends on the OS (and application) of the > server. When Oracle runs on Solaris, it works. And when you connect to > the Linux Oracle to another service (ssh, etc.), it works, too? If > that's the case, I wonder whether the Oracle on Linux is configured to > use any TCP options that might affect window sizes (th_win). In the tcpdump output, look for "wscale " on the first packet. Our state code doesn't handle window scaling which I can see Oracle enabling. 'echo 0 > /proc/sys/net/ipv4/tcp_window_scaling' on the linux box to turn it off. > Mike, have you ever seen such a case before? Nope. .mike
Re: PF NAT and Oracle/Linux mystery
On Fri, Jan 17, 2003 at 07:51:29AM +, Steve Schmitz wrote: > The firewall is running not quite the newest version of OpenBSD/PF (a 3.2 > beta). Is it advisable to upgrade, given the interruption in service? I doubt it will make a difference, as that part of the code (the sequence number tracking) hasn't changed since then, so no. > Jan 16 18:41:32 firewall /bsd: pf: BAD state: TCP 192.168.101.14:32863 > 139.33.102.140:50237 141.225.240.34:1521 [lo=3987556722 high=3987556777 > win=28480 modulator=0] [lo=3963179816 high=3963208296 win=5792 modulator=0] > 4:4 PA seq=3987556722 ack=3963179816 len=121 ackskew=0 pkts=130 dir=out,fwd > Jan 16 18:41:32 firewall /bsd: pf: State failure on: 1 This error means that the client (192.168.101.1) tries to send a packet to the server (141.225.240.34) with a sequence number (3987556722) and length (121) larger than the window the server expects (3987556722-77). When the server acks a packets, the expected window is increased to the acked sequence number plus the advertised window. In this case, the expected window is extremely small (just 55 bytes), so basically the next packet is certain to fail the check. The client isn't sending prematurely here, it just sends the next packet after it got an ack for the previous part (seq=3987556722, src.seqlo=3987556722), the question is why the window is too small. Possibly, the last ack from the server had a very small th_win. You mentioned the behavior depends on the OS (and application) of the server. When Oracle runs on Solaris, it works. And when you connect to the Linux Oracle to another service (ssh, etc.), it works, too? If that's the case, I wonder whether the Oracle on Linux is configured to use any TCP options that might affect window sizes (th_win). Could you run a tcpdump -nvvvSpi to catch all packets of a new connection up to the point where it stalls? You can use a filter expression (like 'host 192.168.101.14') to only capture packets of a single connection, as the stall occurs after around 130 packets, the log shouldn't get too large. Mike, have you ever seen such a case before? Daniel
