Shorewall users - Apr 2004 - DNAT Rules work for a bit, then all fail

Hey Guys

  To start, I''m not on the mailing list, so if you could CC my
  address, that''d be great.

  I''ve found Shorewall very useful, made my life a lot easier when it
  comes to setting up rules, however I''ve come into a little bit of a
  situation.

  Our firewall has a number of static IPs going through one interface
  (to the world), and the internal network on another one... (fairly
  standard setup). We have a number of virtual domains connecting to
  the different IP addresses, and forwarded to the respective hosts on
  the internal network. One of the IP addresses handles forwarding
  SMTP, and http on to our exchange server for webmail, and SMTP. The
  situation has arisen recently to introduce an SMTP gateway for the
  exchange server because of the influx of viruses and spam.

  As we already had it in house, just not yet implemented, we have
  setup the smtp-gateway using symantec''s software, all is running
  well in that regards.

  Now the problem... I alter the rules to point the SMTP connection
  that was pointing to the exchange server, on to the smtp-gateway...
  all works well, webmail stays running, and our other dnat''d
  connections continue to work... for about an hour or so... then ALL
  the dnat''d addresses all fail while the rest of the rules (masq,
  accept, deny, etc) all continue to operate correctly.

  On checking the logs when making an attempt to connect to the dnat''d
  ports/ips, nothing appears, no rejections, no denies, nothing.  He
  is a summary of the rules:

  /etc/shorewall/rules

#
## Forward SMTP to gateway
#
DNAT        net     loc:172.16.10.80        tcp     smtp    -    xx.xx.xx.xx

#
## Forward webmail ##
#
DNAT        net     loc:172.16.10.15        tcp     www     -   xx.xx.xx.xx

#
## Forward IMAP requests
#
DNAT        net     loc:172.16.10.15        tcp     imap    -   xx.xx.xx.xx

Now these all hit the same interface/ip on the outside (replaced
origdest with xx.xx.xx.xx for security)... The other DNAT rules look
similar to the one for www just point to different internal IP
addresses, and a different origdest).  I cannot find anything that
says this kind of setup cannot be done, and the fact it works for a
bit seems to suggest it is supposed to work, but I cannot work out why
it just... stops... any hints? Any points where I can start working on
this issue?  Getting a lot of heat from people higher up wanting a
working system ASAP, they''re even considering moving to a checkpoint
firewall.

Thanks in advanced
  
-- 
Jonathan Angliss
(jon@netdork.net)

Objects in taglines are closer than they appear.

Jonathan Angliss wrote:
> ## Forward IMAP requests
> #
> DNAT        net     loc:172.16.10.15        tcp     imap    -   xx.xx.xx.xx
> 
> Now these all hit the same interface/ip on the outside (replaced
> origdest with xx.xx.xx.xx for security)... The other DNAT rules look
> similar to the one for www just point to different internal IP
> addresses, and a different origdest).  I cannot find anything that
> says this kind of setup cannot be done, and the fact it works for a
> bit seems to suggest it is supposed to work,
It *does* work --  One more time; Shorewall-created rules are static; 
once in place they don''t change so unless you are using rate-limiting
in
your rules somewhere, there is nothing in a Shorewall-created Netfilter 
configuration that can cause rules to suddenly stop working.

Two suggestions:

a) Check your logs for connection-tracking table full messages.
b) Otherwise, you have to troubleshoot this just like any other port 
forwarding problem; Shorewall FAQs 1a and 1b should be helpful.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

Tom Eastep wrote:
> 
> Two suggestions:
> 
> a) Check your logs for connection-tracking table full messages.
> b) Otherwise, you have to troubleshoot this just like any other port 
> forwarding problem; Shorewall FAQs 1a and 1b should be helpful.
> 
One more idea -- more that one NIC attached to the same hub/switch can 
cause things to suddenly stop working although it usually doesn''t take 
an hour (because systems'' ARP caches usually have a much shorter
timeout).

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net