Mid-Summary: DNAT/PAT to multiple, public IPs instead of round-robin DNS ...

RE:  http://www.linuxmanagers.org/pipermail/linuxmanagers/2003-June/001210.html

This is a mid-solution update.  I am going to be researching this more via the LVS (Linux Virtual 
Server) and Red Hat Piranha lists and will post a final solution.  My time has been retasked at work 
recently, so it may be a week or two before I do so.

First off, thanx to the following individuals ... (and I'm sure this is not all) ...
- John Madden -- extensive DNAT and LVS correspondence, LVS recommendation
- Richard Russell -- excellent rehash of my post**, general NAT info/correspondence
- Several people -- recommend OpenBSD pf as my firewall (not against such an idea, but not a 
possibility for me)

**NOTE:  Richard made some simple ASCII art of my network -- something I should have done in 
my original post.  Here's his (which is accurate):  

Internet
   |
 router
   |
  /29
(public)
   |
firewall
   |
  /26
(public)

The "Big Issue(TM)" here is that the overwhelming majority of documentation assumes your "server 
subnet" is a private IP subnet -- both for general DNAT as well as LVS setups.  My setup is a public 
IP subnet.  It's pretty impossible for me to setup a separate private IP subnet (let alone populate it 
with servers), and I really don't want to IP alias or dual-home existing servers.

Again, I want to DNAT the firewall -- with both a /29 and /26 address -- where both subnets are 
_public_.  Here's some of the details people have made me aware of and/or still addressing/
researching:

- Solution:  DNAT does what I need on its own (it worked for me, but I still worry about the ARP 
issues)
- Solution:  LVS-NAT (which I'll simply refer to as just LVS) adds a number of features -- both 
IPTables rule management-wise as well as 
enhancements via a NetFilter module (see links/notes below on Red Hat and LVS/Piranha)
- Side-Effect:  DNAT on the firewall _may_ introduce ARP resolution issues when the server subnet 
(/26) systems try to talk to each other (big fear here as my /26 systems talk to each other 
extensively)
- Workaround:  SNAT on the firewall may address ARP resolution issues by redirecting packets 
back to the server subnet (/26) (seems plausible)
- Workaround:  Dual-home servers with a private IP subnet for talking to each other (may require 
extensive site changes -- especially in my case)
- Workaround:  LVS may address this via its NetFilter module (?) (need to research LVS more)
- Considerations:  DNAT/LVS IP address on firewall for Internet facing IP (/29) may/does need to 
be different (not an issue, I have a pair of IPs on the /29 to spare that I can alias on the firewall's 
eth0 interface)
- Correct (?):  IP address on firewall for server-facing IP (/26) should _never_ be different/multiple 
(i.e. always use single IP) so it is always the default gateway for traffic (even if traffic should stay on 
/26 subnet -- in fact, specifically to make sure there is no "alternative route" out)

If I had a spare pair of systems to put on the /26 subnet, I could probably find out with an libpcap-
app session or two.  Unfortunately I don't at this time (which is a headache for other issues).  But 
I'm going to research a bit more and find out for sure.

In the meantime I'm going to rewrite my original post and post to both the LVS and Piranha lists.

Lastly, I want to point out the following links ...

- As I mentioned in my original post, Brown's growing IP Layer Document (Chapter 5, NAT):  
  http://linux-ip.net/html/ch-nat.html  
- Back to the basic's, Rusty's "Unreliable Guides" on NAT (Destination NAT Onto the Same 
Network):  
  http://www.netfilter.org/unreliable-guides/NAT-HOWTO/NAT-HOWTO.linuxdoc-10.html  
- LVS Homepage:  
  http://www.linuxvirtualserver.org  
- Red Hat Piranha List:  
  http://www.redhat.com/mailman/listinfo/piranha-list  
- PB's Piranha/LVS info on Red Hat kernels:  
  http://baitz.com/lvs.html  
- Alex's LVS+CIPE Red Hat kernels (for 7.x and 9 wo/nptl):
  http://mail.incredimail.com/howto/lvs/install/  

Assuming I move to LVS (which I've wanted to do since I first interviewed with my current employer 
back in March), that last link looks to be my savior for getting LVS on my Red Hat boxen (assuming 
the lack of nptl doesn't break Red Hat 9 systems).  It's good to note the author of those kernels 
actually prefers (from an integration standpoint) that Red Hat has dropped Piranha support in its 
newer kernels.

Again, I'll post a final summary when I can get more definite answers for the group.

-- 
Bryan J. Smith, E.I.  mailto:[email protected]  http://thebs.org
_______________________________________________
LinuxManagers mailing list - http://www.linuxmanagers.org
submissions: LinuxManagers-35TzE1X9F6582KRnZfj+bdi2O/[email protected]
subscribe/unsubscribe: http://www.linuxmanagers.org/mailman/listinfo/linuxmanagers