[strongSwan-dev] ClusterIP and Virtualization

[Daniel Palomares]

I forgot to specify that the 'iptables -L' showed, concerns the Security
Gateway 1.



Daniel Palomares
Orange Labs de France Télécom
Telecom SudParis - UPMC
Doctorate Student Program


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

> 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/82cb6566/attachment.html>