Is VPN initiation by traffic possible?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Is VPN initiation by traffic possible?

nemir nemirius
Hi,

One of my clients is a major bank.   We need to exchange data a few
times a day at different intervals,  and they're insisting that we
initiate the VPN on demand with relevent traffic.

It works from their end.  Tunnel is down, they send a ping,  first
packet is dropped as the tunnel is brought up,  subsequent traffic
reaches its destination.

What I can't see in the man pages, guides, help files is how to get
an OpenBSD firewall to do the same thing.

I still use isakmpd as I have created several custom transform
configurations that I've not had time to figure out how to migrate
over.   And because I am familiar with it.

I use  OpenBSD 4.8,  and will be upgrading as soon as the discs
arrive.

Is it possible? Can you who me how?

Thanks!

Nemir

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Scott McEachern-2
On 04/13/11 05:19, nemir nemirius wrote:

> Hi,
>
> One of my clients is a major bank.   We need to exchange data a few
> times a day at different intervals,  and they're insisting that we
> initiate the VPN on demand with relevent traffic.
>
> It works from their end.  Tunnel is down, they send a ping,  first
> packet is dropped as the tunnel is brought up,  subsequent traffic
> reaches its destination.
>

It's called "port knocking".  Google is your friend here.

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Randal L. Schwartz
>>>>> "Scott" == Scott McEachern <[hidden email]> writes:

Scott> It's called "port knocking".  Google is your friend here.

And if you recommend or use port knocking, you're an amateur at crypto.
If adding 8 sniffable bits to your effective key length makes you
significantly more secure, you've lost the game already.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Stuart Henderson
In reply to this post by Scott McEachern-2
On 2011-04-13, Scott McEachern <[hidden email]> wrote:

> On 04/13/11 05:19, nemir nemirius wrote:
>> Hi,
>>
>> One of my clients is a major bank.   We need to exchange data a few
>> times a day at different intervals,  and they're insisting that we
>> initiate the VPN on demand with relevent traffic.
>>
>> It works from their end.  Tunnel is down, they send a ping,  first
>> packet is dropped as the tunnel is brought up,  subsequent traffic
>> reaches its destination.

I'm not 100% sure but I don't believe OpenBSD supports this.

> It's called "port knocking".  Google is your friend here.

No it isn't.

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Scott McEachern-2
In reply to this post by Randal L. Schwartz
On 04/13/11 09:38, Randal L. Schwartz wrote:
>>>>>> "Scott" == Scott McEachern<[hidden email]>  writes:
> Scott>  It's called "port knocking".  Google is your friend here.
>
> And if you recommend or use port knocking, you're an amateur at crypto.
> If adding 8 sniffable bits to your effective key length makes you
> significantly more secure, you've lost the game already.
>

I'm not advocating it, but it is what he's asking about.

I should have added "This is not a good idea", but I was hoping he'd
figure that out by reading about it.

Nemir, you might want to go back and find out exactly what problem the
bank is trying to solve with their idea.

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Shane Lazarus
Heya

On Thu, Apr 14, 2011 at 3:09 AM, Scott McEachern <[hidden email]>wrote:

> On 04/13/11 09:38, Randal L. Schwartz wrote:
>
>> "Scott" == Scott McEachern<[hidden email]>  writes:
>>>>>>>
>>>>>> Scott>  It's called "port knocking".  Google is your friend here.
>>
>> And if you recommend or use port knocking, you're an amateur at crypto.
>> If adding 8 sniffable bits to your effective key length makes you
>> significantly more secure, you've lost the game already.
>>
>>
> I'm not advocating it, but it is what he's asking about.
>
> I should have added "This is not a good idea", but I was hoping he'd figure
> that out by reading about it.
>
> Nemir, you might want to go back and find out exactly what problem the bank
> is trying to solve with their idea.
>
>
Actually from what I read in his email, it isn't Port knocking he is after.

