Hi again Martin, On 3/18/2015 1:00 PM, Martin Kasztantowicz wrote:
> only the hub has shorewall/strongswan running, and this is where the > problem lies, all the spoke routers are based on firewall appliances. > They have route based tunnels with static routes to all other spoke > destinations. This is why you see in the logs that traffic from host > 10.119.50.34 (located behind gateway 212.202.242.2) is able to > send traffic to the shorewall hub that is destined to 192.168.10.10 > (locate behind gateway 87.139.226.12) at another spoke location. I know > that this works because when I use the IPsec traffic selector of > 0.0.0.0/0 everywhere, all spokes can communicate as desired. Problem is, > that I cannot use such a broad traffic selector because all the spokes > have tunnels to other locations. > > I don't see any other networking messages when sending spoke-to-spoke > traffic, specifically there is nothing that indicates that any traffic > is blocked. If you don't see logging out of the FORWARD chain for the traffic, then it is being dropped during routing, and Shorewall has no control over that. Makes sense, since the traffic arrived over a tunnel, but there is no matching security policy. > > I have built similar route based spoke-to-spoke configurations with > Juniper SSG and Netscreen firewalls and with OpenSwan on pre 2.6 kernels > before and this has never been any problem. With these appliances you > simply create tunnel interfaces, build narrow ipsec tunnels between the > adjecent subnets and apply static routes on each ends telling the > routers how to reach all remote subnets. This is the first time that I > used Shorewall/Strongswan for such a configuration on the hub and I am > really surprised that is this hard (or even impossible?) when using > Linux 2.6 IPsec tunnels. Tuomo Soini has confirmed that, when using PF_KEY IPSEC as introduced in Linux 2.6, in order for the spokes to communicate, you need to define the appropriate tunnels between them. > > If it turns out that Shorewall can't build extra policies to allow > intra-spoke-traffic between working IPsec tunnels - would it possible to > create the needed ip policies via shorewall start scripts and how would > they look like? I am a complete newbie to this iptables stuff so please > excuse this dumb question. > This isn't an iptables issue. It is a PF_KEY IPSEC restriction. The SPD (Security Policy Database) in the kernel is built by StrongSwan (when you are using StrongSwan) and only traffic that matches policies in that database is allowed to pass. Is there not still a version of the old route-based IPSEC implementation that can run on current kernels? Seems like there have been reports on this list of people using such a thing. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
