ftp-proxy(8) and ftpd(8) on the same host
Hi! On 5.2-stable, I'm trying to setup the stock ftpd(8) on a machine where the incoming traffic is not allowed arbitrarily above net.inet.ip.porthifirst, and the clients wish to use passive mode data connections. I thought I could use ftp-proxy(8) to append a pass in rule to the ftp-proxy anchor every time the client issues a PASV command, allowing the passive inbound data connection from the client to the server. I'm running ftp-proxy(8) and ftpd(8) like this: /usr/sbin/ftp-proxy -D 7 -b server_ip -p custom_ftp_port -R 127.0.0.1 -P 21 /usr/libexec/ftpd -D -A -ll -4 -n -W -u 027 -d [-P] # I've tried with and without -P ... and I have this pass in rule in pf.conf for the proxy: pass in on $ext_if inet proto tcp from any to $server_ip port custom_ftp_port Although ftpd(8) listens on *.21, pf(4) won't allow connections to port 21, only custom_ftp_port, which is what I wanted. The clients can connect and log-in alright, but issuing a directory listing and trying to connect using passive mode fails. So it happens, that the client's ftp client retries continually to build up the data connection, so I can follow it in the logs and `pfctl -a ftp-proxy/* -sr`. The rules are changing in the anchor, so ftp-proxy updates it, and this is what I see many times again and again in /var/log/ftpd: ftpd[21372]: command: PASV ftpd[21372]: --- 227 Entering Passive Mode (127,0,0,1,245,74) ftpd[21372]: command: LIST ftpd[21372]: --- 425 Can't build data connection: illegal port number ftpd[21372]: command: PASV ftpd[21372]: --- 227 Entering Passive Mode (127,0,0,1,216,51) ftpd[21372]: command: LIST ftpd[21372]: --- 425 Can't build data connection: illegal port number ftpd[21372]: command: PASV ftpd[21372]: --- 227 Entering Passive Mode (127,0,0,1,232,17) ftpd[21372]: command: LIST ftpd[21372]: --- 425 Can't build data connection: illegal port number ftpd[21372]: command: PASV ftpd[21372]: --- 227 Entering Passive Mode (127,0,0,1,217,88) ftpd[21372]: command: LIST ftpd[21372]: --- 425 Can't build data connection: illegal port number ftpd[21372]: command: PASV ftpd[21372]: --- 227 Entering Passive Mode (127,0,0,1,226,231) ftpd[21372]: command: LIST ftpd[21372]: --- 425 Can't build data connection: illegal port number AFAIK the passive ports that the client negotiates with ftp-proxy differ from the ones that ftp-proxy uses with the ftp server, so there can not be collisions. But evidently I'm missing something here, or I've just stared at the ip addresses and port numbers too long. Any insight would be very much appreciated, thanks, Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
bad rule, or special filtering needed for bootp packets?
The very, very first rule in my pf ruleset is part of a fairly vanilla
anti-spoof/sanity check set, intended to catch incoming bogon/martian
packets:
table unroutable_ips const { 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4, 255.255.255.255/32
}
block drop in log quick on ! lo0 inet from unroutable_ips to any
label block unroutable ip
I can see it being evaluated using pfctl -v -s rules, but so far
(~40hrs uptime) it hasn't matched anything yet. That would normally
not be of concern, except I'm seeing stuff like this in the pflog that
I think it should have caught - but had to get caught by a later,
fail-safe rule at the bottom of the ruleset. In particular, I'm seeing
lots of bootp packets from badly-configured Windows clients:
Mar 26 19:22:05.85 rule 49/(match) [uid 0, pid 2590] block in on
em0: 0.0.0.0.68 255.255.255.255.67: xid:0x64f14f [|bootp] (DF) [tos
0x10] (ttl 64, id 0, len 330)
So:
- Is there something wrong with my first rule that I'm not seeing that
causes these 0.0.0.0 bootp packets to miss it, OR
- Is there something special about the bootp packets [remember, bootp
uses UDP] that they won't match that rule, even though the source is
in the unroutable_ips table?
Thanks for any insight, or other debugging ideas I can test.
/d/
PS: Notice the quick keyword in the block rule - this isn't a last
rule that matches issue, in case you're tempted to reply with
something about that - I would think a packet from 0.0.0.0 should hit
the rule, match, and then due to quick undergo no further
evaluation, end of story.
CPU/hw recommendations for routing
Hi I'm looking into replacing some older OpenBSD boxes (running BGPD/OSPFD and do routing, no active pf) with some new hardware. Of course I'd like to replace them with something fast. Currently there is only moderate load ~200mbps / 200-300kpps. But a little room to grow wont hurt. I guess multicore is nice to distribute the load from the routing processes over multiple cores. The interrupt load from the nics is handled by one core only, right? Ideally I'd have a CPU with fewer cores but higher CPU frequency on each core? Does anybody have experience with Core i7 CPUs that supposedly can automatically over-clock single CPU cores? (such as the Intel Core i7-3770K). Are the AMD FX processors any good for this purpose? Is cache/memory bandwidth and speed a major concern? I did some basic tests with some hardware I have lying around and saw that a Intel Xeon X3470 performs pretty well. How important is the nic driver? In the archives I read that the em driver is pretty good. Is that still the case? Anything else I need to take into consideration? Thanks for sharing your thoughts. Regards Andre
Re: Invalid checksum with 82574L (em)
On Tue, Mar 26, 2013 at 05:46:12PM -0300, Hugo Osvaldo Barrera wrote: On 2013-03-20 20:37, Hugo Osvaldo Barrera wrote: I've been having a very annoying issue with an 82574L for a pretty long time now. After the PC is turned off (either properly or due to a power failure), the NIC does not work upon the next boot. em0 at pci1 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msiem0: The EEPROM Checksum Is Not Valid em0: Unable to initialize the hardware I found an Intel firmware flashing utility for DOS that rebuilds the checksum. After running it, however, my MAC is 00:00:00:00:00:00. I need to set the mac back with it, and make it rebuild the checksum. After I do this, OpenBSD boots fine: em0 at pci1 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msi, address 00:22:4d:7c:b2:76 The NIC is an onboard one, and I've no extra PCI slots, so I can't really change it. Here's my full dmesg in case it's of further use. Please also let me know if there's anything else which may be of use. OpenBSD 5.2-current (GENERIC.MP) #5: Wed Dec 12 23:22:46 MST 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4275666944 (4077MB) avail mem = 4139347968 (3947MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb920 (27 entries) bios0: vendor Intel Corp. version MUCDT10N.86A.0072.2012.0808.1512 date 08/08/2012 bios0: Intel Corporation D2700MUD acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC MCFG HPET acpi0: wakeup devices SLT1(S4) PS2M(S4) PS2K(S4) UAR1(S3) UAR2(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz, 2133.73 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3, CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC cpu0: 512KB 64b/line 8-way L2 cache cpu0: apic clock running at 133MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz, 2133.41 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3, CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC cpu1: 512KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz, 2133.41 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3, CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC cpu2: 512KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz, 2133.41 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3, CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC cpu3: 512KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: SLPB acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 vendor Intel, unknown product 0x0bf3 rev 0x03 vga1 at pci0 dev 2 function 0 vendor Intel, unknown product 0x0be2 rev 0x09 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp at vga1 not configured azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Realtek ALC662 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: msi pci1 at ppb0 bus 1 em0 at pci1 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msi, address 00:22:4d:7c:b2:76 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 8 int 23 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 8 int 19 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 8 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 8 int 16 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 8 int 23 usb0
Re: CPU/hw recommendations for routing
On Wed, Mar 27, 2013 at 07:49:27PM +0100, Andre Keller wrote: Hi I'm looking into replacing some older OpenBSD boxes (running BGPD/OSPFD and do routing, no active pf) with some new hardware. Of course I'd like to replace them with something fast. Currently there is only moderate load ~200mbps / 200-300kpps. But a little room to grow wont hurt. I guess multicore is nice to distribute the load from the routing processes over multiple cores. The interrupt load from the nics is handled by one core only, right? Ideally I'd have a CPU with fewer cores but higher CPU frequency on each core? Does anybody have experience with Core i7 CPUs that supposedly can automatically over-clock single CPU cores? (such as the Intel Core i7-3770K). Are the AMD FX processors any good for this purpose? Is cache/memory bandwidth and speed a major concern? I did some basic tests with some hardware I have lying around and saw that a Intel Xeon X3470 performs pretty well. How important is the nic driver? In the archives I read that the em driver is pretty good. Is that still the case? Anything else I need to take into consideration? Big caches, quick memory and a good IO conectivity helps a lot. AFAIK turbo mode of the new intel CPUs should work but I never tried to figure that out. The clock speed of a CPU can only be compared between the same CPU family. Sometimes a higher clock rate CPU is doing less forwarding than a slower CPU. -- :wq Claudio
Re: CPU/hw recommendations for routing
On 2013-03-27, Andre Keller a...@list.ak.cx wrote: Hi I'm looking into replacing some older OpenBSD boxes (running BGPD/OSPFD and do routing, no active pf) with some new hardware. Of course I'd like to replace them with something fast. Currently there is only moderate load ~200mbps / 200-300kpps. But a little room to grow wont hurt. I guess multicore is nice to distribute the load from the routing processes over multiple cores. The interrupt load from the nics is handled by one core only, right? Ideally I'd have a CPU with fewer cores but higher CPU frequency on each core? Does anybody have experience with Core i7 CPUs that supposedly can automatically over-clock single CPU cores? (such as the Intel Core i7-3770K). Are the AMD FX processors any good for this purpose? Is cache/memory bandwidth and speed a major concern? I did some basic tests with some hardware I have lying around and saw that a Intel Xeon X3470 performs pretty well. How important is the nic driver? In the archives I read that the em driver is pretty good. Is that still the case? Anything else I need to take into consideration? Thanks for sharing your thoughts. Regards Andre I'm using r210's with 6-port em(4) nics added, not too expensive and they work quite nicely (I'd rather have more boxes rather than redundant PSU). At around 200Mbps, most modern machines will give you plenty of headroom. Depending on where they are located you might want to look more at power consumption rather than CPU performance.
Re: bad rule, or special filtering needed for bootp packets?
Thanks to Jan for pointing out I neglected to include the macro defs
for the nets (though they're vanilla and what you'd expect). Here's
the full source for the first rule, the one I think should catch the
bogon packets but doesn't:
int_net = 192.168.5.128/25
wls_net = 192.168.10.128/25
ptr_net = 192.168.99.128/25
table unroutable_ips const { 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4, 255.255.255.255/32
}
block drop in log quick on ! lo0 inet from unroutable_ips to any
label block unroutable ip
The rest of the question below remains the same.
thankee much /david/
On Wed, Mar 27, 2013 at 10:12 AM, David Ruggiero
thatseattle...@gmail.com wrote:
The very, very first rule in my pf ruleset is part of a fairly vanilla
anti-spoof/sanity check set, intended to catch incoming bogon/martian packets:
table unroutable_ips const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16,
!$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4, 255.255.255.255/32 }
block drop in log quick on ! lo0 inet from unroutable_ips to any label
block unroutable ip
I can see it being evaluated using pfctl -v -s rules, but so far (~40hrs
uptime) it hasn't matched anything yet. That would normally
not be of concern, except I'm seeing stuff like this in the pflog that I
think it should have caught - but had to get caught by a later,
fail-safe rule at the bottom of the ruleset. In particular, I'm seeing lots
of bootp packets from badly-configured Windows clients:
Mar 26 19:22:05.85 rule 49/(match) [uid 0, pid 2590] block in on em0:
0.0.0.0.68 255.255.255.255.67: xid:0x64f14f [|bootp] (DF) [tos
0x10] (ttl 64, id 0, len 330)
So:
- Is there something wrong with my first rule that I'm not seeing that causes
these 0.0.0.0 bootp packets to miss it, OR
- Is there something special about the bootp packets [remember, bootp uses
UDP] that they won't match that rule, even
though the source is in the unroutable_ips table?
Thanks for any insight, or other debugging ideas I can test.
/d/
PS: Notice the quick keyword in the block rule - this isn't a last rule
that matches issue, in case you're tempted to reply with
something about that - I would think a packet from 0.0.0.0 should hit the
rule, match, and then due to quick undergo no further
evaluation, end of story.
Re: bad rule, or special filtering needed for bootp packets?
On 27 Mar 2013 at 16:01, David Ruggiero wrote:
Thanks to Jan for pointing out I neglected to include the macro defs
for the nets (though they're vanilla and what you'd expect). Here's
the full source for the first rule, the one I think should catch the
bogon packets but doesn't:
int_net = 192.168.5.128/25
wls_net = 192.168.10.128/25
ptr_net = 192.168.99.128/25
table unroutable_ips const { 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4,
255.255.255.255/32
}
block drop in log quick on ! lo0 inet from unroutable_ips to any
label block unroutable ip
The rest of the question below remains the same.
thankee much /david/
On Wed, Mar 27, 2013 at 10:12 AM, David Ruggiero
thatseattle...@gmail.com wrote:
The very, very first rule in my pf ruleset is part of a fairly
vanilla anti-spoof/sanity check set, intended to catch incoming
bogon/martian packets:
table unroutable_ips const { 10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16, !$int_net, !$wls_net, !$ptr_net, 169.254.0.0/16,
127.0.0.0/8, 192.0.2.0/24, 0.0.0.0/32, 240.0.0.0/4,
255.255.255.255/32 }
block drop in log quick on ! lo0 inet from unroutable_ips to any
label block unroutable ip
I can see it being evaluated using pfctl -v -s rules, but so far
(~40hrs uptime) it hasn't matched anything yet. That would normally
not be of concern, except I'm seeing stuff like this in the pflog
that I think it should have caught - but had to get caught by a
later,
fail-safe rule at the bottom of the ruleset. In particular, I'm
seeing lots of bootp packets from badly-configured Windows clients:
Mar 26 19:22:05.85 rule 49/(match) [uid 0, pid 2590] block in on
em0: 0.0.0.0.68 255.255.255.255.67: xid:0x64f14f [|bootp] (DF)
[tos
0x10] (ttl 64, id 0, len 330)
So:
- Is there something wrong with my first rule that I'm not seeing
that causes these 0.0.0.0 bootp packets to miss it, OR
- Is there something special about the bootp packets [remember,
bootp uses UDP] that they won't match that rule, even
though the source is in the unroutable_ips table?
Thanks for any insight, or other debugging ideas I can test.
/d/
PS: Notice the quick keyword in the block rule - this isn't a
last rule that matches issue, in case you're tempted to reply with
something about that - I would think a packet from 0.0.0.0 should
hit the rule, match, and then due to quick undergo no further
evaluation, end of story.
Did you take the time to display the content of the table?
'pfctl -t unroutable_ips -Ts' should do the trick, and then you would
see that 0.0.0.0 is *not* in the table. I just ran a quick test to
verify that it is not possible to add such an address to a table. I
did not dig through the source code and is not an expert on the IP
stack as some devs on this list, but I do suspect that there are many
special properties attached to a null address field.
Re: bad rule, or special filtering needed for bootp packets?
Thanks! No, it didn't occur to me, so very appreciated. I didn't remember that you could do that form of the table command to show explicit members in a list, so that's also really helpful. FWIW, though..I would not have expected that pf would silently drop - without any warning message or complaint - an address explicitly stated as being a member of a constant table definition. Even that address. You're right that (at least in hindsight) 0.0.0.0/mask might be treated differently - maybe it uses it as a marker for an empty slot or the like? But regardless of that, I would (a) expect that fact to be documented (if it is, I missed it), and (b) expect that the pf parser would say something as it was throwing it away (at least a warning message about unparseable address at line XX - ignored or the like). For it to just drop it on the floor and say nothing at all seems - well, kind of non-pf-ish. Perhaps worth a documentation patch, if not an actual code patch. Again, much thanks. /d/ Did you take the time to display the content of the table? 'pfctl -t unroutable_ips -Ts' should do the trick, and then you would see that 0.0.0.0 is *not* in the table. I just ran a quick test to verify that it is not possible to add such an address to a table. I did not dig through the source code and is not an expert on the IP stack as some devs on this list, but I do suspect that there are many special properties attached to a null address field.
