9498 How to queue ftp-proxy traffic in both directions? - The FreeBSD Forums
The FreeBSD Forums  

Go Back   The FreeBSD Forums > Server & Networking > Firewalls

Firewalls IPFW, PF, IPF (but not limited) related discussion

Reply
 
Thread Tools Display Modes
  #1  
Old March 4th, 2009, 22:18
BLASTER BLASTER is offline
Junior Member
 
Join Date: Mar 2009
Location: Moscow, Russia
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
Question How to queue ftp-proxy traffic in both directions?

Hello,

I'm using freebsd7 as a gateway with ALTQ + PF for traffic shaping in two directions. Also I'm using ftp-proxy for ftp connections to the local server from outside.

My question is, is it possible to shape ftp traffic in both directions?

ftp-proxy in freebsd7 supports queue for the rules it creates, but doesn't support tags (which would solve the problem). This is what my rc.conf looks like:
Code:
ftpproxy_enable="YES"
ftpproxy_flags="-q FTPPROXY -R 192.168.0.8"
When ftp-proxy is working, it creates two rules with the same queue name (FTPPROXY in our case) via anchor "ftp-proxy/*", like these ones:
Code:
pass in quick inet proto tcp from 91.78.191.70 to 192.168.0.8 port = 50001 flags S/SA keep state (max 1) queue FTPPROXY rtable 0
pass out quick inet proto tcp from 192.168.0.1 to 192.168.0.8 port = 50001 flags S/SA keep state (max 1) queue FTPPROXY rtable 0
It seems that the problem is that there is no way to create queues with the same name on different interfaces, so we can queue traffic on only one interface, but not on both. The following:
Code:
altq on $int_if bandwidth 100Mb hfsc queue { dflt, user1, user2 }
...
altq on $ext_if bandwidth 100Mb hfsc queue { dflt, user1, user2 } 
...
causes an error: queue dflt already exists on interface fxp1.
(Why this is unallowable, I don't understand. It would be very convenient to have one queue name (e.g. user1) defined on both router interfaces. The shaping parameters for that queue could be different for different interfaces and the number of rules would reduce.)

At the same time, it's possible to use following:
Code:
altq on {$int_if, $ext_if} bandwidth 100Mb hfsc queue { dflt, user1, user2 }
...
Now we have the same queue names for both interfaces, but only with the same shaping parameters. (Why we can't have a queue with different parameters, but only with the same ones — that's something I don't understand too.) My internet connection has asymmetric bandwidth, so this above is not a solution for me.

Is there any way to solve this problem?

Thanks.
Reply With Quote
  #2  
Old March 12th, 2009, 10:02
BLASTER BLASTER is offline
Junior Member
 
Join Date: Mar 2009
Location: Moscow, Russia
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
Default

It seems that there is no solution for current version of ftp-proxy in Freebsd7, because it has not tags as opposed to ftp-proxy in Openbsd. The only way to queue proxy's traffic on both interfaces is to use default queues for it, so it is no so good solution.

Now, I disable ftp-proxy and just redirect some range of ports for ftp-server on $ext_if, and queue it in an conventional way.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Installation from FTP: cannot resolve hostname ftp... Erratus Installing & Upgrading 20 June 29th, 2010 18:25
pf, ftp-proxy, nat, and dhcp neurosis Firewalls 15 May 20th, 2009 08:16
FTP proxy tomcatf14 Web & Network Services 5 April 27th, 2009 08:40
Postfix: Cannot flush mail queue sniper007 Web & Network Services 1 February 9th, 2009 02:25
Monitor Network Traffic bloodhound Networking 8 January 27th, 2009 09:40


All times are GMT +1. The time now is 05:44.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2013, vBulletin Solutions, Inc.
The mark FreeBSD is a registered trademark of The FreeBSD Foundation and is used by The FreeBSD Project with the permission of The FreeBSD Foundation.
Web protection and acceleration provided by CloudFlare
0