<div dir="ltr">Use the iptables --wait argument?<div><br></div><div>From the manpage:</div><div><div>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.</div></div><div><br></div><div>I've used it, it works.  If it still fails then you have a different problem.</div><div><br></div><div>-Bryan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 1, 2015 at 1:06 AM, James <span dir="ltr"><<a href="mailto:jameszee13@gmail.com" target="_blank">jameszee13@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Hoping someone can point me in the right direction.<br>
<br>
Running strongSwan 5.1.3 on Ubuntu 14.10. It appears that while my<br>
tunnels will consistently come up via service strongswan restart, the<br>
iptable rules are sporadically _not_ added to the hosts.<br>
<br>
As an example, I've automate the configuration and deployment of<br>
strongSwan to 5 hosts which will each build tunnels between each<br>
other. This consistently works.<br>
<br>
However, traffic between the nodes is not always encrypted. After<br>
running tcpdump on various nodes it appears that the updown script is<br>
not run _all_ of the time. On the latest run of this automation<br>
process, 3 nodes had iptable rules that encrypt traffic to all other<br>
nodes, while 1 had half of the rules needed and one node didn't any<br>
rules at all. If I restart the services enough times this issue will<br>
eventually alleviate itself.<br>
<br>
Two questions:<br>
<br>
(a) while I've read that the default updown script does have<br>
scalability limitations, I wouldn't imagine I'd be hitting them with<br>
as few as 5 hosts. Any ideas / thoughts on how to fix this so that<br>
leftfirewall=yes functions as designed?<br>
<br>
(b) is there some way for me to drop traffic between nodes if it's not<br>
encrypted? I've done some Googling on this subject matter and I was<br>
unable to find a cut-and-dry method by which I can drop traffic if it<br>
does not go through the following rule:<br>
<br>
-A INPUT -s <a href="http://10.1.1.174/32" target="_blank">10.1.1.174/32</a> -d <a href="http://10.1.1.172/32" target="_blank">10.1.1.172/32</a> -i eth0 -p ipencap -m<br>
policy --dir in --pol ipsec --reqid 3 --proto esp -j ACCEPT<br>
<br>
Thoughts / ideas would be very greatly appreciated!<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.strongswan.org">Users@lists.strongswan.org</a><br>
<a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a><br>
</blockquote></div><br></div>