{"action":"created","issue":{"url":"https://api.github.com/repos/t-woerner/firewalld/issues/56","labels_url":"https://api.github.com/repos/t-woerner/firewalld/issues/56/labels{/name}","comments_url":"https://api.github.com/repos/t-woerner/firewalld/issues/56/comments","events_url":"https://api.github.com/repos/t-woerner/firewalld/issues/56/events","html_url":"https://github.com/t-woerner/firewalld/issues/56","id":117018700,"number":56,"title":"Firewalld has slow startup on Manjaro ","user":{"login":"ryanvade","id":1910293,"avatar_url":"https://avatars.githubusercontent.com/u/1910293?v=3","gravatar_id":"","url":"https://api.github.com/users/ryanvade","html_url":"https://github.com/ryanvade","followers_url":"https://api.github.com/users/ryanvade/followers","following_url":"https://api.github.com/users/ryanvade/following{/other_user}","gists_url":"https://api.github.com/users/ryanvade/gists{/gist_id}","starred_url":"https://api.github.com/users/ryanvade/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ryanvade/subscriptions","organizations_url":"https://api.github.com/users/ryanvade/orgs","repos_url":"https://api.github.com/users/ryanvade/repos","events_url":"https://api.github.com/users/ryanvade/events{/privacy}","received_events_url":"https://api.github.com/users/ryanvade/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":16,"created_at":"2015-11-15T21:20:59Z","updated_at":"2016-01-11T17:56:29Z","closed_at":null,"body":"I am running firewalld on Manjaro Linux with GNOME 3.18.3.  System startup is really slow because firewalld is taking almost 20 seconds to start.  Is there anything I can do to speed up firewalld?\r\n```\r\n systemd-analyze blame\r\n         19.929s firewalld.service\r\n          9.189s systemd-journald.service\r\n          4.505s dev-sda3.device\r\n          4.455s systemd-modules-load.service\r\n          4.076s ModemManager.service\r\n          2.821s systemd-fsck@dev-disk-by\\x2duuid-fca3eb5c\\x2d2981\\x2d44c6\\x2d8108\\x2d9eef32e823a7.service\r\n          2.791s polkit.service\r\n          2.002s plymouth-quit-wait.service\r\n          1.922s avahi-daemon.service\r\n          1.784s systemd-vconsole-setup.service\r\n          1.679s thermald.service\r\n          1.486s systemd-journal-flush.service\r\n          1.149s systemd-logind.service\r\n          1.146s accounts-daemon.service\r\n           955ms systemd-sysctl.service\r\n           953ms gdm-plymouth.service\r\n           867ms systemd-tmpfiles-setup-dev.service\r\n           761ms bluetooth.service\r\n           701ms systemd-user-sessions.service\r\n           655ms systemd-binfmt.service\r\n           608ms sys-kernel-debug.mount\r\n           606ms dev-hugepages.mount\r\n           592ms freefall@-dev-sda.service\r\n           487ms systemd-hostnamed.service\r\n           424ms home.mount\r\n           413ms systemd-udevd.service\r\n           387ms user@120.service\r\n           316ms tmp.mount\r\n           315ms systemd-remount-fs.service\r\n           313ms dev-mqueue.mount\r\n           266ms proc-sys-fs-binfmt_misc.mount\r\n           249ms udisks2.service\r\n           242ms systemd-rfkill.service\r\n           239ms packagekit.service\r\n           200ms colord.service\r\n           169ms NetworkManager.service\r\n           167ms systemd-timedated.service\r\n           164ms systemd-backlight@backlight:intel_backlight.service\r\n           149ms alsa-restore.service\r\n           134ms systemd-localed.service\r\n           131ms upower.service\r\n           128ms systemd-tmpfiles-setup.service\r\n           120ms sys-kernel-config.mount\r\n           107ms systemd-timesyncd.service\r\n            94ms systemd-udev-trigger.service\r\n            88ms systemd-random-seed.service\r\n            74ms wpa_supplicant.service\r\n            64ms user@1000.service\r\n            49ms systemd-update-utmp.service\r\n            29ms rtkit-daemon.service\r\n            26ms plymouth-start.service\r\n            24ms geoclue.service\r\n            20ms kmod-static-nodes.service\r\n            13ms plymouth-read-write.service\r\n             3ms sys-fs-fuse-connections.mount\r\n```\r\n```\r\n systemctl status firewalld\r\n● firewalld.service - firewalld - dynamic firewall daemon\r\n   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: disabled)\r\n   Active: active (running) since Sun 2015-11-15 15:35:35 CST; 2min 4s ago\r\n Main PID: 606 (firewalld)\r\n   CGroup: /system.slice/firewalld.service\r\n           └─606 /usr/bin/python -Es /usr/bin/firewalld --nofork --nopid\r\n\r\nNov 15 15:35:35 ryan-linux-laptop systemd[1]: Started firewalld - dynamic firewall daemon.\r\nNov 15 15:37:07 ryan-linux-laptop /firewalld[606]: 2015-11-15 15:37:07 ERROR: UNKNOWN_INTERFACE: 'wlp10s0' is not in any zone\r\n```"},"comment":{"url":"https://api.github.com/repos/t-woerner/firewalld/issues/comments/170634225","html_url":"https://github.com/t-woerner/firewalld/issues/56#issuecomment-170634225","issue_url":"https://api.github.com/repos/t-woerner/firewalld/issues/56","id":170634225,"user":{"login":"EinerPetersen","id":16353734,"avatar_url":"https://avatars.githubusercontent.com/u/16353734?v=3","gravatar_id":"","url":"https://api.github.com/users/EinerPetersen","html_url":"https://github.com/EinerPetersen","followers_url":"https://api.github.com/users/EinerPetersen/followers","following_url":"https://api.github.com/users/EinerPetersen/following{/other_user}","gists_url":"https://api.github.com/users/EinerPetersen/gists{/gist_id}","starred_url":"https://api.github.com/users/EinerPetersen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/EinerPetersen/subscriptions","organizations_url":"https://api.github.com/users/EinerPetersen/orgs","repos_url":"https://api.github.com/users/EinerPetersen/repos","events_url":"https://api.github.com/users/EinerPetersen/events{/privacy}","received_events_url":"https://api.github.com/users/EinerPetersen/received_events","type":"User","site_admin":false},"created_at":"2016-01-11T17:56:29Z","updated_at":"2016-01-11T17:56:29Z","body":"Hi Thomas,\n\nOk, the attached tgz is from /etc/firewalld (you'll want to extract it\ninto some temporary directory because it will extract as ./firewalld)\nand a copy of the iptables-save is in\n./firewalld/zones/iptables-2016-01-10...\n\nNote: Yup ..... it's probably going to look really UGLY because I have\nbeen using the \"Firewall Config\" GUI tool to build this stuff lately\n..... I used to do all the rules by hand and it was a LOT cleaner/sane\n:-) ..... Trying to accomplish the following:\n1) Learn the tool\n2) Make it easier to maintain the firewall rules\n3) Keep rule loading as fast as possible on restarts\n\nThe way/logic I used to do the rules by hand:\nInterface -> is the top zone\nNIC (ARIN, APNIC, LACNIC, RIPE) -> addresses in zones\nCountry of origin -> addresses in NIC zones OR sub_NIC (like KRNIC ..)\n\nLogic:\nTraffic from origin -> Interface -> NIC -> Country\nAddress of greatest scope (like 1.0.0.0/8) would come into interface\neth0 and filter to APNIC (chain), IF no more addresses (so 1.0.0.1/32 is\nwhere the traffic originated) then it would either: 1) use the default\naction for the chain/zone (LOG and ACCEPT) OR 2) do something a bit more\ndetailed (LOG and DROP SSH) for example\n    IF I want to DROP all traffic for APNIC, then the default action for\nthat chain would be LOG and DROP\n    IF I want to DROP traffic for a specific NODE (/32) AND there are no\nless specific CHAINS defined, then I can act on traffic specifically for\nthat traffic\n    IF there is a less specific address (like I want to process traffic\nfor 1.0.1.0/24) then there would be another CHAIN ....\n        so the whole thing would now look like:\nInternet zone (Interface) -> NIC in Internet zone -> Country/Subnet zone\nin NIC -> Smaller Subnet in Country zone -> smaller Subnet (until we get\nto smallest in zone ... I stop at /29)\neach zone is a chain, basically anywhere you see a -> ... it's a new\nchain ....\n\nExample:  \n Interface: source = 1.0.0.0/8 -> APNIC-chain\n         APNIC: source = 1.0.0.1/24 -> KR\n            KR: source = 1.0.0.1/29 -> KR_1\n                KR_1: source = 1.0.0.1/32 -> KR_DROP or KR_ACCEPT\n            KR_DROP: -> LOG\n            KR_DROP: -> DROP\n            KR_ACCEPT: -> LOG\n            KR_ACCEPT: -> ACCEPT\n            KR_DEFAULT: -> LOG\n            KR_DEFAULT: -> ACCEPT\n        APNIC_DROP: -> LOG\n        APNIC_DROP: -> DROP\n        APNIC_ACCEPT: -> LOG\n        APNIC_ACCEPT: -> ACCEPT\n        APNIC_DEFAULT: -> LOG\n        APNIC_DEFAULT: -> DROP\n\n\nIt's a bit to maintain but it gives me a lot of control and information\n(... I know where it's coming from and what I am doing with it and it's\nall in syslog :-))\n1) For the entry into chain, have to sort to least specific ip address\nfor the ip space\n2) then in the chain most specific to least specific\n\n\nEiner\n\n\nOn 01/11/2016 05:56 AM, Thomas Woerner wrote:\n>\n> Yes, please send me what you have in the xml files and in the\n> iptables-save file. This would help for optimization.\n> BTW: For IP and also network black/white listing it might be good to\n> use ipsets, as this is increasing the throughput of your firewall by\n> reducing the rule count.\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/t-woerner/firewalld/issues/56#issuecomment-170539769>.\n>\n\n"}}