Wow Tom, I have to say I have not seen a project whose founder and developer is so dedicated to helping users. When I was searching the list I predominately came upon posts from you. I have to say thank you for being persistent and explaining these simple things to me.
I think my confusion came from that quote I posted about how entries in tunnels could be easily replaced by rules. I then took upon myself the false impression that I just needed the hole open and Shorewall did not need to know anything about there actually being an ipsec connection. Your post immediately flipped that light on over my head (and made the whole setup work) and if you don't mind I'd like to use some of it in a blog post, or how-to of some sort. Thanks again for the dedication, this definitely would have turned into a weeklong ordeal like Prasanna warned. Josh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Eastep Sent: Friday, January 05, 2007 8:27 AM To: Shorewall Users Subject: Re: [Shorewall-users] GRE over IPSec VPN 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 ------------------------------------------------------------------------- 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
