Description of problem: ----------------------- On our Fedora-19-based server, we have several rules for port forwarding from server's external interface to ssh ports on workstations that are located on internal network: [root@cyclone ~]# firewall-cmd --zone=public --list-all public (default, active) interfaces: ens192 sources: services: http https ports: masquerade: yes forward-ports: port=9022:proto=tcp:toport=22:toaddr=192.168.90.28 port=9024:proto=tcp:toport=22:toaddr=192.168.90.25 port=6022:proto=tcp:toport=22:toaddr= port=9023:proto=tcp:toport=22:toaddr=192.168.90.19 icmp-blocks: rich rules: These stopped working after a recent update, which upgraded firewalld from firewalld-0.3.8-1 to 0.3.9.3-1. After the update, the output of the above firewall-cmd command remains the same, but connecting to forwarded ports fails. In fact, the symptoms are the same as if port-forwarding rules were present but masquerading was turned off - ssh client takes forever to decide that it cannot establish connection, as opposed to it immediately returning 'No route to host' (which would happen if port-forwarding rule is not present). The rule for local redirection (6022 -> 22 on server) appears to be unaffected. Version-Release number of selected component (if applicable): ------------------------------------------------------------- firewalld-0.3.9.3-1.fc19 How reproducible: --------------- Always. Steps to Reproduce: --------------- 1. set up two machines corresponding to the above-mentioned scenario: machine A has two network interfaces, "private" and "public" one, while machine B has only "private" interface. Enable masquerading on A's "public" interface and forward a port from some port on A's "public" interface to some (e.g., ssh) port on B's "private" interface. 2. connect from machine C ("public" interface) to the forwarded port, for example using nc or ssh client. Actual results: --------------- Connection times out, e.g. "Ncat: Connection timed out". (Note that is is not "Ncat: No route to host.") Expected results: ----------------- Connection is established successfully.
Could you save output of iptables-save in file when using the old and the new firewalld version and attach them here so we can compare them ? You can make the attachment private if you want.
Created attachment 876342 [details] Output of iptables-save with firewalld-0.3.8-1.fc19
Created attachment 876343 [details] Output of iptables-save with firewalld-0.3.9.3-1.fc19
(In reply to Rok Mandeljc from comment #0) > In fact, the symptoms are the same as if port-forwarding rules were present > but masquerading was turned off - ssh client takes forever to decide that it > cannot establish connection, as opposed to it immediately returning 'No > route to host' (which would happen if port-forwarding rule is not present). Yes, looks like it. > Steps to Reproduce: I played with it for some time. I've tried to make the configuration as similar as possible to yours, but I still can't reproduce the problem with firewalld-0.3.9.3-1.fc19 (In reply to Rok Mandeljc from comment #3) > Created attachment 876343 [details] > Output of iptables-save with firewalld-0.3.9.3-1.fc19 I can't see any problem there, the masquerading seems to be ok: *nat -A PREROUTING -j PREROUTING_ZONES -A POSTROUTING_ZONES -o ens192 -g POST_public -A POST_public -j POST_public_allow -A POST_public_allow ! -i lo -j MASQUERADE *filter -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD_OUT_ZONES -g FWDO_public -A FWDO_public -j FWDO_public_allow -A FWDO_public_allow -j ACCEPT Could you attach xml files from /etc/firewalld/services/ ? (primarily public.xml and work.xml)
I think I found the source of my problem - the masquerading should have been enabled on 'work', not on 'public'. Judging by the changelog, the old configuration probably worked in 0.3.8-1 due to #1057875 and 'public' being the default zone... After making the above change, port forwarding works as expected. Sorry for the noise.