Joshua Perry wrote: > Well, it wasn't too difficult, it is running right now, and added masq from > the remote site through this host in just 5 minutes. The problem I've found > is the policy match that Shorewall is adding to the interface's zone chain > rules "policy match dir in pol none" (eg. rule 2 in vlan4_in) lets ESP > through, then blocks the GRE but never gets stripped to the raw data packets > because it is rejected. > > If I add -- like you see below -- the 3rd rule everything works great; ESP > gets in through rule 2 and once in inet2fw there gets accepted by rule 3. > GRE then gets pulled from the ESP and gets through vpn4_1 to inet2fw through > rule 3 and accepted by rule 5, then the raw data gets stripped and shows up > in INPUT as IN=vpn1 and sent down the vpn1_in chain and via rule 2 into > evl2fw and accepted there because of evl2fw's generous rules. > > There is obviously a bit of a dichotomy with how netfilter reacts to the > packets. Basically it deems ESP packets a match to the inbound policy, not > GRE, but the raw packets again are accepted by the policy match. With just > rule 1 & 2 in vlan4_in (default generated by Shorewall) the setup doesn't > work, but adding by hand with iptables rule 3 (Or replacing rule 2 with rule > 3) everything works great. > > I've made a quick post to the netfilter list to see if maybe it's a bug or > if that is how it is supposed to work. If it turns out not to be a bug I > need to find a way to make Shorewall not put that policy match on the zone > rules, as well as understand why it is there in the first place.
Once again, this is not a bug but rather your lack of understanding about
what is going on.
There are three broad classes of Shorewall zones:
a) firewall
b) ipv4
c) ipsec
The type of zone is specified in the second column of /etc/shorewall/zones.
Zones of type 'ipv4' may have ipsec "groups" included in them. A host group
is designated as being 'ipsec' by including the keyword "ipsec" in the
OPTIONS column of /etc/shorewall/hosts.
Traffic to/from ipv4 zones is not encrypted by IPSEC. Traffic to/from ipsec
zones and/or ipsec host groups is encrypted.
Here is what you claim to be your zones file:
/etc/shorewall/zones
----------------------------------------------------------------------
fw firewall
evl
inet
local
----------------------------------------------------------------------
You have no 'ipsec' zones. From looking at the dump that you supplied last
night, I see that you have no ipsec host groups.
In iptables terms then, your 'inet' zone is not an ipsec zone so traffic
to/from hosts in that zone is not encrypted. That is why this rule is the
way that it is:
16 2624 inet2fw all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir in pol none
The 'pol none' says that only traffic from inet hosts that has not been
decrypted should pass through that chain.
Now if you would have added this to your /etc/shorewall/zones file:
rem ipsec
and this to your /etc/shorewall/zones file:
rem vlan4 -
Then you would have seen a rule in the vlan4_in chain such as follows:
xx yyyy rem2fw all -- * * 0.0.0.0/0
0.0.0.0/0 policy match dir in pol ipsec
An traffic entering on vlan4 would have been passed through the rem2fw chain.
-----------------------------------------------------------------------
Note:
Alternatively, you could put this in /etc/shorewallzones:
rem ipv4
And this in /etc/shorewall/hosts:
rem vlan4:67.42.31.242 ipsec
-----------------------------------------------------------------------
Finally, in the /etc/shorewall/tunnels file, you have:
/etc/shorewall/tunnels
----------------------------------------------------------------------
gre inet 67.42.31.242
ipsec:noah inet 67.42.31.242
----------------------------------------------------------------------
The GRE traffic is subject to the IPSEC transport mode SA. So by the time
that GRE packets are processed by the Shorewall-generated ruleset, they have
been decrypted. As you've pointed out, they don't get sent down the
'inet2fw' chain but they *would* be sent down the 'rem2fw' chain. So the
first tunnels file entry should be:
gre rem 67.42.31.242
That is what I meant about parallel vs. nested tunnels -- the GRE tunnel is
nested within the IPSEC transport mode SA and must be defined accordingly.
-Tom
--
Tom Eastep \ Nothing is foolproof to a sufficiently talented fool
Shoreline, \ http://shorewall.net
Washington USA \ [EMAIL PROTECTED]
PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
