Link to home
Start Free TrialLog in
Avatar of philipminer
philipminer

asked on

Need to reactivate the network interface to get the firewall set correctly

I have a Fedora 8 box - Samba server, Slimserver and some virtual machines running Windows.  I think I have the firewall set correctly (I have disabled SE Linux) to handle Samba and Slimserver and a bit of web browing.

When I log on, I can browse the web, but the Slimserver and Samba are invisible until I go to Network Configuration and "activate" the network interface.  It is obviously working already, but my guess is that the firewall settings do not kick in correctly until I do this.  It means I mostly run it logged in, which I am not happy about from a security point of view.

This problem applies to root as well as an ordinary user.

Is it likely that things are starting up in the wrong order, and by activating the network card a second time I am setting things up in the correct order?
Avatar of ravenpl
ravenpl
Flag of Poland image

Please provide output from
chkconfig --list | grep iptables
for i in /etc/sysconfig/network-scripts/ifcfg-*; do echo $i; cat $i; done

which interface You have to activate manually?
Avatar of philipminer
philipminer

ASKER

Output requested:-

[root@comet ~]# chkconfig --list | grep iptables
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@comet ~]#

[root@comet ~]# for i in /etc/sysconfig/network-scripts/ifcfg-*; do echo $i; cat $i; done
/etc/sysconfig/network-scripts/ifcfg-lo
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback
/etc/sysconfig/network-scripts/ifcfg-nildram
# Compaq Computer Corporation Netelligent 10/100 TX PCI UTP
DEVICE=eth1
BOOTPROTO=none
ONBOOT=yes
HWADDR=00:08:c7:0d:bb:8c
NETMASK=255.255.255.248
IPADDR=84.12.40.82
GATEWAY=84.12.40.81
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes
NM_CONTROLLED=no
/etc/sysconfig/network-scripts/ifcfg-ntl
# nVidia Corporation MCP61 Ethernet
DEVICE=eth0
BOOTPROTO=none
HWADDR=00:19:66:46:AE:CA
ONBOOT=yes
NETMASK=255.255.255.0
IPADDR=192.168.13.11
GATEWAY=192.168.13.101
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes
[root@comet ~]#

Sorry to be unclear - network interface = network device = network card

First impression, You should rename
mv /etc/sysconfig/network-scripts/ifcfg-ntl /etc/sysconfig/network-scripts/ifcfg-eth1
mv /etc/sysconfig/network-scripts/ifcfg-nildram /etc/sysconfig/network-scripts/ifcfg-eth0

make sure those
HWADDR=00:19:66:46:AE:CA
lines match current NICs macs. You can see macs from output of "ip link" command.

Next, both interfaces are set to be activated on boot, good. But why both of them have defined
GATEWAY=
line? OS can have only one default gw (unless it's advanced router).

You still haven't told which interface You have to bring up manually?

Also, just after system restart, please check the output from
ip addr; ip route
command - or post it here.
Those script names were made by the system, not by me, but I will change them as you suggest.



The interface causing problems at the moment is eth0 (nickname - ntl) which is the one I use most of the time.  The other should be turned off.  I have two broadband suppliers, which is why I (wrongly) set up two default gateways.

I see the MACS from ip link match the output from the ifcfg scripts.  Either network card works correctly once activated from the GUI tool.


[root@comet ~]# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:19:66:46:ae:ca brd ff:ff:ff:ff:ff:ff
    inet 192.168.13.39/24 brd 192.168.13.255 scope global eth0
    inet6 fe80::219:66ff:fe46:aeca/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:08:c7:0d:bb:8c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::208:c7ff:fe0d:bb8c/64 scope link
       valid_lft forever preferred_lft forever
[root@comet ~]# ip route
192.168.13.0/24 dev eth0  proto kernel  scope link  src 192.168.13.39
default via 192.168.13.101 dev eth0
[root@comet ~]#
Changing the names of those scripts has scrambled the GUI Network Interface tool.  I now have four entries in the list of network devices.  Two now report an error if I try to activate or de-activate, and for the other two, activating or deactivating one changes both.
Networking is now not working at all on this box.  There will be a pause while I try to unscramble.
Is the output from "ip addr; ip route" grabbed just after restart? When the eth0 is down?

> Changing the names of those scripts has scrambled the GUI Network Interface tool.
I'm sorry, I havent foreseen it can break the GUI... Rename them back.

But I think there's something wring with the names.

can You tell me what happens, if You manually restart network
service network restart

also make sure, service network is started at boot time (but so unlikely anybody turned it off)
chkconfig network on
Got the networking back - deleted the devices and re-created them again using the GUI tool.  I should have changed  the contents of /etc/sysconfig/networking/devices to match the changes you proposed.  Remember, I'm a Linux wimp - mostly nervous about messing with config files so tend to use the GUI tools where they seem to work.  Because the GUI tools are pretty good I rarely need to learn what is going on under the lid.

I think the Gnome GUI networking tool made the changes to the script names ("ntl" and "nildram" were the interface nicknames), but they are now as you proposed

Yes, the ip addr and ip route were grabbed just after startup - before doing anything else at all.  Was I clear that at startup I have a working connection anyway, to the extent that Firefox can see the web.

Other services seem to be blocked though.  My next task is - I will run a dump of the iptables rules at startup to see what the settings look like at that stage.  Slimserver uses a non-standard port, so it will be obvious if that one is open at startup.
the firewall rules can be found at /etc/sysconfig/iptables, bring it here
I think, that the problem is the naming of interfaces. I think, that names of the interfaces changes after You restart it from GUI, and then for changed names firewall rules fires.
verify with "ip addr" after You reactivate the interface, is it's name still eth0?
Sounds likely, but now I can't get into the system at all.  I'll be back to you when I can.
Here are my iptables settings - nothing at all specific to either ethernet interface.

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p ipv6-icmp -j ACCEPT
-A RH-Firewall-1-INPUT -m ipv6header --header 50 -j ACCEPT
-A RH-Firewall-1-INPUT -m ipv6header --header 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d ff02::fb -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 23 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3483 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 3483 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 9000 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 9000 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
COMMIT


Since I posted last, I have been exploring sys-config-netwrok, and have now got to the stage that I can start the system from cold, login as root, activate eth0 and logout and eth0 is still running, but I cannot get it to activate on startup.  I tick the box on the setting, but cannot see that it is saved anywhere.
I'm sorry, no clue then.
Possible workarounds, put these lines to /etc/rc.d/rc.local (but test them manually from console first)

#or eth0 if ntl does not work
ifdown ntl
ifup ntl

another possible commands (if above does not work):
service network restart
service iptables restart
I'd like to give you half the points, since you have moved me forward on this.  Is that acceptable and can I actually do it?
ASKER CERTIFIED SOLUTION
Avatar of ravenpl
ravenpl
Flag of Poland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The workaround is good, thanks.  I'll carry on looking at this when I get the time, and will post any answer I get.  I also had the same problem with Fedora 6 on different hardware and just put up with it, so someone else out there will be grateful for a definitive answer if I can find it.