Re: Is VPN initiation by traffic possible?
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
Re: Is VPN initiation by traffic possible?
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 +, 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
Re: Is VPN initiation by traffic possible?
Heya On Fri, Apr 15, 2011 at 10:37 PM, Reyk Floeter r...@openbsd.org 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
Re: Is VPN initiation by traffic possible?
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
Re: Is VPN initiation by traffic possible?
2011/4/15 Reyk Floeter r...@openbsd.org: 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
Re: Is VPN initiation by traffic possible?
On Wed, Apr 13, 2011 at 09:19:19AM +, 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/
Is VPN initiation by traffic possible?
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
Re: Is VPN initiation by traffic possible?
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.
Re: Is VPN initiation by traffic possible?
On 2011-04-13, Scott McEachern sc...@blackstaff.ca 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.
Re: Is VPN initiation by traffic possible?
On 04/13/11 09:38, Randal L. Schwartz wrote: Scott == Scott McEachernsc...@blackstaff.ca 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.
Re: Is VPN initiation by traffic possible?
Scott == Scott McEachern sc...@blackstaff.ca 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 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Re: Is VPN initiation by traffic possible?
Heya On Thu, Apr 14, 2011 at 3:09 AM, Scott McEachern sc...@blackstaff.cawrote: On 04/13/11 09:38, Randal L. Schwartz wrote: Scott == Scott McEachernsc...@blackstaff.ca 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
Re: Is VPN initiation by traffic possible?
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 sc...@blackstaff.cawrote: On 04/13/11 09:38, Randal L. Schwartz wrote: Scott == Scott McEachernsc...@blackstaff.ca 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
Re: Is VPN initiation by traffic possible?
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 shane.laza...@pobox.com Heya On Thu, Apr 14, 2011 at 3:09 AM, Scott McEachern sc...@blackstaff.ca wrote: On 04/13/11 09:38, Randal L. Schwartz wrote: Scott == Scott McEachernsc...@blackstaff.ca 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
Re: Is VPN initiation by traffic possible?
Heya On Thu, Apr 14, 2011 at 8:05 AM, Matt S maschwa...@yahoo.com 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
