On 3/18/2015 5:55 AM, Martin Kasztantowicz wrote: > Hi Tom, > > thank your very much for this fast response. > > I know that my problem could theoretically be solved via StrongSwan by > setting all traffic selectors to 0.0.0.0/0 on all peers. Unfortionally > our peers cannot use these broad selectors because they also have > several other tunnels as well. This means we have to use narrow traffic > selectors for all tunnels of the form > > 10.40.22.0/22 (gateway LAN) => 10.119.50.0/24 (Remote LAN 1) > 10.40.22.0/22 (gateway LAN) => 192.168.10.0/24 (Remote LAN 2) > 10.40.22.0/22 (gateway LAN) => 192.168.11.0/24 (Remote LAN 3) ...In > addition we have to use IKEV1 due to limitations on the remote VPN > appliances, which mandates that the traffic selectors must be identical > on both sides of the tunnels and is not even able to do > split-tunnelling.
Then I don't understand how traffic from 10.119.50.34 to 192.168.10.10 is even sent to your system via the VPN gatewayed at 212.202.242.2 because there is no local SPD entry that covers that source and destination. From what you are saying, there is no such policy on the remote appliance either? This means I have no idea how to handle this in > StrongSwan under these circumstances. Nor do I. > However, if I have a working hub that has IPsec tunnels to several > spokes I assumed it would be possible to tell the gateway *via shorewall > rules* how to route traffic between the peers. IMO it would also be > conceptionally cleaner and more manageable if StrongSwan IPsec would > only used to build a number of tunnels and have all routing and > firewalling policies concentrated in on place (Shorewall) where one > would expect them to be. IPSEC is parallel to routing and you can't coerce traffic that doesn't match an IPSEC security policy to be sent via IPSEC. In some configurations, you can use SNAT to force non-matching traffic to match after the SNAT is applied, but I don't see that technique being useful here. I have sent a message to someone more experienced that I am regarding IPSEC and we'll see what he says. > Is there really no way to do this with Shorewall? From everything I can see in the dump, the traffic is simply being dropped during routing. Are you seeing any other networking log messages in your system log when sending spoke-to-spoke traffic? -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
