[strongSwan] issue with firewall rules

James jameszee13 at gmail.com
Wed Apr 1 19:59:46 CEST 2015

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

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 <jameszee13 at 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 <duff0097 at 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 <jameszee13 at 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 -d -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 at lists.strongswan.org
>>> https://lists.strongswan.org/mailman/listinfo/users

More information about the Users mailing list