What the Bank likely wants is to not have any n+ client(s) out of however
many maintaining a permanent VPN through their infrastructure, thereby
leading to a potential DoS for their other clients.
( based on several appliances having hardware / licensing limitations on how
many concurrently active VPNs are running at once )

Thus what the Bank would like is for the VPN connection to be torn down
after the relevant data is transmitted.

And no, I don't see a "disconnect" option after a brief read of the IPSEC
man pages either.

Shane

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

R0me0 ***
Hello,

I don't know if this will help you, but

"When passive is specified, isakmpd(8) will not
           immediately start negotiation of this tunnel, but wait for an
           incoming request from the remote peer."

You can write a program that initialize connection, transmit your data and
finish it.

I have something seemed, but I use zebedee, and to openbsd have a package. I
wrote a tool that connect, send data and disconnect

This is only a idea

Cheers,


2011/4/13 Shane Lazarus <[hidden email]>

> Heya
>
> On Thu, Apr 14, 2011 at 3:09 AM, Scott McEachern <[hidden email]
> >wrote:
>
> > On 04/13/11 09:38, Randal L. Schwartz wrote:
> >
> >> "Scott" == Scott McEachern<[hidden email]>  writes:
> >>>>>>>
> >>>>>> Scott>  It's called "port knocking".  Google is your friend here.
> >>
> >> And if you recommend or use port knocking, you're an amateur at crypto.
> >> If adding 8 sniffable bits to your effective key length makes you
> >> significantly more secure, you've lost the game already.
> >>
> >>
> > I'm not advocating it, but it is what he's asking about.
> >
> > I should have added "This is not a good idea", but I was hoping he'd
> figure
> > that out by reading about it.
> >
> > Nemir, you might want to go back and find out exactly what problem the
> bank
> > is trying to solve with their idea.
> >
> >
> Actually from what I read in his email, it isn't Port knocking he is after.
>
> What the Bank likely wants is to not have any n+ client(s) out of however
> many maintaining a permanent VPN through their infrastructure, thereby
> leading to a potential DoS for their other clients.
> ( based on several appliances having hardware / licensing limitations on
> how
> many concurrently active VPNs are running at once )
>
> Thus what the Bank would like is for the VPN connection to be torn down
> after the relevant data is transmitted.
>
> And no, I don't see a "disconnect" option after a brief read of the IPSEC
> man pages either.
>
> Shane

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Matt S-5
In reply to this post by Shane Lazarus
________________________________
You might consider a creative solution with Dead Peer Detection.  Per
ipsec.conf(4), you enable Dead Peer Detection by using an ike dynamic statement.

Heya

On Thu, Apr 14, 2011 at 3:09 AM, Scott McEachern <[hidden email]>wrote:

> On 04/13/11 09:38, Randal L. Schwartz wrote:
>
>> "Scott" == Scott McEachern<[hidden email]>  writes:
>>>>>>>
>>>>>> Scott>  It's called "port knocking".  Google is your friend here.
>>
>> And if you recommend or use port knocking, you're an amateur at crypto.
>> If adding 8 sniffable bits to your effective key length makes you
>> significantly more secure, you've lost the game already.
>>
>>
> I'm not advocating it, but it is what he's asking about.
>
> I should have added "This is not a good idea", but I was hoping he'd figure
> that out by reading about it.
>
> Nemir, you might want to go back and find out exactly what problem the bank
> is trying to solve with their idea.
>
>
Actually from what I read in his email, it isn't Port knocking he is after.

What the Bank likely wants is to not have any n+ client(s) out of however
many maintaining a permanent VPN through their infrastructure, thereby
leading to a potential DoS for their other clients.
( based on several appliances having hardware / licensing limitations on how
many concurrently active VPNs are running at once )

Thus what the Bank would like is for the VPN connection to be torn down
after the relevant data is transmitted.

And no, I don't see a "disconnect" option after a brief read of the IPSEC
man pages either.

Shane

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Shane Lazarus
Heya

