<div dir="ltr"><div><div>Hi<br><br></div>My preference would be to do the below steps:<br><br></div><div>1. add the following rules on each of the ipsec-peer-gws, if not already done<br><br>iptables -A INPUT -p esp -j ACCEPT<br>iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT<br>iptables -A INPUT -p udp -m udp --dport 4500 -j ACCEPT<br>iptables -A INPUT -p udp -m udp --dport 1701 -j ACCEPT<br><br>iptables -A OUTPUT -p esp -j ACCEPT<br>iptables -A OUTPUT -p udp -m udp --dport 500 -j ACCEPT<br>iptables -A OUTPUT -p udp -m udp --dport 4500 -j ACCEPT<br>iptables -A OUTPUT -p udp -m udp --dport 1701 -j ACCEPT<br><br>iptables -t nat -I POSTROUTING 1 -p esp -j ACCEPT<br><br></div><div>2. Next i think you should remove all those leftupdown/rightupdowns statements from all the conn entries of all GWs<br><br></div><div>just use the below 2 statements in ALL the ipsec-peer-gws participating in the tunnels without any exceptions<br><br></div><div>leftfirewall=yes<br></div><div>lefthostaccess=yes<br><br></div><div>3. Please use the orginal  default "updown" script as it is without making any changes to it. I think the original default updown script would work for most scenarios without any issues<br><br><br></div><div>4. If i understand correctly each of the leftfirewall/lefthostaccess and the updown file is locally relevant to the respective GWs<br><br><br></div><div><br></div><div>thanks<br></div><div>rajiv<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 1, 2015 at 9:04 PM, 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">Thanks Bryan -- I appreciate the quick response.<br>
<br>
So you modified the /usr/lib/ipsec/_updown script and added the --wait<br>
flag for the add and remove operations?<br>
<br>
If so, clever! I'll give that a try.<br>
<br>
On Wed, Apr 1, 2015 at 8:03 AM, Bryan Duff <<a href="mailto:duff0097@gmail.com">duff0097@gmail.com</a>> wrote:<br>
> Use the iptables --wait argument?<br>
><br>
> From the manpage:<br>
> Wait for the xtables lock.  To prevent multiple instances of the program<br>
> from  running  concurrently, an  attempt will be made to obtain an exclusive<br>
> lock at launch.  By default, the program will exit if the lock cannot be<br>
> obtained.  This option will make the program wait until the exclusive lock<br>
> can  be obtained.<br>
><br>
> I've used it, it works.  If it still fails then you have a different<br>
> problem.<br>
><br>
> -Bryan<br>
><br>
> On Wed, Apr 1, 2015 at 1:06 AM, James <<a href="mailto:jameszee13@gmail.com">jameszee13@gmail.com</a>> wrote:<br>
>><br>
>> 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>
><br>
><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></div>