1

I'm battling with firewalld and SSL on Fedora 29 workstation. I get a connection refused / can't Connect to server when I try and open an SSL connection to nginx.

If I stop firewalld with:

sudo systemctl stop firewalld

Then I connect using http and https from a remote system and get default Welcome to Nginx page.

If I start firewalld with

sudo systemctl start firewalld

Then I can connect using http but cannot connect using https and get a 'Can't connect to Server' error. So the issue seems be my firewalld configuration.

I had configured firewalld for http and https as follows:

>sudo firewall-cmd --set-default-zone=public
success
>sudo firewall-cmd --zone=public --add-service=https --permanent
success
>sudo firewall-cmd --zone=public --add-service=http --permanent
success
>sudo firewall-cmd --zone=public --add-masquerade --permanent
success
>sudo firewall-cmd --reload
success

so now:

>sudo firewall-cmd --get-default-zone
public
>sudo firewall-cmd --get-active-zones
public
  interfaces: ens33
>sudo firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens33
  sources: 
  services: dhcpv6-client http https mdns ssh
  ports: 
  protocols: 
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

Which gets me to the point where http works but not https when firewalld is enabled.

I've tried turning off selinux with:

sudo setenforce 0

but same result- https connections are refused when firewalld is enabled.

I've also tried turning on firewalld logging, but even at log level 10 with all denied, I don't get an entry in the log, after firewalld has started, about the attempted connection.

I suspect that the issue here is my self-signed SSL cert which is known to nginx but not known to firewalld, but I can't seem to find anything that shows how to point firewalld to my CA cert.

Besides:

sudo systemctl disable firewalld

any suggestions to get firewalld to accept my SSL connections?

/etc/hosts maps 10.0.0.10 to the host name; ping'ing the host name gets a response

>ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:2c:b6:0d brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.10/24 brd 10.0.0.255 scope global dynamic noprefixroute ens33
       valid_lft 81698sec preferred_lft 81698sec
    inet6 fe80::213b:4f37:7851:a058/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:65:88:ec brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:65:88:ec brd ff:ff:ff:ff:ff:ff

Removed masquerading with:

>sudo firewall-cmd --zone=public --remove-masquerade --permanent
success
>sudo firewall-cmd --reload
success

But same result.

>sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N FORWARD_IN_ZONES
-N FORWARD_IN_ZONES_SOURCE
-N FORWARD_OUT_ZONES
-N FORWARD_OUT_ZONES_SOURCE
-N FORWARD_direct
-N FWDI_public
-N FWDI_public_allow
-N FWDI_public_deny
-N FWDI_public_log
-N FWDO_public
-N FWDO_public_allow
-N FWDO_public_deny
-N FWDO_public_log
-N INPUT_ZONES
-N INPUT_ZONES_SOURCE
-N INPUT_direct
-N IN_public
-N IN_public_allow
-N IN_public_deny
-N IN_public_log
-N OUTPUT_direct
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j LOG --log-prefix "STATE_INVALID_DROP: "
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j LOG --log-prefix "FINAL_REJECT: "
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES_SOURCE
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES_SOURCE
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j LOG --log-prefix "STATE_INVALID_DROP: "
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j LOG --log-prefix "FINAL_REJECT: "
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -j OUTPUT_direct
-A FORWARD_IN_ZONES -i ens33 -g FWDI_public
-A FORWARD_IN_ZONES -g FWDI_public
-A FORWARD_OUT_ZONES -o ens33 -g FWDO_public
-A FORWARD_OUT_ZONES -g FWDO_public
-A FWDI_public -j FWDI_public_log
-A FWDI_public -j FWDI_public_deny
-A FWDI_public -j FWDI_public_allow
-A FWDI_public -p icmp -j ACCEPT
-A FWDO_public -j FWDO_public_log
-A FWDO_public -j FWDO_public_deny
-A FWDO_public -j FWDO_public_allow
-A INPUT_ZONES -i ens33 -g IN_public
-A INPUT_ZONES -g IN_public
-A IN_public -j IN_public_log
-A IN_public -j IN_public_deny
-A IN_public -j IN_public_allow
-A IN_public -p icmp -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT
-A IN_public_allow -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT

Checking the https status:

>firewall-cmd --info-service=https
https
    ports: 443/tcp
    protocols: 
    source-ports: 
    modules: 
    destination:

Am using WMWare Fusion Professional Version 11.0.3 (12992109) on MacOs Mojave 10.14.4 (18E226). In VMWare the network adapter for Fedora 29 is set to 'Bridged (Autodetect)'.

myk
  • 181
  • 1
  • 6
  • 1
    I don't see any obvious problem here except for masquerading being enabled when you aren't using it. Turn it off. If that doesn't solve the problem, check the actual state of the firewall, e.g. with `iptables -S` and add this to your question. Also add the VMware product you are using, its version information, and the VMware virtual network setup. – Michael Hampton Apr 20 '19 at 03:42
  • Is it possible you're trying to connect to a page on a nonstandard port, such as example.com:9000? That would explain why firewalld is blocking you even with https allowed in the rules. – Kefka May 03 '19 at 15:16
  • oh and you may also want to run `# firewall-cmd --info-service=https` and make sure that 443/tcp is listed under ports, in case something was messed up at some point. Probably not the problem, but sometimes simple stuff gets overlooked. – Kefka May 03 '19 at 15:23
  • @Kefka: nginx is configured as a reverse proxy to redirect 443 to 9999. The client side connection is definitely connecting via port 443 (https) and works when firewalld is disabled. – myk May 05 '19 at 00:28
  • I don't see any problems in what you've posted, but just as a test I would try temporarily allowing port 9999 just in case the proxy is doing something weird like trying to open a second connection on the other port (which possibly is happening if you use rewrites or something in your config). This would be with `# firewall-cmd --add-port=9999/tcp` (without --permanent, so it will take effect immediately and a --reload will remove the rule if it doesn't help) – Kefka May 05 '19 at 22:03
  • @Kefka: unfortunately no success with add-port 9999. – myk May 07 '19 at 20:27

0 Answers0