On 11/05/10 10:40, Gordon Messmer wrote:
On 05/10/2010 06:20 AM, Kahlil Hodgson wrote:
This gives me a very clean and clear separation between inside my network and outside, and no one outside my network is going to see my RFC1918 address space.
I weep every time I see someone advocate NAT for security reasons. It's ridiculous.
I agree 100% and was not the intent of the comment. This is more an organisational approach based on what I've seen and done in the past. Being organised does contribute to security ;-)
Routing policy is definitely required for a multi-homed system such as Jussi presented, but NAT is totally superfluous. It adds an extra layer of complexity that makes the system more difficult to diagnose and configure, and contributes nothing of value in return.
Now that I understand Jussi's set up a little better (all the components seem to be fully internet facing) I also agree 100% with that.
John Pierce's advice was simple and correct. If you don't want to set up ifup-post scripts of your own, you can use shorewall. Shorewall is actually more complex, but you don't have to understand much about the "ip" tool to use it.
Understanding a bit about the "ip" tool and policy-based routing (and routing in general) will help to understand the configuration you have suggested, and mapping it to his needs.
interfaces: inet eth0 - norfc1918,nosmurfs,tcpflags inet eth1 - norfc1918,nosmurfs,tcpflags lan virbr0 - dhcp
zones: fw firewall inet ipv4 lan ipv4
policy: $FW all ACCEPT inet inet DROP all inet ACCEPT all all REJECT info
providers: isp0 1 1 main eth0 62.236.221.78 track,balance isp1 2 2 main eth1 62.220.237.126 track,balance
route_rules: lo - isp0 11000 eth0 - isp0 11000 eth1 - isp1 11000 virbr0 - isp1 11000
Nice use of providers and route_rules. Only one bridge, the one that libvirtd brings up by default. Shorewall probably has to start after libvirtd for this to work. All Jussi has to do is to mod this and his xen-startup scripts to use the same bridge.
Kal