From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: On-Demand IPsec VPN
Date: Wed, 15 Feb 2017 14:53:56 +0000 [thread overview]
Message-ID: <1487170436.24657.168.camel@ipfire.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]
Hello guys,
sorry for my absence in the last few days and weeks. This list has been more or
less read-only for me and I would like to chance this. I would like to see more
people involved in this project and take part in what we do here. So it is
important that everyone is in the know about what is going on.
This morning I worked on a small feature which is probably quite interesting:
On-demand IPsec VPN tunnels.
What does it do? It essentially installs triggers in the kernel instead of
bringing up the VPN tunnel right away. As soon as the kernel is receiving a
packet that is supposed to be sent through that VPN, it will ask strongSwan to
bring up the tunnel and send the packet.
When the VPN tunnel has not transferred any packets for 15 minutes, it will
terminate it and restart it when it is needed again.
Why is this such a great feature? It is simple, but in scenarios with many VPN
tunnels (e.g. headquarters and many branch offices) it does not always make
sense to keep all tunnels up all of the time. This feature will shut down any
tunnels that are not needed and keep resources free.
This is probably not much, but we have seen machines with only few entropy and
we have seen IPsec becoming unstable then.
The web user interface shows the status if a tunnel is idle or connected.
Patches are in next:
http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=dcb406cc675c42f9add4a41c8a1e07eea7c3ab08
http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=1ee1666ee45268db405a66b8ec05501c718e7702
http://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=8057ab15b9efeecf8eca7ad4ebba170f141bd3de
It would be cool if you all could have a look at them, test them, maybe complete
translations for any languages that you speak, etc.
I am not sure if this will cause some problems with some applications that rely
on fast establishing of connections.
Looking forward to hearing your feedback!
Best,
-Michael
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next reply other threads:[~2017-02-15 14:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 14:53 Michael Tremer [this message]
[not found] <762FB15B-0D41-4D22-9284-90C2BEDC5245@rymes.com>
2017-02-15 16:09 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1487170436.24657.168.camel@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox