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
odin-shorewall-mod-iptables.bz2
Description: application/bzip
omotemon-shorewall-mod-iptables.bz2
Description: application/bzip
------------------------------------------------------------------------- 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/
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
