<div dir="ltr"><div><div><div><div><div><div>Hi again;<br><br></div><div>Here is the the architecture we are using is (cIP means ClusterIP):<br></div><br></div><div> +--- SG1 ---+<br></div><div> | |<br>
</div>Client ---+ cIP cIP+--- Server<br> | |<br></div> +--- SG2 ---+<br><br>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.<br>
</div><div>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?<br></div><div><br></div><div>Here are the configurations we tested:<br>
<br></div>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.<br>
</div><div><br>2) IPsec only: With Security Gateways configured with IPsec and Cluster IP not set, we can also ping<br></div><br></div>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. <br>
<div><br><div class="gmail_extra"><div>Here is the iptables -L output:<br><br>Chain INPUT (policy ACCEPT)<br>target prot opt source destination <br>ACCEPT all -- client.local <a href="http://192.168.1.0/24">192.168.1.0/24</a> policy match dir in pol ipsec reqid 1 proto esp<br>
CLUSTERIP all -- anywhere sg1.local CLUSTERIP hashmode=sourceip clustermac=01:00:5E:00:00:03 total_nodes=2 local_node=1 hash_init=0<br>CLUSTERIP all -- anywhere sg1.local CLUSTERIP hashmode=sourceip clustermac=01:00:5E:00:00:02 total_nodes=2 local_node=1 hash_init=0<br>
<br>Chain FORWARD (policy ACCEPT)<br>target prot opt source destination <br>ACCEPT all -- client.local <a href="http://192.168.1.0/24">192.168.1.0/24</a> policy match dir in pol ipsec reqid 1 proto esp<br>
ACCEPT all -- <a href="http://192.168.1.0/24">192.168.1.0/24</a> client.local policy match dir out pol ipsec reqid 1 proto esp<br><br>Chain OUTPUT (policy ACCEPT)<br>target prot opt source destination <br>
ACCEPT all -- <a href="http://192.168.1.0/24">192.168.1.0/24</a> client.local policy match dir out pol ipsec reqid 1 proto esp<br><br><br></div><div>Thanks you in advance, we would be glad to hear any suggestions.<br>
<br></div><div>Daniel Palomares<br></div><div><br><br></div><br><div class="gmail_quote">2013/5/27 Daniel Palomares <span dir="ltr"><<a href="mailto:palomaresdaniel@gmail.com" target="_blank">palomaresdaniel@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks you very much for your answer Martin. This is exactly what happened.<br><br>However, now im facing troubles with the internal interface of the SG1.<br>
<br></div><div>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. <br>
<br></div><div>I have applied the command "<b>echo 2 > /sys/devices/virtual/net/<br>/brif/<if>/multicast_router</b>" on those vnet where needed.<br><br></div><div>Do you know if Am I missing something? Does IPsec block the ping when it is going back to the client?<br>
<br></div><div>Thanks again! <br><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Daniel<br></div></font></span><div><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/5/27 Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@strongswan.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel,<br>
<div><br>
> when listening to the bridge (br0), we can also see the ICMP packets.<br>
> Unfortunately, when listening to vnet0 or 10.0.0.3, we see no ICMP<br>
> packets.<br>
<br>
</div>Linux bridges do not forward all packets with a multicast MAC addresses<br>
anymore (see [1]).<br>
<br>
You can change the default behavior by using:<br>
<br>
echo 2 > /sys/devices/virtual/net/<br>/brif/<if>/multicast_router<br>
<br>
Regards<br>
Martin<br>
<br>
[1]<a href="http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#Snooping" target="_blank">http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#Snooping</a><br>
<br>
<br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div></div>