2

In an attempt to gain VNC access to a remote box I threw this silly command at its firewalld over ssh i.e.

$ firewall-cmd --enable 5903:tcp

Now I cannot ssh, ping or curl the server. Whoops.

Can anybody explain what has caused this to happen? I mean surely --enable on its own would enable the firewall and its default rules (i.e. ssh access being one of them) right? As you can probably tell I didn't read the manual- fundamental human error. Also note I ran the command as a normal user, not as root or via sudo. Thanks all :(

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
tiredone
  • 63
  • 1
  • 6
  • I ran an intensive zenmap (nmap) scan on the host, it comes back as host down. This means somehow, the above command killed off networkd or probably segfaulted the machine. I'll look into this some more later and attempt to give more insight as to what is going on for a clearer question. – tiredone Feb 12 '13 at 20:07
  • Just to confirm. The firewall was indeed put into panic mode by the issued command. So note well that --enable == --enable-panic! To disable the mode you either issue --disable or --disable-panic to firewall-cmd. – tiredone Feb 13 '13 at 08:08

1 Answers1

3

FirewallD is very new, and as such it's going to take some time to get accustomed to.

You can begin by reading the Fedora wiki page on FirewallD, which has a complete list of its command line options/usage.

My best guess on what happened is that you accidentally put the firewall in panic mode, where it blocks all network connections. This is based on the fact that the only option to firewall-cmd which begins with --enable is --enable-panic. You will have to go to the server console or remote into the server's OOB management interface (iLO, DRAC, IPMI) to recover from this.

The correct way to add a service is with --add-service or --add-port.

@mattdm notes in a comment below that a bug has been filed against FirewallD for exactly this behavior. The bug appears to have been fixed, by removing the options --enable-panic and --disable-panic and replacing them with --panic-on and --panic-off. This has been committed and will appear in a future release.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
  • Thank you, panic sounds v.likely. I'll make a note to read the wiki through. The alternative access options sound nice since the server is far away from me. Again much appreciated... I am totally in for it now though! – tiredone Feb 12 '13 at 20:16
  • Any data center that isn't horribly low budget should offer you remote console access via one of these methods, either included or as a small additional charge. – Michael Hampton Feb 12 '13 at 20:17
  • This is totally it. I filed a bug about this a few months ago, at https://bugzilla.redhat.com/show_bug.cgi?id=874912 – mattdm Feb 23 '13 at 16:22
  • To add to the answer's last line, here is the actual syntax for a given tcp port and in public zone: sudo firewall-cmd --zone=public --add-port=3310/tcp – Ross Jul 30 '13 at 22:54