Hello alll,
I have been using and bragging about Shorewall for a while now. Normally
I find reading the documentation and trial and error to be sufficent to
solve any problems I have but now I am stumped!
I encountered a problem that demanded all www access to one machine
(''server'') be redirected to another (''crg'').
All other access needed
to remain as is. This was needed immediately.
I apologize in advance for the lengthy email, I wanted to make sure all
the necessary details were in it. My configuration files are a bit large
and I wanted to avoid subjecting all to them, except as needed.
If anyone can suggest what I am doing wrong, of perhaps what I tried to
do is not easily done.
** The Solution Attempted
A diagram of the system before any change follows. I have indicated the
applicable shorewall configuration files that are in effect and the
order I beleive they are processed.
net -> [nat] -> [rules] -> crg
-> [rules] -> server
Where:
[nat] = /etc/shorewall/nat - Static Nat Translation
[rule] = /etc/shorewall/rule - routing rules
The desired configuration is:
net -> [nat] -> [rules] -> crg
-> [rules]
-> server:80,443 -> crg
-> server:* -> server (imap, pop3, etc.)
Note that I am stilling doing nat translation on ''server'' via
the [nat]
file and then doing DNAT on server:80 via [rules]
My first step was to upgrade to Shorewall 1.3.1 (from 1.2.17) to get
the easier to use DNAT capability.
I also recompiled iptables from 1.2.3 to 1.2.4
I added the following to my [rules] file (one of the first entries):
DNAT:INFO net public:192.168.1.10 tcp http,https - 192.168.1.11
Where all addresses are AFTER static NAT translation:
192.168.1.10 = crg
192.168.1.11 = server
public = the interface these servers are on
It did work just fine for my internal networks (not shown above), which
does NOT use the ''nat'' file. An example of one of these is:
DNAT:INFO local public:192.168.1.10 tcp http,https - 192.168.1.11
But to my surprise and confusion this did not work as I expected from
the ''net''.
The shorewall logs indicated that local->server:80 worked perfectly, but
net->server:80 never encountered the DNAT rule. It appeared to bypass
the rule and proceed to the general rule (later in my file) of:
ACCEPT net public tcp http,https
I also noticed that all ''net'' access to crg (192.168.1.10)
triggered a
DNAT log in shorewall! This was also unexpected. No such log entry was
triggered by internal access. Swapping the .10 and .11 address for the
DNAT yielded yet a different log entry. Now accessing crg did not
generate a DNAT entry but accessing server did! Yet, as expected from
the rule files documentation, the DNAT did NOT takes place.
I also tried setting NAT_BEFORE_RULES to ''No'' (it''s
default is ''Yes'')
but that didn''t seem to help. Should it have?
*** Work Around Solution:
In desperation I disabled NAT translation (in nat) for
''server'' and
simulated them via DNAT entries in the rule file. This is a bit messy
but it worked perfectly.
DNAT:INFO net public:192.168.1.10 tcp http,https - SERVER-IP
DNAT:INFO net public:192.168.1.11 tcp imap,smpt,pop3 - SERVER-IP
DNAT:INFO net public:192.168.1.11 tcp 137:139 - SERVER-IP
etc....
Where ''SERVER-IP'' is the public (outside the firewall) IP of
''server''.
The network isn
net -> [nat] -> [rules] -> crg
-> [rules] -> server
-> server-public:80,443
-> crg-private
-> server-public:imap,pop3,etc
-> server-private
*** Conclusions
So my conclusions of all this are:
* For some reason combining nat translation via the [nat] file and
DNAT via [rules] is NOT a good idea!!!
* There is something I am missing...
I have not yet tried ProxyArp as I am not familiar with it. After I read
up on it I may try that.
What would be nice for cases like this is a re-direct IP-A:Port -> IP-B
and fall through to normal rule processing for IP-B. This keeps all the
security already setup (such as preventing access from some IPs, etc.)
without having to duplicate them. Especially handy when a server needs
to be temporarily redirected to a backup one while the original is being
reconfigured. Doubly handy when the reconfiguration is NOT a planned
event (and when the server supports virtual hosts).
Actually now that I think about it ... Firewall applies all IP-A rules,
then maps IP-A -> IP-B (and firewall optionally proceeds to check IP-B
rules for security). Probably a bit over-the-top for most needs!
Thanks for reading,
Robb
My previously posted solution to my problem is VERY wrong. It worked well enough for incoming data but failed to handle my server sending mail (no mapping from internal to external IP). After reading iptables documents I came up with a very simple solution that keeps all my other stuff unchanged! I am providing this in case it helps anyone else with a similar problem. By doing this NO other changes to my existing configuration was necessary. Once ''server'' is repaired/upgraded I can comment out the lines or remove [init] and everything goes back to normal. If anyone has an easier way or a Shorewall only please share it. /etc/shorewall/init # # Shorewall init file # # Emergency re-routing of HTTP/S requests from Server to CRG Done here # since it proved impossible to do this in rules # # Overview: [nat] file is processed BEFORE DNAT actions in [rules] and # [rules] cannot specify global SNAT! And even if the DNAT entries in # [rules] is processed before [nat] [rules] are NOT added to PREROUTING # and [nat] is so [rules] still happened after [nat]! # The above is my best guess so far. Shorewall is rather complex so I # may (probably) missed something that would have helped me. # # <robb@canfield.com> # use Shorewall''s run_iptables command so it can capture and deal with errors # Use -I to force these to the top, in case Shorewall did something else before us # External references to server run_iptables -t nat -I PREROUTING -j DNAT -d 206.124.157.35 --to 192.168.1.10 -p tcp --dport http run_iptables -t nat -I PREROUTING -j DNAT -d 206.124.157.35 --to 192.168.1.10 -p tcp --dport https # To keep it all together also do the internal network stuff here run_iptables -t nat -I PREROUTING -j DNAT -d 192.168.1.11 --to 192.168.1.10 -p tcp --dport http run_iptables -t nat -I PREROUTING -j DNAT -d 192.168.1.11 --to 192.168.1.10 -p tcp --dport https On Wed, 26 Jun 2002, Robb Canfield wrote:> Hello alll, > > I have been using and bragging about Shorewall for a while now. Normally > I find reading the documentation and trial and error to be sufficent to > solve any problems I have but now I am stumped! > > I encountered a problem that demanded all www access to one machine > (''server'') be redirected to another (''crg''). All other access needed > to remain as is. This was needed immediately. > > I apologize in advance for the lengthy email, I wanted to make sure all > the necessary details were in it. My configuration files are a bit large > and I wanted to avoid subjecting all to them, except as needed. > > If anyone can suggest what I am doing wrong, of perhaps what I tried to > do is not easily done. > > ** The Solution Attempted > > A diagram of the system before any change follows. I have indicated the > applicable shorewall configuration files that are in effect and the > order I beleive they are processed. > net -> [nat] -> [rules] -> crg > -> [rules] -> server > > Where: > [nat] = /etc/shorewall/nat - Static Nat Translation > [rule] = /etc/shorewall/rule - routing rules > > The desired configuration is: > net -> [nat] -> [rules] -> crg > -> [rules] > -> server:80,443 -> crg > -> server:* -> server (imap, pop3, etc.) > > Note that I am stilling doing nat translation on ''server'' via the [nat] > file and then doing DNAT on server:80 via [rules] > > My first step was to upgrade to Shorewall 1.3.1 (from 1.2.17) to get > the easier to use DNAT capability. > > I also recompiled iptables from 1.2.3 to 1.2.4 > > I added the following to my [rules] file (one of the first entries): > DNAT:INFO net public:192.168.1.10 tcp http,https - 192.168.1.11 > > Where all addresses are AFTER static NAT translation: > 192.168.1.10 = crg > 192.168.1.11 = server > public = the interface these servers are on > > It did work just fine for my internal networks (not shown above), which > does NOT use the ''nat'' file. An example of one of these is: > DNAT:INFO local public:192.168.1.10 tcp http,https - 192.168.1.11 > > But to my surprise and confusion this did not work as I expected from > the ''net''. > > The shorewall logs indicated that local->server:80 worked perfectly, but > net->server:80 never encountered the DNAT rule. It appeared to bypass > the rule and proceed to the general rule (later in my file) of: > ACCEPT net public tcp http,https > > I also noticed that all ''net'' access to crg (192.168.1.10) triggered a > DNAT log in shorewall! This was also unexpected. No such log entry was > triggered by internal access. Swapping the .10 and .11 address for the > DNAT yielded yet a different log entry. Now accessing crg did not > generate a DNAT entry but accessing server did! Yet, as expected from > the rule files documentation, the DNAT did NOT takes place. > > I also tried setting NAT_BEFORE_RULES to ''No'' (it''s default is ''Yes'') > but that didn''t seem to help. Should it have? > > *** Work Around Solution: > > In desperation I disabled NAT translation (in nat) for ''server'' and > simulated them via DNAT entries in the rule file. This is a bit messy > but it worked perfectly. > > DNAT:INFO net public:192.168.1.10 tcp http,https - SERVER-IP > DNAT:INFO net public:192.168.1.11 tcp imap,smpt,pop3 - SERVER-IP > DNAT:INFO net public:192.168.1.11 tcp 137:139 - SERVER-IP > etc.... > > Where ''SERVER-IP'' is the public (outside the firewall) IP of ''server''. > > The network isn > net -> [nat] -> [rules] -> crg > -> [rules] -> server > -> server-public:80,443 > -> crg-private > -> server-public:imap,pop3,etc > -> server-private > > *** Conclusions > > So my conclusions of all this are: > * For some reason combining nat translation via the [nat] file and > DNAT via [rules] is NOT a good idea!!! > * There is something I am missing... > > I have not yet tried ProxyArp as I am not familiar with it. After I read > up on it I may try that. > > What would be nice for cases like this is a re-direct IP-A:Port -> IP-B > and fall through to normal rule processing for IP-B. This keeps all the > security already setup (such as preventing access from some IPs, etc.) > without having to duplicate them. Especially handy when a server needs > to be temporarily redirected to a backup one while the original is being > reconfigured. Doubly handy when the reconfiguration is NOT a planned > event (and when the server supports virtual hosts). > > Actually now that I think about it ... Firewall applies all IP-A rules, > then maps IP-A -> IP-B (and firewall optionally proceeds to check IP-B > rules for security). Probably a bit over-the-top for most needs! > > Thanks for reading, > Robb > > > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@shorewall.net > http://www.shorewall.net/mailman/listinfo/shorewall-users >
On Wed, 26 Jun 2002, Robb Canfield wrote:> Hello alll, > > I have been using and bragging about Shorewall for a while now. Normally > I find reading the documentation and trial and error to be sufficent to > solve any problems I have but now I am stumped! > > I encountered a problem that demanded all www access to one machine > (''server'') be redirected to another (''crg''). All other access needed > to remain as is. This was needed immediately. > > I apologize in advance for the lengthy email, I wanted to make sure all > the necessary details were in it. My configuration files are a bit large > and I wanted to avoid subjecting all to them, except as needed. > > If anyone can suggest what I am doing wrong, of perhaps what I tried to > do is not easily done. > > ** The Solution Attempted > > A diagram of the system before any change follows. I have indicated the > applicable shorewall configuration files that are in effect and the > order I beleive they are processed. > net -> [nat] -> [rules] -> crg > -> [rules] -> server > > Where: > [nat] = /etc/shorewall/nat - Static Nat Translation > [rule] = /etc/shorewall/rule - routing rules > > The desired configuration is: > net -> [nat] -> [rules] -> crg > -> [rules] > -> server:80,443 -> crg > -> server:* -> server (imap, pop3, etc.) > > Note that I am stilling doing nat translation on ''server'' via the [nat] > file and then doing DNAT on server:80 via [rules] >That''s not the way it works. Entries in the nat file generate a DNAT rule and a matching SNAT rule in the nat table. The SNAT rule deals with outbound connections so is not relevant to your situation. DNAT rules in the rules file generate a DNAT rule in the nat table and an ACCEPT rule in the filter table. The ACCEPT rule is expressed in terms of the destination address after DNAT has occurred. The DNAT rules in the nat table are applied before the filter rules in the filter table. Normally, nat table DNAT rules generated from the nat file come before the rules generated by DNAT entries in the rules file. As always with iptables, the first matching rule determines the outcome and following rules are ignored. So by default, entries in the nat file take precedence over those from the rules file. Also, DNAT only gets applied once (first matching rule wins). Your interpretation had it happening twice (once for the nat entry and one for the rules entry). In 1.2.13, a new NAT_BEFORE_RULES variable was added in shorewall.conf. This variable was added to handle situations exactly like yours. If you set NAT_BEFORE_RULES=No then the DNAT rules generated from the rules file come before those generated by the nat file. That way, you can choose those connections that you want to be redirected to another system and the rest will be redirected as specified in the nat file. Remember that in both files, the original destination address is the network IP address. Hope this helps -- I''ll be out of town for a few days and won''t be able to respond further. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net
Tom Eastep
2002-Jun-30 14:15 UTC
NAT_BEFORE_RULES=No Broken!!! ( Was [Shorewall-users] NAT and DNAT?)
Robb pointed out that he tried NAT_BEFORE_RULES=No and that didn''t work
for him. I tried it out this morning and it didn''t work for me either
:-(
Seems that I had broken it in one of the 1.3.0-pre releases.
There''s a corrected version of the firewall script at:
http://www.shorewall.net/pub/shorewall/errata/1.3.2/firewall
Just a reminder that the corrected version will not work with either 1.3.0
or 1.3.1 -- you must upgrade to 1.3.2 to use it.
-Tom
--
Tom Eastep \ Shorewall - iptables made easy
AIM: tmeastep \ http://www.shorewall.net
ICQ: #60745924 \ teastep@shorewall.net