Shorewall users - May 2008 - Need help getting IPSEC VPN to work with Shorewall

I''ve looked at a number of docs for a couple of days now, and while
I''ve
made some progress, I''ve hit a wall that is baffling me.

I''ve attached the output of `shorewall dump` from the two machines.
Both are running CentOS 5, Shorewall 3.4.6 (I''m willing to upgrade, but
I didn''t think that the conf would be too different than 4.x, so I
wanted to get the VPN up first), and both are using the ''Red
Hat'' way of
configuring IPSEC (as you can see from the output of `shorewall dump`,
the VPN does negotiate...) and it is a network-to-network tunnel.

On one host (calling it ''host1'' in this email) when ever I try
to ping
the other network (other is 192.168.42.0, and it doesn''t matter what
host I try to ping, from what host), I get logs like the following:

Shorewall:all2all:REJECT:IN= OUT=eth0 SRC=192.168.47.1 DST=192.168.42.1
LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0
ID=55376 SEQ=1


On the other host (calling it ''host2''), I get a completely
different
log:

Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=69.30.99.148 DST=69.30.46.20
LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=25966 DF PROTO=ESP SPI=0xccd0a1c


Host1 is a Xen server, with the following network configurations:
#Interface	Xen bridge	Role/routing/forwarding
eth0		xenbr0		plain bridge, 69.30.46.0/24
dummy0		xenbr1		NAT to eth0, 192.168.47.0/24
dummy1		xenbr2		nothing, 10.42.47.0/24

Host2 is a firewall/router, with the following network configurations:
#Interface		Role/routing/forwarding
eth0			External interface, 69.30.99.0/24
eth1			Routing to eth0, 69.30.88.112/28
eth1:1			NAT to eth0, 192.168.42.0/24
eth2			Spare/unused, 172.24.20.0/24

I thought that NAT wouldn''t be involved with the VPN, but I could be
wrong, as the tunnel isn''t going through NAT but landing on the gateway
machines.  My goal is to be able to reach 192.168.42.0 from 192.168.47.0
and vice-versa.  All of the routing and NAT configurations have been
working for months, I''m just now adding in the VPN.

Any help would be appreciated, please let me know if you need more
information.

Thanks.


--Tim



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don''t miss this year''s exciting event. There''s still
time to save $100.
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

I have to run now, so I can''t look at the dumps.  I am just going to
make some guesses.

On Thu, May 01, 2008 at 08:56:28AM -0700, Timothy Selivanow
wrote:
> 
> Shorewall:all2all:REJECT:IN= OUT=eth0 SRC=192.168.47.1 DST=192.168.42.1
> LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0
> ID=55376 SEQ=1
> 
Your policy file does not specify a policy for traffic going out into
the tunnel.  Your all2all policy is to REJECT, hence the rejection.
Either that, or you need routeback in the interfaces file and you don''t
have it.
> 
> Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=69.30.99.148 DST=69.30.46.20
> LEN=136 TOS=0x00 PREC=0x00 TTL=64 ID=25966 DF PROTO=ESP SPI=0xccd0a1c
> 
This one almost certainly looks like it is missing routeback.  Your src
address is the one you note below as being part of eth0''s segment.
However, the dst address and out interface are heading to eth0.

I''ll try and look more later.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don''t miss this year''s exciting event. There''s still
time to save $100.
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Timothy Selivanow wrote:
> I''ve looked at a number of docs for a couple of days now, and
while I''ve
> made some progress, I''ve hit a wall that is baffling me.
That''s because you are trying to use ESP within AH. None of the
Shorewall documents cover that setup since AH is rarely used and the
method for defining its use to Netfilter is pretty much undocumented.

Getting this to work with Shorewall is going to take a lot of time, a
lot of experimentation and acquiring a lot of knowledge about how both
the Netfilter ''policy'' match works and how IPSEC works. I
personally
don''t have the time right now to get involved.

Sorry,
-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 the 2008 JavaOne(SM) Conference 
Don''t miss this year''s exciting event. There''s still
time to save $100.
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

On Thu, 2008-05-01 at 13:02 -0700, Tom Eastep wrote:
> Timothy Selivanow wrote:
> > I''ve looked at a number of docs for a couple of days now, and
while I''ve
> > made some progress, I''ve hit a wall that is baffling me.
> 
> That''s because you are trying to use ESP within AH. None of the
> Shorewall documents cover that setup since AH is rarely used and the
> method for defining its use to Netfilter is pretty much undocumented.
> 
> Getting this to work with Shorewall is going to take a lot of time, a
> lot of experimentation and acquiring a lot of knowledge about how both
> the Netfilter ''policy'' match works and how IPSEC works. I
personally
> don''t have the time right now to get involved.
I got it to work, but I dropped using Shorewall to manage IPTables.  I
spent the last almost two weeks learning this, and I believe that I now
have at least a working understanding of the IPSec/IPTables and now
understand IPTables and kernel routing *much* more than I did before
exploring this :)

The trick is realizing the IPSec interaction is more simple than it
seems.  A packet traverses IPTables once (for a single direction, so if
forwarding is taking place add that, etc...) for each of the following
states: plain, ESP encap., and AH encap (the shorewall errors I had
before and some other test lead me to believe that AH and ESP are
encapsulated separately).

The first time traffic traverses, it is plain.  Once through IPTables
the kernel discovers that the traffic matches an IPSec policy, so it
encapsulates it and throws it back into IPTables.  Perform that again if
using AH and ESP together.

Here are the basic additions to the rules I had been using, the exacts
are attached in case you would like to take a look over it.  I bypassed
using Shorewall because digging through the docs took too long and I
already knew what I wanted to do.


1.) Accept incoming IPSec protocols and IKE

2.) If using masquerading, don''t masquerade if dest is other side of
tunnel. (I just added ''-d ! {other-side}'' to the masq rule.)

3.) If using norfc1918, add a rule right before it to allow incoming
rfc1918 address (need to experiment if just adding ''-s !
{other-side}''
to the -j norfc1918 rule would work, would make it subject to eth0_in
filtering...)

4.) Make new ''zone'' otherside2local by adding ''-s
{other-side}'' rule
just above the other forward rule on same interface combination.  E.g.,
given ''eth0_fwd -o eth1 -j inet2local'' and local is not
192.168.2.0/24
but other side is, add ''eth0_fwd -o eth1 -s 192.168.2.0/24 -j
otherside2local'' just above it, or above the norfc1918 rule if using on
eth0.

5.) Make new ''zone'' local2otherside by adding ''-d
{other-side}'' rule on
the other interface of the zone traversal pair, same as above.  E.g.,
given ''-A eth1_fwd -o eth0 -j local2inet'' and same network as
before,
add ''-A eth1_fwd -o eth0 -d 192.168.2.0/24 -j local2otherside''
just
above it, or above the norfc1918 rule.


--Tim




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/