Problems using portupgrade with ipfilter running

I can't get portupgrade to work properly on my FreeBSD server because of the ipfilter table running on it.
The solution sounds simple enough, to just change the table, but it doesn't seem that simple.

Portupgrade downloads various source code tarballs off the internet when various ports get upgraded. Portupgrade does this by using either ftp or http. Now here's the problem: I opened port 80 on the out -> in port, and packages that are fetched by http are getting in.

Here's the rule:- (xxx is just there to hide my global IP address)
pass out quick proto tcp from to any port = 80 keep state group 250

Now, when I make a similar rule to allow ftp:-

pass out quick proto tcp from to any port = 21 keep state group 250

FTP still fails.
A look at tcpdump shows that the server is actually connecting to the freebsd ftp servers using weird destination ports in the 1024+ range, but they are all random. No sight of port 21 to be seen. What's going on there?
I still managed to get portupgrade to work by simply disabling the packet filtering, but this isn't an optimal solution.

Can anyone tell me how I can adjust my ipfilter settings to make portupgrade go seamlessly without dropping packet filtering entirely?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

FTP is more complicated protocol.... You do not seem to understand it.
There is nothin weird in it, it works as designed, your stupid firewall configuration messes things up.

first you add ipmon_enable="YES" in /etc/rc.conf to get logs from your firewall, dumpig packets is more dangerous than disabling firewall.

normally ftp consists of control and data connections, and you deny later ones, so you get no files, portupgrade still works as expected - does not install unfetchable ports....

At first you connect to port 21 of ftp server
then either
1) you get connection to some port of your host from server port 20
1a) >1023 ...> 1023
2) you connect to ports >1023 on server


RFC959 and RFC1579 for more reference on breaking standard protocols
Neo-RioAuthor Commented:
Isn't there a way to create a rule in ipfilter to accept an FTP data connection, based on the state of the control conenction?
ipfilter accepts no connections
system accepts connection whenever ipfilter alows

there is no such facility.

the nat transparent proxy mechanism is different.
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Neo-RioAuthor Commented:
gaaahh.... just about had it with this

I've got these rules in my fw scripts. I've tried what the FreeBSD handbook said in relation to this problem.

so far I've got this in my FW
pass out quick proto tcp from (my ip adress) to any port = 21 flags S keep state group 250

(group 250 is the group for all outgoing, tied to the ethernet interface I'm using)

Then, I enabled ipnat and did this in the config file:-

map bge0 -> 0/32 proxy port 21 ftp/tcp

Now, that than get a "No route to host" error message.... ftp just tries to connect and then times out. Obviously ftp is getting out now, but it sure as hell isn't coming back in.

Neo-RioAuthor Commented:
Actually I'm looking at the logs in ipmon, and I'm not seeing any action whatsoever.
ftp just times out with those new rules, and the ipf firewall isn't giving me any info as to why.

system log is no help either

a look in tcpdump shows that requests to the ftp domain are fine, and that port 21 is getting out of the machine. However, no packets are coming back in.

....and if I disable packet filtering thigns go ok, but I can't do that of course.

ftp proxy connects via notmal socket, so you nat it back to it self, and ride into inetd flood protector.
i do not see your ipf rules make anything into logs
Neo-RioAuthor Commented:
OK, I've fixed the problem now. We're currently in the process of shifting over to a different FW system and the server was pointing at the old one - which is wherre the problem was.

On an unrelated note, I need some help with the ipf daemon on one of my servers. I shutdown the ipf daemon with ipf -D and now it won't start up after port upgrade. I get an "ioctl(FIONREAD): Operation not supported by device" error when I try and re-enable it with "ipf -Fa -f /etc/ipf.ruletable" and if I use "ipf -E", the daemon simply shuts off all network activity entirely.

Any idea how to fix this? Will I just have to reboot it, or is this fixable on the fly?

ipf is not daemon, it is kernel module or device driver.
why you filter when you do not have any understanding of application you filter???

Most likely you attempt to disable kld version of ipf, this will not work, you need "kldunload ipf" instead

or maybe
ipf -IFa # flush inactive ruleset
ipf -Ifv /etc/ipf.rules # check syntax of your ruleset against inactive ruleset
ipf -s # swap rulesets

do not blame FreeBSD ports or system applications for your fireswall's operators lack of required skill.
Neo-RioAuthor Commented:
Flushing the inactive ruleset doesn't work either. Just spits out the same "ioctl(SIOCIPPFFL): Operation not supported by device"

Trying to check the ruleset against the inactive ruleset results in "ipf: fopen(v) failed: No such file or directory" The ipf rule file is definitely where I said it was.

ipf -s also spits put another error: "ioctl(SIOCSWAPA): operation not supported by device"

Seems like no matter what I try and do, something is Very Bad (tm) at a kernel level.
then you never loaded any ipf ruleset (and ipf kernel module)

it expects ruleset to  be in /etc/ipf.rules
and /etc/rc.conf set up this way:

# ipnat_enable="YES"

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Neo-RioAuthor Commented:
funny you should mention that, because those lines are already in rc.conf, and the firewall was working OK before something happened to it.

I think I'll just reboot
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.