Shorewall users - Aug 2003 - Shorewall & IPSec & NAT problems?

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url :
http://lists.shorewall.net/pipermail/shorewall-users/attachments/20030812/66d90c50/attachment-0001.bin

On Tue, 2003-08-12 at 21:06, Gregory K. Ruiz-Ade wrote:
> 
> The ''shorewall.status'' file was taken via "shorewall
status" after doing
> a "shorewall reset" and then trying to ping a remote host
(10.3.1.37)
> from the DMZ machine (10.1.4.10).
> 
What kind of IPSEC tunnel connects your firewall with 10.3.1.37 (e.g.,
net-to-net, host-to-net, ???).
>From the firewall, does "ping -I 63.113.17.131 10.3.1.37" work?
If not and you disable NAT, does the command work?

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Wednesday 13 August 2003 06:44 am, Tom Eastep wrote:
> What kind of IPSEC tunnel connects your firewall with 10.3.1.37
> (e.g., net-to-net, host-to-net, ???).
the firewall itself is connected via a host-to-net tunnel to 10.3.1.37, 
and the dmz machine via a net-to-net tunnel, as per freeswan 
convention.
> From the firewall, does "ping -I 63.113.17.131 10.3.1.37" work?
> If not and you disable NAT, does the command work?
Well, haivng just gotten though a long bashing session with iptables 
(hooray for LOG targets!) and diddling my NAT configurations, I think 
I''ve figured out the various problems.

First, I had to change "All Interfaces" and "Local
Interfaces" from yes
to no in /etc/shorewall/nat.  That had a positive effect right away.

Additionally, because I also have our IPSec web set up so that all the 
gateways have host-to-host tunnels between themselves, I had to add the 
following rule to /etc/shorewall/rules:

ACCEPT	fw	wan	udp	500	500

''wan'' is the zone name for all the IPSec-connected hosts and
subnets.
Because of the host-to-host tunnels for the gateways in IPSec, all the 
isakey packets were getting dropped/rejected by the fw2all rule 
outbound via ipsec0.  Adding the above rule fixed that.  I suppose I 
could have been more specific and created a set of rules, one for each 
gateway, like:

ACCEPT	fw	wan:$BUR_GW	udp	500	500

I''m not sure, however, if you can specify hosts in the
"destination"
column, where one usually puts/expects zones.  If I _can_ do that, I 
think I''ll go ahead and do it, just to tighten things up a bit.

So, all in all, the problem turned out to be that I had my NAT rules in 
/etc/shorewall/nat set up to do nat on all interfaces & local for the 
DMZ machines I was NATting.  Minus IPSec, that would probably work just 
fine, but IPSec introduces extra complexity.  Turns out that the packet 
was getting lost on the _remote_ IPSec gateway/firewall, because the 
rules decided it was an illegal packet (came from the IPSec VPN but 
with an external IP address, kill it.)

Now, if only I could figure out why the firewall machine doesn''t 
actually seem to want to answer on the other IP aliases I have set 
up... ("real" address of 63.113.17.130 and first alias on
63.113.17.131
work, but .132 and .134 get nothing, & nothing can ping them... 
blah....)

-- 
Gregory K. Ruiz-Ade <gkade@bigbrother.net>
OpenPGP Key ID: EAF4844B  keyserver: pgpkeys.mit.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url :
http://lists.shorewall.net/pipermail/shorewall-users/attachments/20030813/5805c90e/attachment.bin

On Wed, 2003-08-13 at 21:45, Gregory K. Ruiz-Ade wrote:
> 
> First, I had to change "All Interfaces" and "Local
Interfaces" from yes
> to no in /etc/shorewall/nat.  That had a positive effect right away.
I realized as I was getting up this morning that you probably had "Yes
Yes" in your nat file.
> 
> Additionally, because I also have our IPSec web set up so that all the 
> gateways have host-to-host tunnels between themselves, I had to add the 
> following rule to /etc/shorewall/rules:
> 
> ACCEPT	fw	wan	udp	500	500
> 
> ''wan'' is the zone name for all the IPSec-connected hosts
and subnets.
> Because of the host-to-host tunnels for the gateways in IPSec, all the 
> isakey packets were getting dropped/rejected by the fw2all rule 
> outbound via ipsec0.  Adding the above rule fixed that.  I suppose I 
> could have been more specific and created a set of rules, one for each 
> gateway, like:
> 
> ACCEPT	fw	wan:$BUR_GW	udp	500	500
> 
> I''m not sure, however, if you can specify hosts in the
"destination"
> column, where one usually puts/expects zones.  If I _can_ do that, I 
> think I''ll go ahead and do it, just to tighten things up a bit.
Or you specify "wan" as the GATEWAY ZONE in the definition of each
tunnel.
> 
> Now, if only I could figure out why the firewall machine doesn''t 
> actually seem to want to answer on the other IP aliases I have set 
> up... ("real" address of 63.113.17.130 and first alias on
63.113.17.131
> work, but .132 and .134 get nothing, & nothing can ping them... 
> blah....)
Enjoy...

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Thursday 14 August 2003 06:29 am, Tom Eastep wrote:
> I realized as I was getting up this morning that you probably had
> "Yes Yes" in your nat file.
Which, really, was a feature I would have liked to take advantage of, 
but it''s apparently not something that works well when you have to take
into account the routing between WAN/VPN segments, as well.  I could 
probably make it work that way if I wanted to set up fully dynamic 
routing between all the offices, but that''s far more work than I am 
interested in doing.
> > ACCEPT	fw	wan:$BUR_GW	udp	500	500
> Or you specify "wan" as the GATEWAY ZONE in the definition of
each
> tunnel.
Ahh... I guess I misunderstood the documentation regarding the GATEWAY 
ZONE option.  Thanks!
> > Now, if only I could figure out why the firewall machine
doesn''t
> > actually seem to want to answer on the other IP aliases I have set
And that seemed to resolve itself after bouncing ipsec.
> Enjoy...
Oh, believe me, I am.  Shorewall has saved me a tremendous amount of 
pain over some of my other options.  I''d still be writing my own shell 
scripts, probably without any of the elegance of shorewall.

Fast, simple, and efficient.  I''m very impressed.

Thanks again,

Gregory

-- 
Gregory K. Ruiz-Ade <gkade@bigbrother.net>
OpenPGP Key ID: EAF4844B  keyserver: pgpkeys.mit.edu