I''ve upgraded a 3-interface system from 2.0.8 to 3.2.6 on Debian, and I''m not able to make DNAT work anymore. If someone could offer a suggestion of where to look to fix this, it would be very much appreciated. Problem Summary: If I set DETECT_DNAT_IPADDRS=Yes, then I can''t access anything on my DMZ via DNAT. If I set DETECT_DNAT_IPADDRS=No, then **EVERYTHING** (all web pages, anyway) get redirected to my web server on my DMZ. Problem Example: DETECT_DNAT_IPADDRS=Yes: I can access http://www.slashdot.com from my loc computers just fine, but accessing http://www.NerdWorld.org (on my DMZ) fails with a time-out. DETECT_DNAT_IPADDRS=No: I can access my web server on my DMZ, but if I try to access slashdot (http://www.slashdot.com), it loads a page on NerdWorld.org instead! (http://www.NerdWorld.org) My setup is classic 3-interface. eth0 is DHCP to my cable modem. eth1 is my dmz at 192.168.2.0/24, while eth2 is loc at 192.168.1.0/24. I have a web server, mail server, and DNS servers on the dmz. Workstations are on loc. I cut and pasted most of my "rules" from the old system to the new system, so I don''t think I''ve introduced a typo in the configuration files. Obviously, I''ve got some parameter messed up in shorewall.conf, but I can''t figure out what it is. I''m frankly a little confused by some of the new parameters in shorewall.conf (or at least, confused by things I never had to figure out before <sigh>) shorewalldump is enclosed. Thanks for the help! -- Casey Bralla Chief Nerd in Residence The NerdWorld Organisation ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Casey Bralla wrote:> My setup is classic 3-interface.What are you trying to accomplish with the loc->dmz DNAT rules? If you are trying to make connections to your external IP address go to the DMZ then you need to put your external IP address in the ORIG DEST column. Possibly you are doing that using a variable but if so, the variable is empty. One possibility -- in Shorewall 2.0.8, there was a function called find_interface_address(). In 3.2.6, that function is named find_first_interface_address(). You may be suffering a ''command not found'' error that is getting lost in the noise (or in that most questionable of Debian ideas, the /var/log/shorewall-init.log file). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, Nov 21, 2007 at 07:44:24AM -0800, Tom Eastep wrote:> (or in that most questionable of > Debian ideas, the /var/log/shorewall-init.log file).What''s wrong with it? It''s essential to debugging a headless server that won''t boot cleanly. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Andrew Suffield wrote:> On Wed, Nov 21, 2007 at 07:44:24AM -0800, Tom Eastep wrote: >> (or in that most questionable of >> Debian ideas, the /var/log/shorewall-init.log file). > > What''s wrong with it? It''s essential to debugging a headless server > that won''t boot cleanly.The problem with it is that the average Debian Shorewall user has no clue that it exists. That coupled with use of /etc/init.d/shorewall rather than /sbin/shorewall leads to additional cluelessness. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, Nov 21, 2007 at 09:00:20AM -0800, Tom Eastep wrote:> Andrew Suffield wrote: > > On Wed, Nov 21, 2007 at 07:44:24AM -0800, Tom Eastep wrote: > >> (or in that most questionable of > >> Debian ideas, the /var/log/shorewall-init.log file). > > > > What''s wrong with it? It''s essential to debugging a headless server > > that won''t boot cleanly. > > The problem with it is that the average Debian Shorewall user has no clue > that it exists. That coupled with use of /etc/init.d/shorewall rather than > /sbin/shorewall leads to additional cluelessness.I suppose there''s no accounting for idiots... still, I don''t see how it could hurt to have it there. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, Nov 21, 2007 at 05:59:38PM +0000, Andrew Suffield wrote:> On Wed, Nov 21, 2007 at 09:00:20AM -0800, Tom Eastep wrote: > > Andrew Suffield wrote: > > > On Wed, Nov 21, 2007 at 07:44:24AM -0800, Tom Eastep wrote: > > >> (or in that most questionable of > > >> Debian ideas, the /var/log/shorewall-init.log file). > > > > > > What''s wrong with it? It''s essential to debugging a headless server > > > that won''t boot cleanly. > > > > The problem with it is that the average Debian Shorewall user has no clue > > that it exists. That coupled with use of /etc/init.d/shorewall rather than > > /sbin/shorewall leads to additional cluelessness. > > I suppose there''s no accounting for idiots... still, I don''t see how > it could hurt to have it there. >I am in agreement with Andrew. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wednesday 21 November 2007 10:44:24 am Tom Eastep wrote:> Casey Bralla wrote: > > My setup is classic 3-interface. > > What are you trying to accomplish with the loc->dmz DNAT rules? If you are > trying to make connections to your external IP address go to the DMZ then > you need to put your external IP address in the ORIG DEST column. Possibly > you are doing that using a variable but if so, the variable is empty. > > > -TomThanks for your help, Tom. Adding the ORIG DEST made it work! BTW, the loc->dmz NAT rule is to allow my local clients to access my web pages **exactly** like external clients on the internet using the same IP address, which is the dhcp address assigned by comcast. -- Casey Bralla Chief Nerd in Residence The NerdWorld Organisation ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Wed, Nov 21, 2007 at 09:00:20AM -0800, Tom Eastep wrote:> Andrew Suffield wrote: > > On Wed, Nov 21, 2007 at 07:44:24AM -0800, Tom Eastep wrote: > >> (or in that most questionable of > >> Debian ideas, the /var/log/shorewall-init.log file). > > > > What''s wrong with it? It''s essential to debugging a headless server > > that won''t boot cleanly. > > The problem with it is that the average Debian Shorewall user has no clue > that it exists.On reflection, while this may not be a direct problem, there''s no good reason for the difference between the Debian and upstream versions here. This (approximate) behaviour would be beneficial to non-Debian users as well, and could be improved upon. The basic objective is this: get ''shorewall start'' to be completely silent unless an error occurs (because we don''t need to see all those progress messages as part of the normal boot sequence), and simultaneously dump the full startup chatter into a log file so that the sysadmin can examine it later if necessary. To accomplish this, two alterations to shorewall would be necessary: First, a new argument that specifies an absolute verbosity level, rather than being dependant on the contents of shorewall.conf: ''shorewall -v=-1'' or something, rather than having to say ''shorewall -qqqqq'' and hoping that the config file''s verbosity is set no higher than 4. Secondly, an optional log file defined in shorewall.conf, with its own verbosity level. I''m thinking of something like this: progress_message() { local timestamp if [ $VERBOSE -gt 1 ]; then [ -n "$TIMESTAMP" ] && timestamp="$(date +%H:%M:%S) " echo "${timestamp}$@" fi if [ $LOG_VERBOSE -gt 1 ]; then timestamp="$(date +%H:%M:%S) " echo "${timestamp}$@" >> $STARTUP_LOG fi } and so on in the other functions. Then vendors simply ship a default config file that names a suitable log file, and use the silent form in the init script. This also has the secondary benefit that all shorewall behaviour is logged, rather than just the bits from the init script, so you can look at the log at any time and see the most recent output. You could even have ''shorewall dump'' grab it. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Fri, 2007-11-23 at 16:39 +0000, Andrew Suffield wrote:> > On reflection, while this may not be a direct problem, there''s no good > reason for the difference between the Debian and upstream versions > here. This (approximate) behaviour would be beneficial to non-Debian > users as well, and could be improved upon.I''ll hack up something along these lines for 4.1.2. Thanks, Andrew -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
On Fri, 2007-11-23 at 16:39 +0000, Andrew Suffield wrote:> Secondly, an optional log file defined in shorewall.conf, with its own > verbosity level. > I''m thinking of something like this: > > progress_message() > { > local timestamp> > if [ $VERBOSE -gt 1 ]; then > [ -n "$TIMESTAMP" ] && timestamp="$(date +%H:%M:%S) " > echo "${timestamp}$@" > fi > > if [ $LOG_VERBOSE -gt 1 ]; then > timestamp="$(date +%H:%M:%S) " > echo "${timestamp}$@" >> $STARTUP_LOG > fi > } > > and so on in the other functions. Then vendors simply ship a default > config file that names a suitable log file, and use the silent form in > the init script. > > This also has the secondary benefit that all shorewall behaviour is > logged, rather than just the bits from the init script, so you can > look at the log at any time and see the most recent output. You could > even have ''shorewall dump'' grab it.In some cases, it would be desirable to have the compiler output placed in the STARTUP_LOG as well: shorewall start, shorewall restart, shorewall refresh, shorewall try, shorewall safe-start, shorewall save-restart There are other cases where it would not be desirable: shorewall {compile|check} (especially by a user other than root), shorewall load, shorewall reload So it looks like we also need to add a couple of options to the compilers to specify the log file and verbosity. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/