Neo-Rio
asked on
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 xxx.xxx.xxx.xxx/32 to any port = 80 keep state group 250
Now, when I make a similar rule to allow ftp:-
pass out quick proto tcp from xxx.xxx.xxx.xxx/32 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?
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 xxx.xxx.xxx.xxx/32 to any port = 80 keep state group 250
Now, when I make a similar rule to allow ftp:-
pass out quick proto tcp from xxx.xxx.xxx.xxx/32 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?
ASKER
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.
system accepts connection whenever ipfilter alows
there is no such facility.
the nat transparent proxy mechanism is different.
ASKER
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.0.0.0/0 -> 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.
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.0.0.0/0 -> 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.
ASKER
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 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
i do not see your ipf rules make anything into logs
ASKER
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?
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.
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.
ASKER
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" ......wtf? 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.
Trying to check the ruleset against the inactive ruleset results in "ipf: fopen(v) failed: No such file or directory" ......wtf? 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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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
I think I'll just reboot
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