Re: Not firewall, but what?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 05/10/2010 08:09 PM, Jussi Hirvi wrote:
> Hm, NAT might be difficult, because there are common ports to the guest 
> systems. 

Yeah, but they're going to have different IP addresses and we could do
NAT around that.  My personal preference is to put a router between
external interfaces (with non-RFC1918 addresses) and my internal network
(even a DMZ).  I'd then use NAT to map the external ipaddr:port pairs to
internal ipaddr:port pairs.  If your hosts need SSL, I'd add dnsmaq to
the mix so internally your guests FQDNs resolve to  internal addresses,
whereas externally their FQDNs resolve to the external addresses.

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'm using shorewall to configure iptables to do
the NAT so everything is clean and clear and my firewalls can be very
restrictive.  Haven't got a spare router?  Well your xen-host _can_ be
the router.

> Below is more detail:
> 
> If we say network
> 	A = 62.220.237.x and
> 	B = 62.236.221.x
> 
> My guest systems are:
> - name server (port 53) (network B)
> - mail server (80,443,25,465,995.993,563,636) (network A)
> - secondary mail server to a mail server in another box (25,465)
> 	(preferably network A AND B, for maximum availability)
> - a test system, can be in either network (but port 22 required)
> 
> Of course I could rearrange, for example set up another xen box for one 
> of these mail servers.

Okay, and you name server 62.236.221.71 (?) is the one causing problems?

If I was starting from scratch, I'd be giving you guests IP addresses
192.168.0.1-5 and put them all on the same bridge.  I'd then use NAT on
the xen-host to map the external IPs to internal and forward them to the
bridge.  Not strictly necessary but cleaner to my mind.

My guess is requests coming in on network B and responses leaving by
network A.  This will confuse the heck out of the recipient 'cause it
mixes up the SRC and DST headers.  The solution to this is policy-based
routing.  Basically we set things up to use different routing tables
depending on the source address of the packet.  Here's a pointer to some
reading that should get you up to speed.

http://www.policyrouting.org/PolicyRoutingBook/ONLINE/TOC.html

Lots of good stuff in there and well work the read.

Hope this helps,

Kal

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux