[strongSwan] issue with firewall rules

James jameszee13 at gmail.com
Wed Apr 1 17:34:39 CEST 2015


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


More information about the Users mailing list