Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a PC with two Ethernet cards, and I was trying to configure my eth1, but when I typed $ iptables -F INPUT, the internet was gone on eth0. Does anyone has any idea how to get my internet connection back? I tried $iptables-restore /etc/sysconfig/iptables but it doesn't work.

My OS is fedora 17, x32 edition.

Update 1

nothing changed after reboot; i am connected to the network but no internet connection

PS: p4p1=eth0 PS: p3p1=eth1

$iptables -nL | grep Chain

Chain INPUT (policy ACCEPT)
Chain FORWARD (policy ACCEPT)
Chain OUTPUT (policy ACCEPT)

iptables -nvL

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
  646 57716 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
  646 39724 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
 1826  153K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited
    0     0            all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 0
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
    0     0 ACCEPT     tcp  --  p4p1   *       0.0.0.0/0            0.0.0.0/0            multiport sports 80,443 state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  p4p1   *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
    0     0 ACCEPT     tcp  --  p4p1   *       0.0.0.0/0            0.0.0.0/0            multiport sports 80,443 state RELATED,ESTABLISHED
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 0
    0     0 ACCEPT     udp  --  p4p1   *       0.0.0.0/0            0.0.0.0/0            udp spt:53
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4
    0     0 ACCEPT     tcp  --  p4p1   *       0.0.0.0/0            0.0.0.0/0            multiport sports 80,443 state RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24     state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0           
    0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 250 packets, 20540 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 ACCEPT     tcp  --  *      p4p1    0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
    0     0 ACCEPT     udp  --  *      p4p1    0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  *      p4p1    0.0.0.0/0            0.0.0.0/0            multiport dports 80,443

--END--

share|improve this question
    
The -F option pretty much flushed out all your INPUT rules. I agree with Aaron below that a reboot may restore your default chains. –  slafat01 Oct 2 '12 at 12:41
add comment

1 Answer

up vote 1 down vote accepted

A reboot might well clear up the problem. If you don't want to do that, though, you might try this:

Assuming Fedora configures similarly to RHEL, there is a chain called "RH-Firewall-1-INPUT" or similar which is used to contain rules managed by the Red Hat firewall configurator, and the INPUT chain is configured with default DROP policy and a rule pushing traffic into the Red Hat table.

You can use

 iptables -nL | grep Chain

to list all chains; if there is a chain called something like "RH-Firewall-1-INPUT" or similar, then

 iptables -A INPUT -j RH-Firewall-1-INPUT

(with the name of the firewall chain as the argument to -j, if it isn't actually "RH-Firewall-1-INPUT") should solve the problem -- this adds a rule to the INPUT chain which will push all incoming traffic into the Red Hat firewall chain, which (unless it's also been flushed) should be correctly configured to handle incoming traffic.

If that doesn't restore your connectivity, then post a comment with the output of `iptables -nvL' on the affected machine, and I'll see what I can do for you from there.

Updated: Wow.

OK, I'd start by removing INPUT rule #9, since that looks to be stopping anything from getting through the INPUT chain:

 iptables -D INPUT 9

Note that, even if that works, it'll leave you without any real firewall protection, since you've got a default ACCEPT policy on the INPUT chain. If it does work, I'd recommend rebuilding the INPUT chain from scratch.

That said, I don't think it is going to work; with a default ACCEPT policy on an empty INPUT chain, you should have no trouble accepting traffic, and it sounds like flushing the INPUT table (iptables -F INPUT) was what caused the problem in the first place. That makes me think there's something non-obvious about how your interfaces are set up, and I don't really have enough information here to tell what's going on.

If you'll add to your question the output of `ifconfig -a' on the affected machine, that might help a bit? Other than that, I'm really not sure what to suggest...

share|improve this answer
    
unfortunately it did not work, please check update 1 –  Eren Oct 2 '12 at 13:09
    
@Eren: Answer updated. Short version: Not really sure what to tell you, sorry... –  Aaron Miller Oct 2 '12 at 13:34
    
your suggestion (iptables -D INPUT 9) worked! thank you! –  Eren Oct 2 '12 at 13:44
    
Glad to hear it! -- keep in mind, though, that's probably got you without much of anything in terms of firewall protection right now, so you do want to be thinking about spending some quality time with iptables in the very near future. –  Aaron Miller Oct 2 '12 at 13:58
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.