Hello!!!

I finished my firewall settings yesterday. Basically copied some (about 140) lines from other Iptables files and changed them to suit my needs.

I created a script and putted it in the rc.local file for it to start automatically and looks like it´s working fine... :-) But sometimes this message appears on the screen: Masquerade: route sent us somewhere else. Could anybody help me with what is triggering this message?

The second thing is that when I start my Firewall before the connection (mine is adsl) is up, I get this message on screen: Iptables v1.2.11: host/network ´login.icq.com´ not found.
Try ´iptables -h´ or ´iptables --help´for more information. And when I start my PPP connection before the Firewall I don´t get the message. The question is: should any firewall start after the connection is up?

For me that is more of an idealistic concept because it happens just one second after the connection is up.

By the way, login.icq.com is the login page (destination) for ICQ, and I blocked it.

Thanks a lot!!!
Palula Brasil

It's hard to say without seeing your routing table (route command result) and the section of iptables script dealing with masquerading. My guess is that they not always match. Why? Without seeing it I can't say.

Quote:

The second thing is that when I start my Firewall before the connection (mine is adsl) is up, I get this message on screen: Iptables v1.2.11: host/network ´login.icq.com´ not found. Try ´iptables -h´ or ´iptables --help´for more information. And when I start my PPP connection before the Firewall I don´t get the message. The question is: should any firewall start after the connection is up?

Any address written in non-IP form (so login.icq.com is one of them) is resolved when the rules load. In your case, DNS server access is needed. The connection is down at that time, so resolve attempt fails. Write the address as IP (if it doesn't change). It should help.

Firewall should rather start before your connection, but there are limitations, as you see above.

Sorry for the delay in replying your message.

The only line I have on all my firewall regarding MASQUERADE is this one:

/sbin/iptables -t nat -A POSTROUTING -s $lanip -j MASQUERADE
(Where $lanip represents my LAN IP range)

The message doesn´t appear often. It appears sometimes only. My internet connection looks fine on my windows clients, but even still it´s always annoying to know that something is going wrong with your config right? So I just want it to work 100% (as possible).

Hope anyone can help me!! :-)
Thanks a lot guys.

Do you have login.icq.com anywhere in the script (not only in the masquerading line)?

Yep. I still have it on my firewall script.
But I will change it to the regular IP number.

I changed it and the message still goes on appearing.
Something weird is that I just got my DHCP (with dhcpd) woking this afternoon and the Masquerade message seems to be appearing a bit more oftenly.

But I can surf on the web normally still yet, and the DHCP is assigning adresses normally too.

But anyway, I´d really like to correct this problem. It reminds me of how I suck!!! :-)

Thank in advance!
Palula Brasil

Here is my route table:

My opinion is that it's all because this entry:
169.254.0.0 * 255.255.0.0 U 0 0 0 eth1
169.254.x.x is global address space, still it's redirected to local network. If you connect to any server from that range of IPs, there's a problem that may result in the message you get. Is it possible to remove this entry or there's a reason why you have it?

I don´t know how that entry has been generated.
I looked for everything regarding that IP adress (169.254.0.0) in my firewall rules and I didn´t find anything.
How is an entry generated?

And another thing. Could you give an explanation of how the route command can be read? I saw it and tried to understand, but for example I couldn´t even detect that this IP adress (169.254.0.0) shouldn´t be there...

By the way. My network only comprehends adresses beetween 192.168.100.1 (server) and 192.168.100.2 - 192.168.100.255 (clients) so I really think I don´t need that IP (169.254.0.0).

And theres something else I forgot too. As I said before, I configured a DHCP server on my Linux machine (DHCPD) it´s working fine (at least I think). The thing is: When I typed ifconfig, 3 interfaces were shown. eht0, eth1 and lo. Now 4 interfaces are shown eth0, eth1, lo and another wich I can´t remember because I´m not in my machine, but I´m pretty sure it has the letter "s". Is that normal, should it happen?

Thanks a lot! :-)

Ok!
I did a little research and tried hard to understand how this thing works and came up with this line to exclude this route from my routing table.

Is this right? And is that permanent? I mean will this exclude it permanently? If not, how can I permanently take that routing rule from my routing config?

Thank You!!! :-)

Hard to say. Usually when adding a new interface, but also manually.

Quote:

And another thing. Could you give an explanation of how the route command can be read? I saw it and tried to understand, but for example I couldn´t even detect that this IP adress (169.254.0.0) shouldn´t be there...

It's quite simple. Let's say you work as the routing mechanism and get a message. You look into the table comparing destination address from the message with the ones you have in first table column using also netmask. When you have match (default rule matches all), you know which interface to use to send it.

Routing table analysis is easy. You need to know which interfaces you have and what are their IPs and netmasks. Every interface should have an entry with its network. Default means..well...default (usually Internet connection).

Quote:

And theres something else I forgot too. As I said before, I configured a DHCP server on my Linux machine (DHCPD) it´s working fine (at least I think). The thing is: When I typed ifconfig, 3 interfaces were shown. eht0, eth1 and lo. Now 4 interfaces are shown eth0, eth1, lo and another wich I can´t remember because I´m not in my machine, but I´m pretty sure it has the letter "s". Is that normal, should it happen?

Can't guess what kind of interface it is. No idea for one with s It's probably has something to do with DHCP. Without your configuration it's hard to say.

Quote:

Ok! I did a little research and tried hard to understand how this thing works and came up with this line to exclude this route from my routing table. Code: route del -net 169.254.0.0 netmask 255.255.0.0 dev eth0 Is this right? And is that permanent? I mean will this exclude it permanently? If not, how can I permanently take that routing rule from my routing config?

Looks correctly and should be permanent if there's no nice program recreating it at every boot. If you have something like that you need to find it.

It didn´t work.
Every time I boot up, there it is again on the route table.

Can anybody help me with this?
Thank you! :-)

There´s something else I forgot to tell.

In my Linux a service starts up at boot time called mDNSResponder. And it boots properly (doesn´t fail). But it gives two messages when I run the shutdown command (when it´s time for this service to unload).

If the ppp0 connection is up at shutdown time: mDNSResponder: 17 messages supressed. MASQUERADE: route sent us somewhere else.

If the ppp0 connection is down: mDNSResponder: No route. Rusty´s brain broke.

Thanks in advance!!!
Palula Brasil.

The question is what's setting the entry up. It may be mDNSResponder.
To find *all* files with 169.254.0.0 run the following command (big warning: it can take even 10 minutes):
cd /; grep -R 169.254.0.0 *
How does the result look like?

I couldn´t do that search because at some point my FC3 halted and putted a message regarding that the fd0 couldn´t be read... But it really shouldn´t be because the drive was not mounted and neither was I intrested in using the drive at that moment.

Anyway, unloading the mDNSResponder service took care of the route message. And it doesn´t show anymore messages regarding that route problem... But still there is that route (169.254.0.0) at the route table. And because of that Grep problem, I wasn´t unable to see which files has anything regarding that IP adress.

How can I correct that problem?

Thanks in advance.

The full grep command as I have given tries to look into all the directories and files. In your case, also floppy. Let's try a differnet version. This time only in /etc directory (it will be probably enough) and shorter.
cd /etc; grep -R 169.254.0.0 *

Quote:

Anyway, unloading the mDNSResponder service took care of the route message. And it doesn´t show anymore messages regarding that route problem... But still there is that route (169.254.0.0) at the route table. And because of that Grep problem, I wasn´t unable to see which files has anything regarding that IP adress.

If you remove the route with mDNSResponder off and reboot (make sure mDNSResponder is off permanently) does it stay?