[strongSwan] issue with firewall rules

[Rajiv Kulkarni]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150402/957d1863/attachment.html>