[strongSwan-dev] ClusterIP and Virtualization

[Daniel Palomares]

Hi again;

Here is the the architecture we are using is (cIP means ClusterIP):

                 +--- SG1 ---+
                 |                    |
Client ---+ cIP      cIP+--- Server
                 |                    |
                 +--- SG2 ---+

Our problem is that client cannot ping the Server. The ping request reaches
the Server, but the reply is blocked by the SG1. More specifically, the
reply is received by the SG1 but it is not forwarded to the client.
We believe the problem comes from two instance of Cluster IP interacting
with IPsec. Is there any known issues for tunneling incoming multicast
packets with IPsec?

Here are the configurations we tested:

1) Two Cluster IP only: With Cluster IP and the Security Gateways not
configured with IPsec, we can ping the server with the client each other.
On each segment ping have the expected MAC addresses. In this case the IP
address of the client is the outer IP address since no encapsulation occurs.

2) IPsec only: With Security Gateways configured with IPsec and Cluster IP
not set, we can also ping

3) IPsec and a single Cluster IP: With Security Gateways configured with
IPsec and Cluster IP set on the client side only (= Cluster IP is not set
on the Server side), ping between the client and server are fine.

Here is the iptables -L output:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  client.local         192.168.1.0/24       policy match
dir in pol ipsec reqid 1 proto esp
CLUSTERIP  all  --  anywhere             sg1.local            CLUSTERIP
hashmode=sourceip clustermac=01:00:5E:00:00:03 total_nodes=2 local_node=1
hash_init=0
CLUSTERIP  all  --  anywhere             sg1.local            CLUSTERIP
hashmode=sourceip clustermac=01:00:5E:00:00:02 total_nodes=2 local_node=1
hash_init=0

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  client.local         192.168.1.0/24       policy match
dir in pol ipsec reqid 1 proto esp
ACCEPT     all  --  192.168.1.0/24       client.local         policy match
dir out pol ipsec reqid 1 proto esp

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  192.168.1.0/24       client.local         policy match
dir out pol ipsec reqid 1 proto esp


Thanks you in advance, we would be glad to hear any suggestions.

Daniel Palomares



2013/5/27 Daniel Palomares <palomaresdaniel at gmail.com>

> Thanks you very much for your answer Martin. This is exactly what happened.
>
> However, now im facing troubles with the internal interface of the SG1.
>
> The pings now passes through the security gateway, it reaches the server,
> but then, when it comes back, it is blocked in the Security Gateway.
>
> I have applied  the command "*echo 2 >
> /sys/devices/virtual/net/<br>/brif/<if>/multicast_router*" on those vnet
> where needed.
>
> Do you know if Am I missing something? Does IPsec block the ping when it
> is going back to the client?
>
> Thanks again!
>
> Daniel
>
>
> 2013/5/27 Martin Willi <martin at strongswan.org>
>
>> Hi Daniel,
>>
>> > when listening to the bridge (br0), we can also see the ICMP packets.
>> > Unfortunately, when listening to vnet0 or 10.0.0.3, we see no ICMP
>> > packets.
>>
>> Linux bridges do not forward all packets with a multicast MAC addresses
>> anymore (see [1]).
>>
>> You can change the default behavior by using:
>>
>>  echo 2 > /sys/devices/virtual/net/<br>/brif/<if>/multicast_router
>>
>> Regards
>> Martin
>>
>> [1]
>> http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#Snooping
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20130528/9cc3e5b6/attachment.html>