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 <palomaresdan...@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 <palomaresdan...@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 <mar...@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 >>> >>> >>> >> >
_______________________________________________ Dev mailing list Dev@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/dev
