Thanks to Charles, I was able to configure my LRP/Shorewall Alix box so that it works with both a 192.168 lan and another routable lan (WAN still goes to the greater internet).
Back on November 4, I had offered: > "I'll be happy to write a web page describing it all for the documentation > pages > if anybody is interested." That offer is still valid. Is there a particular template people would like me to use or should I just start writing a web page documenting this? The idea is to document which shorewall files need to be dicked and approximately what content should go in each one. Thanks, especially to Charles, for the help. Bill Dudley On 11/5/10, wfdudley <wfdud...@gmail.com> wrote: > Charles, > > Thanks for this. I didn't expect to get an answer from the author of > Dachstein etc. > > I'll let all know how I fare. > > Bill Dudley > > > On 11/5/10, Charles Steinkuehler <char...@steinkuehler.net> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 11/4/2010 8:11 PM, wfdudley wrote: >>> I'll stop being grumpy now. >>> >>> I was just dismayed that the docs for this are, um, more diffuse that my >>> old >>> LRP install. >>> >>> I'd suggest that the floppy is way past it's time, and now its time to >>> make a LRP >>> release that assumes real storage, like a 250Meg CF card, or other solid >>> state >>> "disk drive". Then you can have the docs, a real editor, even a real >>> GUI >>> if >>> somebody gets ambitious and codes it up. >>> >>> So: my REAL problem. >>> >>> My ISP (and my employer) gives me a block of 16 public IP addresses. >>> xxx.xxx.xxx.16/28 >>> xxx.xxx.xxx.17 is the pipeline >>> xxx.xxx.xxx.18 is the WAN port on the firewall >>> The LAN port is 192.168.1.254, for laptops, Winders boxes, other stuff >>> without fixed >>> address >>> The DMZ port is xxx.xxx.xxx.16/28. The current LRP/Dachstein uses Proxy >>> Arp >>> (not bridging, I was mistaken, the m0n0wall does bridged firewall) so >>> that >>> the >>> servers on the DMZ have some ports visible to the outside world. >>> >>> The shorewall docs say "use the three port example -- unless you've got >>> multiple >>> IPs, in which case, never mind, you'll have to read all the docs". >>> I'm paraphrasing, >>> obviously. This is about when I threw up my hands. >> >> This is virtually identical to my setup here (one reason you probably >> find the DachStein scripts easy to use...I set them up to do pretty much >> exactly what you want). While I have migrated from leaf to a minimal >> debian install, I still use shorewall to create and control my firewall. >> Tom has made this *MUCH* easier and more flexible than the scripts I >> crafted back in the *Stein days. >> >> I believe part of your problem is you are trying to make things harder >> than they really are. In my setup, I use the network setup scripts (ie: >> /etc/network/interfaces and sub-scripts) to setup the basic routing, >> tell shorewall to turn on the proxy-arp flag, and that's about it. The >> low-level network setup is identical to what you have to do for >> DachStein, you're just switching to the Shorewall scripts to craft the >> ipchains/iptables rules. >> >> To provide some concrete examples: >> >> Use /etc/network/interfaces to bring up two ports with identical IP >> address and network configuration, then use the routing tables to >> control which IP addresses appear on which interfaces: >> >> # Upstream link >> auto eth0 >> iface eth0 inet static >> address 70.184.225.178 >> netmask 255.255.255.240 >> gateway 70.184.225.177 >> # Proxyarp: Add specific routes to hosts on this nic >> up ip route add 70.184.225.177/32 dev eth0 >> >> # DMZ >> auto eth2 >> iface eth2 inet static >> address 70.184.225.178 >> netmask 255.255.255.240 >> # Proxyarp: Add specific routes to hosts on this nic >> up ip route add 70.184.225.176/29 dev eth2 >> up ip route add 70.184.225.184/29 dev eth2 >> >> Note there is a single host route (the /32) to the upstream gateway, and >> everything else is sent to the DMZ interface. The two 'half network' >> routes (/29) on the DMZ interface are to override the /28 route which >> points to both interfaces and is created by default when you bring up >> the interface. >> >> Once your routing is in place, all you have to do in shorewall is add >> the proxyarp flag to the interface in the interfaces file: >> >> <snippet /etc/shorewall/interfaces> >> net eth0 detect proxyarp,tcpflags,blacklist,norfc1918 >> loc eth1 detect dhcp >> dmz eth2 detect proxyarp >> </snippet> >> >> You can now freely create shorewall rules to allow traffic through the >> firewall, ie: >> >> <snippet /etc/shorewall/rules> >> ACCEPT all dmz:70.184.225.183 tcp smtp,smtps,pop-3,imap2,imaps,www >> </snippet> >> >> - -- >> Charles Steinkuehler >> char...@steinkuehler.net >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkzUHjoACgkQLywbqEHdNFx1LgCg6pc+tTAW+6kOLVE9Mb5DL24Z >> coUAn1I+NH9Usi0Q3eHYMCPxxDNTg9wZ >> =BJNV >> -----END PGP SIGNATURE----- >> > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ------------------------------------------------------------------------ leaf-user mailing list: leaf-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