On Thu, Apr 14, 2011 at 8:05 AM, Matt S <[hidden email]> wrote:

> ________________________________
> You might consider a creative solution with Dead Peer Detection.  Per
> ipsec.conf(4), you enable Dead Peer Detection by using an ike dynamic
> statement.
>
>
>

One thing that came to mind for manual configuration is an authpf shell or
equivalent...

On connection by that shell account, manually bring up the IPSEC connection,
on disconnect bring it down.
That way you have the internal server wanting to communicate have some
control over when the VPN is active.

But yes, the focus does seem to be on how you can automate an otherwise
currently manual function.

Shane

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Joachim Schipper-2
In reply to this post by nemir nemirius
On Wed, Apr 13, 2011 at 09:19:19AM +0000, nemir nemirius wrote:
> Hi,
>
> One of my clients is a major bank.   We need to exchange data a few
> times a day at different intervals,  and they're insisting that we
> initiate the VPN on demand with relevent traffic.
>
> It works from their end.  Tunnel is down, they send a ping,  first
> packet is dropped as the tunnel is brought up,  subsequent traffic
> reaches its destination.

> Is it possible? Can you who me how?

OpenBSD won't do this for you. Can't you wrap whatever sends the data in
a script that sets up and tears down the relevant tunnel?

(You *could* write a daemon to listen on a tun/tap-style device,
dynamically manage the tunnel and forward traffic. But that's quite a
bit of work.)

                Joachim

--
TFMotD: CPANPLUS::Module::Fake (3p) - class for creating fake module objects
http://www.joachimschipper.nl/

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Reyk Floeter-2
In reply to this post by nemir nemirius
Hi Nemir!

Short answer: Yes, it works.

Please forget all the other answers...  I was reading them with some
amusement - port knocking, tunnels, special scripts, "no" :-).  Nobody
seems to have a clue about our IPsec stack.

It is a standard feature that should just work fine with isakmpd(8).
Instead of creating all flows from isakmpd, you can load flows in
ipsec.conf and let isakmpd wait in passive mode.  Passive mode lets
isakmpd wait for connections from remote peers _or_ for messages from
the kernel.  The kernel will send a PFKEYv2 message to isakmpd if it
sees traffic for a flow that does not have an active SA; kindly asking
it to negotiate one.

See also:
http://www.allard.nu/openbsd/maillist/archive/200608/1331.html

A possible, but untested, ipsec.conf configuration could be:

---snip---
flow esp from 192.168.10.0/24 to 192.168.20.0/24 peer 10.0.0.2 type require
ike passive esp from 192.168.10.0/24 to 192.168.20.0/24 peer 10.0.0.2
---snap--

The "flow esp" line is loaded into the kernel but doesn't have an SA
associated.  Note that you could also use "acquire" instead of
"require" to allow unencrypted traffic before the SA is present (who
would do that?).  The "ike passive esp" is loaded into isakmpd(8).

Note that iked(8) doesn't support this type of configuration yet.  It
does understand the acquire/require messages from the kernel but
currently requires to have an active flow from an initial IKEv2
handshake.  It is on our TODO list ;-).

Regards,
reyk

On Wed, Apr 13, 2011 at 09:19:19AM +0000, nemir nemirius wrote:

> One of my clients is a major bank.   We need to exchange data a few
> times a day at different intervals,  and they're insisting that we
> initiate the VPN on demand with relevent traffic.
>
> It works from their end.  Tunnel is down, they send a ping,  first
> packet is dropped as the tunnel is brought up,  subsequent traffic
> reaches its destination.
>
> What I can't see in the man pages, guides, help files is how to get
> an OpenBSD firewall to do the same thing.
>
> I still use isakmpd as I have created several custom transform
> configurations that I've not had time to figure out how to migrate
> over.   And because I am familiar with it.
>
> I use  OpenBSD 4.8,  and will be upgrading as soon as the discs
> arrive.
>
> Is it possible? Can you who me how?
>
> Thanks!
>
> Nemir

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Shane Lazarus
Heya

