Still can't quite get this to work as I'd like. I copied /usr/lib/ipsec/_updown to /etc/ipsec.updown and modified all "iptables -I" and "iptables -D" calls to include --wait (i.e., "iptables --wait -I" and "... -D").
I then modified my configuration file: conn dev3-dev5 type=transport authby=secret left=2.1.1.173 leftid=dev3 #leftfirewall=yes leftupdown=/etc/ipsec.updown right=2.1.1.175 rightid=dev5 auto=start compress=yes The iptable rules are not installed. Interestingly enough, if I configure leftupdown=/usr/lib/ipsec/_updown it _still_ doesn't work. While I could simply modify /usr/lib/ipsec/_updown with the --wait flag and then use firewall=yes, my geeky side would much rather determine why this is breaking. ;) Any thoughts / ideas would be greatly appreciated! On Wed, Apr 1, 2015 at 11:34 AM, James <jamesze...@gmail.com> wrote: > 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