Univention Bugzilla – Bug 39686
External IP routing does not work for docker guests if univention-firewall is stopped
Last modified: 2019-01-03 07:20:25 CET
If univention-firewall is shut down, all forwarding rules are removed from iptables queues. univention-firewall should recreate/keep them upon shutdown if docker resp. docker containers are running. +++ This bug was initially created as a clone of Bug #38307 +++ BEFORE: root@docker51:~# iptables -L -n -v -t nat ; iptables -L -n -v Chain PREROUTING (policy ACCEPT 12 packets, 1702 bytes) pkts bytes target prot opt in out source destination 4 240 DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL Chain INPUT (policy ACCEPT 6 packets, 520 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1 packets, 60 bytes) pkts bytes target prot opt in out source destination 1 60 DOCKER all -- * * 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL Chain POSTROUTING (policy ACCEPT 1 packets, 60 bytes) pkts bytes target prot opt in out source destination 0 0 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0 Chain DOCKER (2 references) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 367 packets, 25119 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 403 packets, 47137 bytes) pkts bytes target prot opt in out source destination root@docker51:~# FIREWALL SHUTDOWN: root@docker51:~# invoke-rc.d univention-firewall stop Stopping Univention iptables configuration::. root@docker51:~# AFTER: root@docker51:~# iptables -L -n -v -t nat ; iptables -L -n -v Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain DOCKER (0 references) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 28 packets, 1576 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 29 packets, 3404 bytes) pkts bytes target prot opt in out source destination root@docker51:~# The same problem applies to a firewall restart/start.
*** Bug 39773 has been marked as a duplicate of this bug. ***
A generic solution would be an additional packetfilter.d/ directory with scripts that are called upon firewall shutdown.
Other idea: mark all rules added by univention-firewall and in stop() remove only those. add: # iptables -A ..... -m comment --comment "${comment}" -j REQUIRED_ACTION remove with: # iptables-save | grep -v "${comment}" | iptables-restore or # iptables -S | grep "${comment}" | sed 's/^-A //' | while read rule; do iptables -D $rule; done
(In reply to Daniel Tröder from comment #3) > Other idea: mark all rules added by univention-firewall and in stop() remove > only those. Not my preferred favorite. Because currently customers can simply stop the firewall and everything is file if they messed something up. Additionally the iptables rules may get extremely faulty (e.g. kill important connections) if the firewall is stopped and only some manually added rules remain.
In my tests the stopping of the univention-firewall doesn't stop the network connections TO the containers, because the running docker processes have bound to the forwarded ports and seem to be injecting the packets into the network stack. If the docker processes are killed while the univention-firewall is running, the network is still intact, because now the iptables port-forwardings transport the packets to the containers. Without the docker daemon the univention-firewall will not be able to recreate the docker rules if restarted. But that is a situation unsupported by upstream (and us?). Anyway… the only thing broken when the univention-firewall is stopped, is the containers access to the outside. That is, because although host:/proc/sys/net/ipv4/ip_forward=1, they live in a not-routed private network. If in the host at the end of univention-firewall.stop() masquerading is add, that will be fixed. Index: base/univention-firewall/debian/univention-firewall.init =================================================================== --- base/univention-firewall/debian/univention-firewall.init (Revision 65282) +++ base/univention-firewall/debian/univention-firewall.init (Arbeitskopie) @@ -52,6 +52,7 @@ iptables -F iptables -F -t nat iptables -F -t mangle + iptables -t nat -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE ip6tables -P INPUT ACCEPT ip6tables -P OUTPUT ACCEPT IMHO as the stopping of the docker daemon is unsupported this fixes the bug.
All the port forwarding for docker apps is done with /etc/security/packetfilter.d/20_docker.sh. If the firewall is disabled (security/packetfilter/disabled=true) most of the apps wont be usable anymore. Maybe could add a way to add "unstoppable" rules to univention-firewall that are geting called even if the firewall is deactivated or gets stopped? (Like in comment 2)
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.