Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Up until three days ago, my firestarter configuration and hosts.allow files were working fine without complaint. Then suddenly, I could no longer ssh tunnel, use imap client, vnc, etc. to the host.
I have reviewed firestarter's configuration to verify the IP address of the host in question, deleted the ip address, and added the ip address in question in the allow host section but firestarter refuses to allow the host access. Now, the only way to access the remote host is to turn firestarter off or by connecting from another host via ssh.
Have anyone heard of anything similar happening like this before with firestarter?
The host ip address changed earlier, changes were made to hosts.allow and firestarter. All was well, suddenly host could no longer access remote site.
To be sure ip addresses match, the ip address was copied from filter messages in /var/log/messages and pasted into hosts.allow and firestarter's host allow section. When that didn't work, selected host ip in Firestarter's event log and clicked allow host. Still no joy.
I just played around with firestarter. The rule generation looked pretty basic. If you're sure the problem is in the firewall (i.e. firestarter is still logging that it is blocking this host) and if you are familiar with iptables you can look through the rules that are generated with (as root):
Code:
iptables -nvL | less
If you're not familiar with iptables and are comfortable posting the output of the above command along with the problematic IP address, I'll be happy to take a look at it and see if I can spot anything. (Before running the above command, try doing something that will get blocked from the problem host so that the output you post shows it being blocked. Perhaps there won't be any useful info there, but then again, there may be.)
Warning, even with iptables for dummies, I still don't get iptables.
BUT, I believe that the remote hosts' newly ISP DHCP issued ipaddress (98.170.0.0) that's being rejected is in firestarters policy area for reserved ips. (ip addresses 98.0.0.0/8)???
Although that conclusion seems reasonable, it does not make sense because a similarly configured host at the same location accepts the remote host using the 98.0.0.0 ip address.
Warning, even with iptables for dummies, I still don't get iptables.
I dunno. You seem to be doing pretty well.
Quote:
BUT, I believe that the remote hosts' newly ISP DHCP issued ipaddress (98.170.0.0) that's being rejected is in firestarters policy area for reserved ips. (ip addresses 98.0.0.0/8)???
Exactly so. Now I should warn you that I am no Firestarter expert and I haven't studied the manual. But off hand, I don't see a way to handle this situation from the GUI. (Doesn't mean there isn't one.) However, the relevant data is listed in /etc/firsestarter/non-routables, and you can simply hand edit that if you don't have a better way. (You will just have to delete the line; it doesn't appear to allow for commenting something out. I'd suggest making a backup copy of the unmodified file.) Also note that the pathname I quoted is from Ubuntu; the location of the file could be different in Fedora.
Another thing, I am not an expert on unroutable addresses in Internet Protocol. But I seem to remember that there were some addresses that were reserved for the time being. Maybe there has been a change and some addresses that used to be reserved are now being used? I just downloaded the tarball from fs-security to check for any recent changes. It is dated 2005 and the non-routables file still contains that address range.
Quote:
Although that conclusion seems reasonable, it does not make sense because a similarly configured host at the same location accepts the remote host using the 98.0.0.0 ip address.
My reading of the rules you posted is it should be rejecting that address if the connection attempt comes in on eth0 and does not originate from 64.183.63.40/29 (which I assume is your LAN).
So the only way I could see different behavior is if something is configured differently on the other box or if the other box is on the same subnet (as reflected by the rule I've highlighted above) as the problematic client. As always, I am capable of making mistakes. You could always do a similar listing of the rules using iptables on the other box. The critcal rules for this would be what I've highlighted above, the rule you've probably already spotted in the NR chain, and, of course, the LSI chain where the packets actually get dropped.
Last edited by blackhole54; 06-02-2008 at 03:49 AM.
Reason: cleanup
This was intended as an edit to the previous post but I am having trouble with LQ's edit function. (Thank heavens for local text editors!)
EDIT: Firestarter has an option (Preferences -> Advanced Options under "Traffic Validation") called Block traffic from reserved addresses on public interfaces. Unchecking this box causes the NR chain to disappear. Perhaps the computer that is allowing connections from the problematic client has this box unchecked. Whether or not it should be checked is a decision you will have to make.
EDIT2: It occurred to me some of the confusion you professed about iptables might be not understanding CIDR notation. If so, take a look here. If you are a little rusty with "dotted decimal notation" for IP addresses, have a look here.
Last edited by blackhole54; 06-02-2008 at 09:51 AM.
Thanks for the link. Unfortunately, Firestarter is listing both 98.0.0.0/8 and 198.18.0.0/15 as "unroutable." But, as I previously noted, that project last released code in 2005.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
