ftp-proxy on localhost

O

oobayly

Currently using FreeBSD 7.2-Release with all ports up to date as my firewall.

I've got Passive & Active ftp working from behind my firewall, however I had issues using any ftp clients from the firewall itself.
My default rule is to block out all outbound traffic, and to only open certain ports (anything required for work). This means that p2p apps (BBC iPlayer included) are prevented from being used.

After some investigating it struck me that any connections from the firewall box are sent straight out the default gateway, and don't hit the redirect rule in pf.conf. (Duh)

A suggestion on another site advised me to add the following rule to my pf.conf:
Code: 
pass out on $ext_if inet proto tcp from any to any port >1023

This allows ftp, but also means that my nice restrictive firewall has a gaping big hole in it.

Excuse my ignorance, but is there any way I can modify this rule that allows traffic from the firewall box out on the WAN, but still restricts traffic from the LAN going out on the WAN?

Many thanks,
John
 
Write separate 'quick' rules containing the firewall's IP instead of 'any' as the originating IP, and place them above the rest of the ruleset.

Something like

Code: 
pass out quick on $ext_if inet proto tcp from $firewall to any port > 1023 flags S/SA keep state

Thus creating a hole for the firewall's own traffic only, whilst leaving the traffic flowing through the firewall subject to the 'any' rules.
 
I can see the logic in that, however the from address is always the WAN IP regardless of whether the packet comes directly from the firewall or a machine behind the firewall. Hence the rule you suggested matches all traffic (above port 1023) outbound and not just that from the local machine.

Removing the port > 1023 rule, and executing the following commands:
Behind firewall: telnet ftp.freebsd.org 3307
From firewall: fetch ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-7.2-release/Latest/ifstated.tbz

results in the following log:
Code: 
000000 rule 3/0(match): block out on tun1: xx.xx.82.202.58456 > 87.51.34.132.3307:
  tcp 28 [bad hdr length 0 - too short, < 20]
3. 059453 rule 3/0(match): block out on tun1: xx.xx.82.202.64877 > 87.51.34.132.3307:
  tcp 28 [bad hdr length 0 - too short, < 20]
6. 015586 rule 3/0(match): block out on tun1: xx.xx.82.202.58681 > 87.51.34.132.3307:
  tcp 28 [bad hdr length 0 - too short, < 20]
190. 640831 rule 3/0(match): block out on tun1: xx.xx.82.202.63945 > 87.51.34.132.52079:
  tcp 40 [bad hdr length 0 - too short, < 20]
 
Does this box have two NICs? Try separating the ruleset into a LAN interface ruleset and a WAN interface ruleset. A.k.a.: block as close to the the origin as you can.
 
3: 2xADSL & 1 LAN. I had thought that might be the option, but had thought I might get away with altering my current ruleset <sigh>. In fact it may fix some of the ambiguities I've got too.
I guess I'll be booting up the kettle & Spotify this evening when everyone leaves.

Thanks for your help.
 
You must log in or register to reply here.
Back
Top