On Fri, Apr 15, 2011 at 10:37 PM, Reyk Floeter <[hidden email]> wrote:

> Hi Nemir!
>
> Short answer: Yes, it works.
>
>  ...
>   Regards,
> reyk
>

The question remains, how does the connection get torn down?

Or, in another fashion, how does the OpenBSD IPSEC implementation tell the
remote IPSEC implementation that the VPN is not currently required and to
de-register the Active SA?

Shane

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Reyk Floeter-2
On Sat, Apr 16, 2011 at 12:47:57AM +1200, Shane Lazarus wrote:
> The question remains, how does the connection get torn down?
>
> Or, in another fashion, how does the OpenBSD IPSEC implementation tell the
> remote IPSEC implementation that the VPN is not currently required and to
> de-register the Active SA?
>

an SA has a lifetime and an optional byte limit and the IKE/IKEv2 peer
decides if it wants to renegotiate or drop the SA after this limit is
reached.  smart, isn't it?

for example, the windows 7 IKEv2 client tells the remote peer to
delete any child SAs (phase 2 SAs) after expiration but does not
negotiate new ones until new traffic is trying to flow.  iked(8) just
handles this fine.  AFAIK, OpenBSD isakmpd(8) tries to rekey expired
phase 1 SAs by default but closes the connection if the peer doesn't
respond... until another acquire message is received from the kernel
or the peer comes around to say `hello'.

reyk

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

Martin Pelikan
In reply to this post by Reyk Floeter-2
2011/4/15 Reyk Floeter <[hidden email]>:
> Short answer: Yes, it works.

Yes, it does. But...

> See also:
> http://www.allard.nu/openbsd/maillist/archive/200608/1331.html

See also:
http://old.nabble.com/isakmpd---get-CRLs-to-work-td30629580.html

That basically means if you're using X.509 PKI and someone compromises
one of your certificates, simple revocation (and updating the CRLs
properly) won't work - the kicked client can just reconnect back. I've
tested that once again on 4.8-release and even when both isakmpds load
the newest CRL, the revoked client is allowed in anyway, creates flows
and happily communicates.

That patch raises a lot of XXXs because I simply needed a quick fix
and don't really much understand the way that part of isakmpd is
written. But none of the developers seemed to care about this so far,
so I guess nobody uses it anyway :-)

So, if your client is just one bank, use RSA keys. It's also easier to
configure. But I think people with lots of clients should be aware of
this bug (or does the revocation actually work for anyone?)

> Note that iked(8) doesn't support this type of configuration yet. B It
> does understand the acquire/require messages from the kernel but
> currently requires to have an active flow from an initial IKEv2
> handshake. B It is on our TODO list ;-).

iked(8) and certificate revocation work just fine.

--
Martin Pelikan

Reply | Threaded
Open this post in threaded view
|

Re: Is VPN initiation by traffic possible?

nemir nemirius
In reply to this post by Reyk Floeter-2
Hi Reyk,


> Short answer: Yes, it works.


Fantastic! Thanks for the response!!




> See also:
> http://www.allard.nu/openbsd/maillist/archive/200608/1331.html

I have read this now...



I do still have to read up on iked,  so I can get my head around that

info better, though.

> A possible, but untested, ipsec.conf configuration could be:
>
> ---snip---
> flow esp from 192.168.10.0/24 to 192.168.20.0/24 peer 10.0.0.2 type require
> ike passive esp from 192.168.10.0/24 to 192.168.20.0/24 peer 10.0.0.2
> ---snap--


I am still using isakmpd.conf & isakmpd.policy....

do you have a possible untested sample config for them..?  All the

threads I've seen on this just say "isakmpd.conf is possible but more

complicated" and don't go any further.  :(


I guess I've read so much stuff now I probably could covert over, but
that would alter the change impact, requiring a lot more effort.


Thanks for the awesome responses!

Nemir