[strongSwan] issue with firewall rules

[James]

Thanks Rajiv.

iptables is open between the hosts themselves -- esp and all ports you
listed are included. It's good to have double-checked though, so
thanks for the reminder.

The issue here is that occasionally the iptable rules are not
populated properly when an SA is established. In other words, after
the connections between hosts are built, there's usually one or two
hosts that do _not_ have the automatically-generated iptable rules
injected, even though I _do_ have the leftfirewall=yes stanza enabled.

The result of this is the traffic to / from the hosts that are
impacted by that iptable rule are_ not_ encrypted.

Bryan had mentioned using iptables --wait to ensure that iptables has
a lock before making changes. This _DID_ seem to alleviate the issue
somewhat, but even after replacing 'iptables -I' and 'iptables -D'
with 'iptables --wait -D' or '-I' it is still _not_ consistent and
often there are a few rules missing from the table from a random host
or two.

Any thoughts on why some rules simply don't get injected properly?

-j

On Wed, Apr 1, 2015 at 4:09 PM, Rajiv Kulkarni
<rajivkulkarni69 at gmail.com> wrote:
> Hi
>
> My preference would be to do the below steps:
>
> 1. add the following rules on each of the ipsec-peer-gws, if not already
> done
>
> iptables -A INPUT -p esp -j ACCEPT
> iptables -A INPUT -p udp -m udp --dport 500 -j ACCEPT
> iptables -A INPUT -p udp -m udp --dport 4500 -j ACCEPT
> iptables -A INPUT -p udp -m udp --dport 1701 -j ACCEPT
>
> iptables -A OUTPUT -p esp -j ACCEPT
> iptables -A OUTPUT -p udp -m udp --dport 500 -j ACCEPT
> iptables -A OUTPUT -p udp -m udp --dport 4500 -j ACCEPT
> iptables -A OUTPUT -p udp -m udp --dport 1701 -j ACCEPT
>
> iptables -t nat -I POSTROUTING 1 -p esp -j ACCEPT
>
> 2. Next i think you should remove all those leftupdown/rightupdowns
> statements from all the conn entries of all GWs
>
> just use the below 2 statements in ALL the ipsec-peer-gws participating in
> the tunnels without any exceptions
>
> leftfirewall=yes
> lefthostaccess=yes
>
> 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
>
>
> 4. If i understand correctly each of the leftfirewall/lefthostaccess and the
> updown file is locally relevant to the respective GWs
>
>
>
> thanks
> rajiv
>
>
> On Wed, Apr 1, 2015 at 9:04 PM, 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 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
>> >
>> >
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>
>