Hi Tom,
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.
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.
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.
Martin
>>> Tom Eastep <[email protected]> 18.03.2015 17:35 >>>
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 \________________________________________________
------------------------------------------------------------------------------
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
