Setting up an iptables firewall - Revision history

123.50.64.151: Moved link to HN definition at its first occurence, for anyone confused by the acronym

2019-07-13T21:52:43Z

Moved link to HN definition at its first occurence, for anyone confused by the acronym

195.50.210.9: /* Setting up a firewall that allows per-container configuration */

2015-12-08T16:41:55Z

‎Setting up a firewall that allows per-container configuration

195.50.210.9: /* Setting up a firewall that allows per-container configuration */

2015-12-08T16:38:51Z

‎Setting up a firewall that allows per-container configuration

Homeless Guy: /* Simple firewall configuration independent to IP addresses: vzfirewall */

2013-10-10T13:15:00Z

‎Simple firewall configuration independent to IP addresses: vzfirewall

Narcisgarcia: /* See also */ Frank Taveras

2013-06-13T09:52:14Z

‎See also: Frank Taveras

Narcisgarcia: /* Setting up a firewall that allows per-container configuration */

2013-06-13T09:50:37Z

‎Setting up a firewall that allows per-container configuration

Iandunn: /* Setting up a HN-based firewall */ added the URL to the wiki page to the script so that people will know where it came from

2012-03-19T18:19:19Z

‎Setting up a HN-based firewall: added the URL to the wiki page to the script so that people will know where it came from

Iandunn: /* Setting up a HN-based firewall */ Added note about creating a copy of the container config file for each IP the container has assigned

2011-12-27T19:23:43Z

‎Setting up a HN-based firewall: Added note about creating a copy of the container config file for each IP the container has assigned

Kir: Reverted edits by 89.108.162.5 (talk) to last revision by 74.190.203.80

2011-11-28T05:26:41Z

Reverted edits by 89.108.162.5 (talk) to last revision by 74.190.203.80

Show changes

89.108.162.5: /* Setting up a HN-based firewall */

2011-11-28T04:18:18Z

‎Setting up a HN-based firewall

Show changes

← Older revision		Revision as of 21:52, 13 July 2019
Line 1:		Line 1:
−	This document consists of two parts. The first is setting up a firewall (using iptables) on the HN, which will restrict traffic to the containers. The effect would emulate, as far as the containers and their customers are concerned, an external hardware firewall controlled by the sysadmin. The second is setting up a firewall that protects the [[HN]] itself but still allows traffic to the containers, thus allowing individual containers to define their own iptables.	+	This document consists of two parts. The first is setting up a firewall (using iptables) on the [[HN]], which will restrict traffic to the containers. The effect would emulate, as far as the containers and their customers are concerned, an external hardware firewall controlled by the sysadmin. The second is setting up a firewall that protects the HN itself but still allows traffic to the containers, thus allowing individual containers to define their own iptables.

	While the firewalls shown here can be accomplished using iptables manually (or using Fedora core's iptables service), the methods presented here are especially modular and easy to modify. This is important when you have 20+ containers and a lot of other things to be doing...		While the firewalls shown here can be accomplished using iptables manually (or using Fedora core's iptables service), the methods presented here are especially modular and easy to modify. This is important when you have 20+ containers and a lot of other things to be doing...

← Older revision		Revision as of 16:41, 8 December 2015
Line 255:		Line 255:


−	Above information is outdated, to enable iptables you need to make sure that CT.conf(CT - id of your container, 100 for example) contains NETFILTER="full" ~~line.~~ When this done, you should reboot your container and iptables should work properly.	+	Above information is outdated, to enable iptables you need to make sure that CT.conf(CT - id of your container, 100 for example) contains following line:
		+
		+	<pre>
		+	NETFILTER="full"
		+	</pre>
		+
		+	When this done, you should reboot your container and iptables should work properly.

	== See also ==		== See also ==

@@ Line 253: / Line 253: @@
 modprobe xt_state
 </pre>
 == See also ==

@@ Line 11: / Line 11: @@
 The exception to this is the nameserver, which we want open to the world. We use it as a caching nameserver for our containers and also to host DNS for a few customer domain.
-== Simple firewall configuration independent to IP addresses: vzfirewall ==
+== Simple firewall configuration independent of IP addresses: vzfirewall ==
-<code>Vzfirewall</code> tool allows you to open/close ports for incoming connections with no dependencies to foreign IP addresses. E.g. you may allow a hostname <code>release.prod.example.com</code> to connect to port 5432 of VE 1234 and leave all other ports closed by modifying <code>1234.conf</code> file adding multiline <code>FIREWALL</code> directive into it:
+<code>Vzfirewall</code> tool allows you to open/close ports for incoming connections with no dependencies to foreign IP addresses. E.g. you may allow a hostname <code>release.prod.example.com</code> to connect to port 5432 of VE 1234 and leave all other ports closed by modifying <code>1234.conf</code> file adding multiline <code>FIREWALL</code> directives into it:
 <pre>
@@ Line 33: / Line 33: @@
 You must then run <code>vzfirewall -a</code> on your hardware node to apply changes made in <code>*.conf</code>.
-Note that it is recommended to use hostnames instead of IP addresses here, so the configuration is persistent for VE movements to different IP-address: you just need to run <code>vzfirewall -a</code> again after movement. It is also reboot-safe, because applied to <code>/etc/sysconfig/iptables</code> (at RHEL systems).
+Note that it is recommended to use hostnames instead of IP addresses here, so the configuration is persistent for VE movements to different IP-address: you just need to run <code>vzfirewall -a</code> again after movement. It is also reboot-safe, as the rules are applied to <code>/etc/sysconfig/iptables</code> (at RHEL systems).
 Vzfirewall and its documentation are available at [http://en.dklab.ru/lib/dklab_vzfirewall/ http://en.dklab.ru/lib/dklab_vzfirewall/].

← Older revision		Revision as of 09:52, 13 June 2013
Line 257:		Line 257:

	* [[Traffic accounting with iptables]]		* [[Traffic accounting with iptables]]
		+	* [http://www.readymakers.com/blog/how-to-enable-iptables-in-openvz-container/ How to enable IPtables in OpenVZ container] (Frank Taveras) - Lack of modprobe modules on HN.

	[[Category: Networking]]		[[Category: Networking]]

← Older revision		Revision as of 09:50, 13 June 2013
Line 240:		Line 240:

	If you do not, you will get an error like this: "iptables: No chain/target/match by that name"		If you do not, you will get an error like this: "iptables: No chain/target/match by that name"
		+	* Note: xt_tcpudp module seem to be included in the kernel packages of Debian 6, but not of CentOS 6.

	If you want to use stateful firewall rules (and you should!) you will also need to make sure that 'ipt_state' is in the 'IPTABLES' option in your vz.conf file:		If you want to use stateful firewall rules (and you should!) you will also need to make sure that 'ipt_state' is in the 'IPTABLES' option in your vz.conf file:

@@ Line 65: / Line 65: @@
 # /etc/firewall.d to set up additional rules in the FORWARD chain
 # to allow access to containers' services.
 . /etc/init.d/functions

@@ Line 190: / Line 190: @@
 </pre>
-And there you go. Go ahead and start the firewall and check its status:
+And there you go.
 <pre>
 service firewall restart