Thanks Bryan -- I appreciate the quick response. So you modified the /usr/lib/ipsec/_updown script and added the --wait flag for the add and remove operations?
If so, clever! I'll give that a try. On Wed, Apr 1, 2015 at 8:03 AM, Bryan Duff <duff0...@gmail.com> wrote: > Use the iptables --wait argument? > > From the manpage: > Wait for the xtables lock. To prevent multiple instances of the program > from running concurrently, an attempt will be made to obtain an exclusive > lock at launch. By default, the program will exit if the lock cannot be > obtained. This option will make the program wait until the exclusive lock > can be obtained. > > I've used it, it works. If it still fails then you have a different > problem. > > -Bryan > > On Wed, Apr 1, 2015 at 1:06 AM, James <jamesze...@gmail.com> wrote: >> >> Hello, >> >> Hoping someone can point me in the right direction. >> >> Running strongSwan 5.1.3 on Ubuntu 14.10. It appears that while my >> tunnels will consistently come up via service strongswan restart, the >> iptable rules are sporadically _not_ added to the hosts. >> >> As an example, I've automate the configuration and deployment of >> strongSwan to 5 hosts which will each build tunnels between each >> other. This consistently works. >> >> However, traffic between the nodes is not always encrypted. After >> running tcpdump on various nodes it appears that the updown script is >> not run _all_ of the time. On the latest run of this automation >> process, 3 nodes had iptable rules that encrypt traffic to all other >> nodes, while 1 had half of the rules needed and one node didn't any >> rules at all. If I restart the services enough times this issue will >> eventually alleviate itself. >> >> Two questions: >> >> (a) while I've read that the default updown script does have >> scalability limitations, I wouldn't imagine I'd be hitting them with >> as few as 5 hosts. Any ideas / thoughts on how to fix this so that >> leftfirewall=yes functions as designed? >> >> (b) is there some way for me to drop traffic between nodes if it's not >> encrypted? I've done some Googling on this subject matter and I was >> unable to find a cut-and-dry method by which I can drop traffic if it >> does not go through the following rule: >> >> -A INPUT -s 10.1.1.174/32 -d 10.1.1.172/32 -i eth0 -p ipencap -m >> policy --dir in --pol ipsec --reqid 3 --proto esp -j ACCEPT >> >> Thoughts / ideas would be very greatly appreciated! >> _______________________________________________ >> Users mailing list >> Users@lists.strongswan.org >> https://lists.strongswan.org/mailman/listinfo/users > > _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users