[strongSwan] issue with firewall rules

[James]

All,

I think I figured out what's going on. Because each host is
auto=start, multiple SAs were being built between each host.

charon would eventually detect that there were non-unique SAs and
destroy them, and the firewall rule would go with it.

I caught then when watching the iptable rules immediately after
restarting the daemon(s) and realizing that the rules were properly
injected, only to disappear a few seconds later.

The logs then showed this:

charon: 04[IKE] deleting duplicate IKE_SA for peer 'dev2' due to
uniqueness policy

After adding uniqueids=never to the configuration it appears to have
rectified the problem.

I'm curious, however, if there is some way to blackhole traffic (or
return an icmp unreachable) if the traffic is not being encrypted from
host A to host B. In other words, if the tunnel is not up (or the
iptables rule is not installed), there's a subsequent firewall rule
that will drop the traffic. This is critical in ensuring that services
running on these servers and communicating will not unknowingly send
data in plain text.

Thoughts?

On Wed, Apr 1, 2015 at 6:04 PM, James <jameszee13 at gmail.com> wrote:
> 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
>>
>>