Re: ISAKMPD
MG wrote: Forgive my ignorance, but does this mean that if I were to install OpenBSD 4.9 via FTP today, there shouldn't be random IPsec disconnects as described in bug PR6601? Thanks. The file sets on ftp.openbsd.org/pub/OpenBSD/4.9/ (and of course on all official mirrors) are 4.9-release (the same as on the CD). If you don't mind getting your files from an non-official source, you can install or update from ftp://ftp.openbsd-stable.org./pub/OpenBSD-stable/4.9-stable/ The patch for isakmpd is included in these file sets. Maurice BTW: openbsd-stable.org is my pet project, so I'm a bit biased.
Re: ISAKMPD
MG [mas...@fourseasonsnow.com] wrote: > Forgive my ignorance, but does this mean that if I were to install > OpenBSD 4.9 via FTP today, there shouldn't be random IPsec > disconnects as described in bug PR6601? Thanks. Only if it's 4.9-current (snapshot) If you install 4.9 release, you have to update to stable. (See OpenBSD web site)
Re: ISAKMPD
On 7/14/2011 9:31 PM, Kenneth R Westerback wrote: On Thu, Jul 14, 2011 at 11:28:44PM +0200, rancor wrote: Are there many updates of the source that is not published as an errata (on stable)? Yes. Ken // rancor 2011/7/14 Stuart Henderson: On 2011-07-14, Paul Suh wrote: If it's easy to pull the diff it shouldn't be hard to post it It's not about difficulty. and it would be a nice thing to do for folks have scripts that notify them on changes of the errata pages. It's normal to have things in -stable where no erratum is issued. Why go to the hassle of a script to notify you of changes to a webpage when you can just run "cd /usr/src; cvs -d $SOMEPATH -q up -r OPENBSD_whatever" from cron? Forgive my ignorance, but does this mean that if I were to install OpenBSD 4.9 via FTP today, there shouldn't be random IPsec disconnects as described in bug PR6601? Thanks.
Re: ISAKMPD
On Thu, Jul 14, 2011 at 11:28:44PM +0200, rancor wrote: > Are there many updates of the source that is not published as an > errata (on stable)? Yes. Ken > > // rancor > > 2011/7/14 Stuart Henderson : > > On 2011-07-14, Paul Suh wrote: > >> If it's easy to pull the diff it shouldn't be hard to post it > > > > It's not about difficulty. > > > >> and it would be a nice thing to do for folks have scripts that > >> notify them on changes of the errata pages. > > > > It's normal to have things in -stable where no erratum is issued. > > > > Why go to the hassle of a script to notify you of changes to a webpage when > > you can just run "cd /usr/src; cvs -d $SOMEPATH -q up -r OPENBSD_whatever" > > from cron?
Re: ISAKMPD
Are there many updates of the source that is not published as an errata (on stable)? // rancor 2011/7/14 Stuart Henderson : > On 2011-07-14, Paul Suh wrote: >> If it's easy to pull the diff it shouldn't be hard to post it > > It's not about difficulty. > >> and it would be a nice thing to do for folks have scripts that >> notify them on changes of the errata pages. > > It's normal to have things in -stable where no erratum is issued. > > Why go to the hassle of a script to notify you of changes to a webpage when > you can just run "cd /usr/src; cvs -d $SOMEPATH -q up -r OPENBSD_whatever" > from cron?
Re: ISAKMPD
On 2011-07-14, Paul Suh wrote: > If it's easy to pull the diff it shouldn't be hard to post it It's not about difficulty. > and it would be a nice thing to do for folks have scripts that > notify them on changes of the errata pages. It's normal to have things in -stable where no erratum is issued. Why go to the hassle of a script to notify you of changes to a webpage when you can just run "cd /usr/src; cvs -d $SOMEPATH -q up -r OPENBSD_whatever" from cron?
Re: ISAKMPD
On Thu, Jul 14, 2011 at 11:49:16AM -0400, Paul Suh wrote: > Folks, > > Hmm -- it's not showing on the 4.9 or 4.8 Errata pages: > > http://www.openbsd.org/errata49.html > http://www.openbsd.org/errata48.html > > If it's easy to pull the diff it shouldn't be hard to post it, and it would be > a nice thing to do for folks have scripts that notify them on changes of the > errata pages. Errata are only published for critical stuff. I rather use my time to work on the upcoming release. I already spent time on the 4.8 stable commit. I've deciced that's enough. -Otto
Re: ISAKMPD
Folks, Hmm -- it's not showing on the 4.9 or 4.8 Errata pages: http://www.openbsd.org/errata49.html http://www.openbsd.org/errata48.html If it's easy to pull the diff it shouldn't be hard to post it, and it would be a nice thing to do for folks have scripts that notify them on changes of the errata pages. --Paul On Jul 14, 2011, at 10:45 AM, Otto Moerbeek wrote: > On Thu, Jul 14, 2011 at 10:36:54AM -0400, Wade, Daniel wrote: > >> It's tagged for 4.9-STABLE >> >> http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/dh.c > > And I just comitted a corresponding diff into 4.8 stable. > > Dunno if this warrants a patch. It's easy to pull the diff from cvs. > > -Otto > >> >> >> >> -Original Message- >> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of >> Steve >> Sent: Thursday, July 14, 2011 9:41 AM >> To: misc@openbsd.org >> Subject: ISAKMPD >> >> Hi all, >> >> Sorry this has been asked before but I can find no answer. >> >> Is there going to be an official patch for ISAKMPD for 4.8 4.9. >> >> I did see something in the bug tracking a while back but I now get the >> following error when I try to access it. >> >> Not FoundThe requested URL /cgi-bin/query-pr-wrapper was not found on this >> server. >> Apache/1.3.29 Server at cvs.openbsd.org Port 80 >> >> With thanks [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: ISAKMPD
On Thu, Jul 14, 2011 at 10:36:54AM -0400, Wade, Daniel wrote: > It's tagged for 4.9-STABLE > > http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/dh.c And I just comitted a corresponding diff into 4.8 stable. Dunno if this warrants a patch. It's easy to pull the diff from cvs. -Otto > > > > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of > Steve > Sent: Thursday, July 14, 2011 9:41 AM > To: misc@openbsd.org > Subject: ISAKMPD > > Hi all, > > Sorry this has been asked before but I can find no answer. > > Is there going to be an official patch for ISAKMPD for 4.8 4.9. > > I did see something in the bug tracking a while back but I now get the > following error when I try to access it. > > Not FoundThe requested URL /cgi-bin/query-pr-wrapper was not found on this > server. > Apache/1.3.29 Server at cvs.openbsd.org Port 80 > > With thanks
Re: ISAKMPD
It's tagged for 4.9-STABLE http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/dh.c -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Steve Sent: Thursday, July 14, 2011 9:41 AM To: misc@openbsd.org Subject: ISAKMPD Hi all, Sorry this has been asked before but I can find no answer. Is there going to be an official patch for ISAKMPD for 4.8 4.9. I did see something in the bug tracking a while back but I now get the following error when I try to access it. Not FoundThe requested URL /cgi-bin/query-pr-wrapper was not found on this server. Apache/1.3.29 Server at cvs.openbsd.org Port 80 With thanks
Re: ISAKMPD
On Thu, Jul 14, 2011 at 06:41:06AM -0700, Steve wrote: > Hi all, > > Sorry this has been asked before but I can find no answer. > > Is there going to be an official patch for ISAKMPD for 4.8 4.9. Do remedy what problem? > > I did see something in the bug tracking a while back but I now get the > following error when I try to access it. > > Not FoundThe requested URL /cgi-bin/query-pr-wrapper was not found on this > server. > Apache/1.3.29 Server at cvs.openbsd.org Port 80 What link are you trying to access? The bug tracking system is still offline at the moment. Ken > > With thanks
ISAKMPD
Hi all, Sorry this has been asked before but I can find no answer. Is there going to be an official patch for ISAKMPD for 4.8 4.9. I did see something in the bug tracking a while back but I now get the following error when I try to access it. Not FoundThe requested URL /cgi-bin/query-pr-wrapper was not found on this server. Apache/1.3.29 Server at cvs.openbsd.org Port 80 With thanks
Re: isakmpd and INVALID_COOKIE
Hmm.. sounds like this might be a candidate for -STABLE? --Paul On Jul 8, 2011, at 10:09 AM, Stuart Henderson wrote: > On 2011-07-08, Tony Sarendal wrote: >>>> If you're running isakmpd from 4.8 or 4.9 with IKE you want to pull >>>> up src/sbin/isakmpd/dh.c to r1.14 otherwise you will certainly >>>> see problems from time to time. >>> >> >> Is this a cosmetic thing or does it affect connectivity ? > > dh.c r1.14 affects stability. Between 4.7 and 4.8 isakmpd switched > from internal to openssl DH; an openssl function wasn't padding with > leading 0's where it was expected that they would, so there was junk > at the end of the key, causing key mismatches. [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: isakmpd and INVALID_COOKIE
On Fri, Jul 8, 2011 at 4:09 PM, Stuart Henderson wrote: > On 2011-07-08, Tony Sarendal wrote: > >> > If you're running isakmpd from 4.8 or 4.9 with IKE you want to pull > >> > up src/sbin/isakmpd/dh.c to r1.14 otherwise you will certainly > >> > see problems from time to time. > >> > > > > Is this a cosmetic thing or does it affect connectivity ? > > dh.c r1.14 affects stability. Between 4.7 and 4.8 isakmpd switched > from internal to openssl DH; an openssl function wasn't padding with > leading 0's where it was expected that they would, so there was junk > at the end of the key, causing key mismatches. > Sounds like a candidate to our issues that we are seeing on both 4.8 and 4.9. We see it quite easily as we run gre tunnels with bgp inside them using ipsec to encrypt gre. We are seeing the connectivity issue antyhing from a few times a day to a few times a week. And the time I caught it while it was going on things started working immediately after some bi-directional ike traffic. Regards Tony
Re: isakmpd and INVALID_COOKIE
On 2011-07-08, Tony Sarendal wrote: >> > If you're running isakmpd from 4.8 or 4.9 with IKE you want to pull >> > up src/sbin/isakmpd/dh.c to r1.14 otherwise you will certainly >> > see problems from time to time. >> > > Is this a cosmetic thing or does it affect connectivity ? dh.c r1.14 affects stability. Between 4.7 and 4.8 isakmpd switched from internal to openssl DH; an openssl function wasn't padding with leading 0's where it was expected that they would, so there was junk at the end of the key, causing key mismatches.
Re: isakmpd and INVALID_COOKIE
We are not using the tunnels for production use yet and have not started to measure uptime but we will do it soon. I have not noticed any problem when Im using the tunnels, only the messages. How ever. I was recommended by Stuart to pull up src/sbin/isakmpd/dh.c to 1.14 since there is a bug that are fixed in current but that caused problem from time to time with OpenBSD 4.8 and 4.9. I can send you the patch if you find it hard to figure it out. Best regards rancor Den 8 jul 2011 14.24 skrev "Tony Sarendal" :
Re: isakmpd and INVALID_COOKIE
On Mon, Jul 4, 2011 at 4:12 PM, rancor wrote: > Ah =) Thanks! > > // rancor > > 2011/7/4 Stuart Henderson : > > On 2011-07-02, rancor wrote: > >> Hi. > >> > >> I have two separate ipsec tunnels from 4.9 boxes and both are > >> generating this message i /var/log/messages once every hour or two > >> Jul 2 08:14:54 isakmpd[28247]: message_recv: invalid > >> cookie(s) 57603c2 > >> Jul 2 08:14:54 isakmpd[28247]: dropped message from > >> x.x.x.x port 500 due to notification type INVALID_COOKIE > >> > >> The tunnels works perfect but I still wounder why I got this message. > >> > >> This is my ipsec.conf on host x > >> ike esp transport from x.x.x.x to y.y.y.y psk > >> > >> and on host y > >> ike esp transport from y.y.y.y to x.x.x.x psk > >> > >> Any idea? > >> > >> Best regards rancor > >> > >> > > > > If you're running isakmpd from 4.8 or 4.9 with IKE you want to pull > > up src/sbin/isakmpd/dh.c to r1.14 otherwise you will certainly > > see problems from time to time. > Is this a cosmetic thing or does it affect connectivity ? We are having issues with gaps in connectivity on our ipsec links with a basic ike setup, an issue we're starting to look into now. Regards Tony
Re: isakmpd and INVALID_COOKIE
Ah =) Thanks! // rancor 2011/7/4 Stuart Henderson : > On 2011-07-02, rancor wrote: >> Hi. >> >> I have two separate ipsec tunnels from 4.9 boxes and both are >> generating this message i /var/log/messages once every hour or two >> Jul 2 08:14:54 isakmpd[28247]: message_recv: invalid >> cookie(s) 57603c2 >> Jul 2 08:14:54 isakmpd[28247]: dropped message from >> x.x.x.x port 500 due to notification type INVALID_COOKIE >> >> The tunnels works perfect but I still wounder why I got this message. >> >> This is my ipsec.conf on host x >> ike esp transport from x.x.x.x to y.y.y.y psk >> >> and on host y >> ike esp transport from y.y.y.y to x.x.x.x psk >> >> Any idea? >> >> Best regards rancor >> >> > > If you're running isakmpd from 4.8 or 4.9 with IKE you want to pull > up src/sbin/isakmpd/dh.c to r1.14 otherwise you will certainly > see problems from time to time.
Re: isakmpd and INVALID_COOKIE
On 2011-07-02, rancor wrote: > Hi. > > I have two separate ipsec tunnels from 4.9 boxes and both are > generating this message i /var/log/messages once every hour or two > Jul 2 08:14:54 isakmpd[28247]: message_recv: invalid > cookie(s) 57603c2 > Jul 2 08:14:54 isakmpd[28247]: dropped message from > x.x.x.x port 500 due to notification type INVALID_COOKIE > > The tunnels works perfect but I still wounder why I got this message. > > This is my ipsec.conf on host x > ike esp transport from x.x.x.x to y.y.y.y psk > > and on host y > ike esp transport from y.y.y.y to x.x.x.x psk > > Any idea? > > Best regards rancor > > If you're running isakmpd from 4.8 or 4.9 with IKE you want to pull up src/sbin/isakmpd/dh.c to r1.14 otherwise you will certainly see problems from time to time.
isakmpd and INVALID_COOKIE
Hi. I have two separate ipsec tunnels from 4.9 boxes and both are generating this message i /var/log/messages once every hour or two Jul 2 08:14:54 isakmpd[28247]: message_recv: invalid cookie(s) 57603c2 Jul 2 08:14:54 isakmpd[28247]: dropped message from x.x.x.x port 500 due to notification type INVALID_COOKIE The tunnels works perfect but I still wounder why I got this message. This is my ipsec.conf on host x ike esp transport from x.x.x.x to y.y.y.y psk and on host y ike esp transport from y.y.y.y to x.x.x.x psk Any idea? Best regards rancor
Re: Flag to move isakmpd default keys dir?
On 2011-06-14, Paul Suh wrote: > On Jun 7, 2011, at 11:29 AM, Rodolfo Gouveia wrote: >> I thought you could change those in isakmpd.conf: >> # Certificates stored in PEM format >> [X509-certificates] >> CA-directory= /etc/isakmpd/ca/ >> Cert-directory= /etc/isakmpd/certs/ >> CRL-directory= /etc/isakmpd/crls/ >> Private-key=/etc/isakmpd/private/local.key >> I took the above from the isakmpd.conf(5). > > Rodolfo, > > Thanks for the input, but the lockout to /etc/isakmpd actually happens in the > code -- see my reply to Stuart Henderson's post. Changing the values in > isakmpd.conf won't do anything. ah, m_priv_local_sanitize_path() does a realpath() lookup and enforces that the path is inside /etc/isakmpd (RO) or /var/run (RW). > Also, I'm not using isakmpd.conf -- I'm using ipsec.conf and running "isakmpd > -K" so that I can use ipsecctl. This is a lot simpler than isakmpd.conf and is > (I believe) the preferred way to do IPSec these days. there's no problem to mix ipsec.conf and isakmpd.conf, for example it's the only way to set certain things (e.g. lifetimes for the default peer). also note that ipsec.conf does not require -K, you can (and in some cases should) use ipsec.conf with keynote policies.
Re: Flag to move isakmpd default keys dir?
On Jun 7, 2011, at 11:29 AM, Rodolfo Gouveia wrote: > On 06/05/2011 02:37 AM, Paul Suh wrote: >> Folks, >> >> I've been working with the flashrd system for booting from compact flash >> media, and ran across a case where I'd like to make some changes to isakmpd, >> but before I do so I'm not sure that it's a good idea. >> >> The location for certificates, CA's, private keys, etc. is hard-coded in >> /usr/src/sbin/isakmpd/conf.h and conf.c to be /etc/isakmpd/. I'd like to be > > I thought you could change those in isakmpd.conf: > # Certificates stored in PEM format > [X509-certificates] > CA-directory= /etc/isakmpd/ca/ > Cert-directory= /etc/isakmpd/certs/ > CRL-directory= /etc/isakmpd/crls/ > Private-key=/etc/isakmpd/private/local.key > I took the above from the isakmpd.conf(5). Rodolfo, Thanks for the input, but the lockout to /etc/isakmpd actually happens in the code -- see my reply to Stuart Henderson's post. Changing the values in isakmpd.conf won't do anything. Also, I'm not using isakmpd.conf -- I'm using ipsec.conf and running "isakmpd -K" so that I can use ipsecctl. This is a lot simpler than isakmpd.conf and is (I believe) the preferred way to do IPSec these days. --Paul [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Flag to move isakmpd default keys dir?
On Jun 5, 2011, at 2:42 PM, Stuart Henderson wrote:
> On 2011/06/05 13:09, Paul Suh wrote:
>> Stuart,
>>
>> I tried using a symlink, but isakmpd didn't seem to like it.
>
> For the file or the whole directory?
> It seems to work with /etc/isakmpd -> /somewhere/else.
Stuart,
Sorry about the delay but my day job has been busy. When I try to move the
isakmpd directory and make it a symlink, I get a series of errors that look
like:
> Jun 14 16:27:25 redoubt isakmpd[24833]: exchange_run: doi->initiator
(0x88ecda80) failed
> Jun 14 16:29:34 redoubt isakmpd[19190]: m_priv_getfd: illegal path
"/etc/isakmpd/private//71.163.154.173"
> Jun 14 16:29:34 redoubt isakmpd[24833]: ike_auth_get_key: failed opening
"/etc/isakmpd/private//71.163.154.173"
> Jun 14 16:29:34 redoubt isakmpd[19190]: m_priv_getfd: illegal path
"/etc/isakmpd/private/local.key"
> Jun 14 16:29:34 redoubt isakmpd[24833]: ike_auth_get_key: failed opening
"/etc/isakmpd/private/local.key"
> Jun 14 16:29:34 redoubt isakmpd[24833]: rsa_sig_encode_hash: could not get
private key
> Jun 14 16:29:34 redoubt isakmpd[24833]: exchange_run: doi->initiator
(0x88ecd580) failed
It looks to me like the check happens in monitor.c, in m_priv_getfd(), which
calls m_priv_local_sanitize_path():
> /* Check that path/mode is permitted. */
> static int
> m_priv_local_sanitize_path(char *path, size_t pmax, int flags)
> {
> char new_path[PATH_MAX], var_run[PATH_MAX];
>
> /*
>* We only permit paths starting with
>* /etc/isakmpd/ (read only)
>* /var/run/ (rw)
> */
...
> if (strncmp(ISAKMPD_ROOT, new_path, strlen(ISAKMPD_ROOT)) == 0 &&
> (flags & O_ACCMODE) == O_RDONLY)
> return 0;
>
> bad_path:
> return 1;
> }
>
So it's going to take a patch to the code. That said, to go back to my
original question, can anyone tell me why this would be implemented in such a
fashion that forces isakmpd to have its true directory in /etc/isakmpd? I can
understand why there would be a runtime check against ISAKMPD_ROOT, but what
if I want to move ISAKMPD_ROOT to somewhere else specified by a runtime flag
(but still fixed in place)? Does that have any negative security implications?
Thanks in advance to anyone who has any insights.
--Paul
[demime 1.01d removed an attachment of type application/pkcs7-signature which
had a name of smime.p7s]
Re: Flag to move isakmpd default keys dir?
On 06/05/2011 02:37 AM, Paul Suh wrote: > Folks, > > I've been working with the flashrd system for booting from compact flash > media, and ran across a case where I'd like to make some changes to isakmpd, > but before I do so I'm not sure that it's a good idea. > > The location for certificates, CA's, private keys, etc. is hard-coded in > /usr/src/sbin/isakmpd/conf.h and conf.c to be /etc/isakmpd/. I'd like to be I thought you could change those in isakmpd.conf: # Certificates stored in PEM format [X509-certificates] CA-directory= /etc/isakmpd/ca/ Cert-directory= /etc/isakmpd/certs/ CRL-directory= /etc/isakmpd/crls/ Private-key=/etc/isakmpd/private/local.key I took the above from the isakmpd.conf(5). Cheers, --rodolfo
Re: Flag to move isakmpd default keys dir?
On 2011/06/05 13:09, Paul Suh wrote: > Stuart, > > I tried using a symlink, but isakmpd didn't seem to like it. For the file or the whole directory? It seems to work with /etc/isakmpd -> /somewhere/else.
Re: Flag to move isakmpd default keys dir?
Stuart, I tried using a symlink, but isakmpd didn't seem to like it. --Paul On Jun 5, 2011, at 7:00 AM, Stuart Henderson wrote: > Can't you just use symlinks? > > On 2011-06-05, Paul Suh wrote: >> Folks, >> >> I've been working with the flashrd system for booting from compact flash >> media, and ran across a case where I'd like to make some changes to isakmpd, >> but before I do so I'm not sure that it's a good idea. >> >> The location for certificates, CA's, private keys, etc. is hard-coded in >> /usr/src/sbin/isakmpd/conf.h and conf.c to be /etc/isakmpd/. I'd like to be >> able to set a flag on isakmpd at launch time that it should read the >> information from a different path, such as /flash/isakmpd, so that such >> system-specific information can be more easily preserved across upgrades of >> the base system. However, since this is getting into crypto and security >> territory, I'm not sure that it's a good idea to allow this path to be >> changed. >> >> I'm fairly certain that this is innocuous, but opinions, anyone, before I >> start hacking? [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: Flag to move isakmpd default keys dir?
Can't you just use symlinks? On 2011-06-05, Paul Suh wrote: > Folks, > > I've been working with the flashrd system for booting from compact flash > media, and ran across a case where I'd like to make some changes to isakmpd, > but before I do so I'm not sure that it's a good idea. > > The location for certificates, CA's, private keys, etc. is hard-coded in > /usr/src/sbin/isakmpd/conf.h and conf.c to be /etc/isakmpd/. I'd like to be > able to set a flag on isakmpd at launch time that it should read the > information from a different path, such as /flash/isakmpd, so that such > system-specific information can be more easily preserved across upgrades of > the base system. However, since this is getting into crypto and security > territory, I'm not sure that it's a good idea to allow this path to be > changed. > > I'm fairly certain that this is innocuous, but opinions, anyone, before I > start hacking? > > > --Paul > > [demime 1.01d removed an attachment of type application/pkcs7-signature which > had a name of smime.p7s]
Flag to move isakmpd default keys dir?
Folks, I've been working with the flashrd system for booting from compact flash media, and ran across a case where I'd like to make some changes to isakmpd, but before I do so I'm not sure that it's a good idea. The location for certificates, CA's, private keys, etc. is hard-coded in /usr/src/sbin/isakmpd/conf.h and conf.c to be /etc/isakmpd/. I'd like to be able to set a flag on isakmpd at launch time that it should read the information from a different path, such as /flash/isakmpd, so that such system-specific information can be more easily preserved across upgrades of the base system. However, since this is getting into crypto and security territory, I'm not sure that it's a good idea to allow this path to be changed. I'm fairly certain that this is innocuous, but opinions, anyone, before I start hacking? --Paul [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Re: IPSEC/ISAKMPD routing question
2011/1/10, Christoph Leser : > > I would like to ask: > > 1. Is it true, that isakmpd is supposed to accept any ID parameter of > type IPV4_ADDR_SUBNET ) in quick mode and set up a corresponing route, > even when it is the 'default' route? Yes, some people want all their traffic through encrypted tunnel. I used to bring IPv6 to places where people were ignoring it -- exactly this way. You might want to specify it in your policy file, like: remote_filter != "000.000.000.000-255.255.255.255" or remote_filter_type != "IPv4 subnet" > 2. What would I have to change to only accept those remote network Ids > that are configured in ipsec.conf? The above, or more specific. Sorry for the previous empty reply, I'll finally try to learn how to use an email client. -- Martin Pelikan
Re: IPSEC/ISAKMPD routing question
2011/1/10, Christoph Leser : > Hello, > > I have an IPSEC VPNs in Tunnelmode, configured in ipsec.conf with a line > like: > > ike active esp tunnel from to peer > > > > My isakmpd.policy file is > > # cat /etc/isakmpd/isakmpd.policy > Keynote-version: 2 > Authorizer: "POLICY" > Conditions: app_domain == "IPsec policy" && > esp_present == "yes" && > esp_enc_alg != "null" -> "true"; > > > Every thing works fine. > > But today, one of the remote_gateways was replaced by a misconfigured > new one, leading to the following phase-2 packet: > > 13:29:01.098526 .500 > .500: [udp sum > ok] isakmp v1.0 exchange QUICK_MODE > cookie: 70de03ee348066c9->76aabe706bed52c2 msgid: 301c68c8 len: > 300 > payload: HASH len: 24 > payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY > payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP > spisz: 4 xforms: 1 SPI: 0xcb2d2b94 > payload: TRANSFORM len: 32 > transform: 1 ID: AES > attribute LIFE_TYPE = SECONDS > attribute LIFE_DURATION = 28800 > attribute ENCAPSULATION_MODE = TUNNEL > attribute KEY_LENGTH = 128 > attribute AUTHENTICATION_ALGORITHM = HMAC_SHA > attribute GROUP_DESCRIPTION = 2 > payload: NONCE len: 20 > payload: KEY_EXCH len: 132 > payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 > payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 > [ttl 0] (id 1, len 328) > > > Please note that both ID parameters in this packet are 0.0.0.0. > > This lead to a routing entry ( made by isakmpd, I suppose ): > # netstat -rn | grep his_ip > default0 default0 0 > /esp/use/in > default0 default0 0 > /esp/require/out > > This route virtually disconnected my gateway from the external and from > the internal network, no ping to any address was successful. > > I would like to ask: > > 1. Is it true, that isakmpd is supposed to accept any ID parameter of > type IPV4_ADDR_SUBNET ) in quick mode and set up a corresponing route, > even when it is the 'default' route? > > 2. What would I have to change to only accept those remote network Ids > that are configured in ipsec.conf? > > Thanks > > -- Martin PelikC!n, Steadynet E-mail: martin.peli...@gmail.com, gpg key 0x7176E4C9 Tel: +420 724 818 573 Jabber: sztor...@jabber.cz web: http://cap.potazmo.cz/
IPSEC/ISAKMPD routing question
Hello, I have an IPSEC VPNs in Tunnelmode, configured in ipsec.conf with a line like: ike active esp tunnel from to peer My isakmpd.policy file is # cat /etc/isakmpd/isakmpd.policy Keynote-version: 2 Authorizer: "POLICY" Conditions: app_domain == "IPsec policy" && esp_present == "yes" && esp_enc_alg != "null" -> "true"; Every thing works fine. But today, one of the remote_gateways was replaced by a misconfigured new one, leading to the following phase-2 packet: 13:29:01.098526 .500 > .500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 70de03ee348066c9->76aabe706bed52c2 msgid: 301c68c8 len: 300 payload: HASH len: 24 payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0xcb2d2b94 payload: TRANSFORM len: 32 transform: 1 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = TUNNEL attribute KEY_LENGTH = 128 attribute AUTHENTICATION_ALGORITHM = HMAC_SHA attribute GROUP_DESCRIPTION = 2 payload: NONCE len: 20 payload: KEY_EXCH len: 132 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 [ttl 0] (id 1, len 328) Please note that both ID parameters in this packet are 0.0.0.0. This lead to a routing entry ( made by isakmpd, I suppose ): # netstat -rn | grep his_ip default0 default0 0 /esp/use/in default0 default0 0 /esp/require/out This route virtually disconnected my gateway from the external and from the internal network, no ping to any address was successful. I would like to ask: 1. Is it true, that isakmpd is supposed to accept any ID parameter of type IPV4_ADDR_SUBNET ) in quick mode and set up a corresponing route, even when it is the 'default' route? 2. What would I have to change to only accept those remote network Ids that are configured in ipsec.conf? Thanks
Re: Migrating from isakmpd to iked: interface name not recognized
Am 14.12.2010 um 17:23 schrieb Mike Belopuhov: mask2prefixlen functions are taken from bgpd. OK? Thanks, Axel --- axel@chaos1.de PGP-Key:29E99DD6 +49 151 2300 9283 computing @ chaos claudius
Re: Migrating from isakmpd to iked: interface name not recognized
On Mon, Dec 13, 2010 at 18:50 +0100, Axel Rau wrote:
> Hi all,
>
> in the man page for iked.conf, I read:
> "Addresses can be specified in CIDR notation (matching netblocks), as
> symbolic host names, interface names, or interface group names."
>
> In my iked.conf, I have
>local pppoe0
> but iked -vn complains:
> no IP address found for pppoe0
> /etc/iked.conf: 26: could not parse host specification
> .
> ifconfig pppoe0 | grep inet
> shows:
> inet 79.243.41.99 --> 87.186.224.28 netmask 0x
>
iked is still in the works. you shouldn't try to migrate to it unless
you can come up with fixes for such problems yourself.
mask2prefixlen functions are taken from bgpd. OK?
Index: parse.y
===
RCS file: /home/cvs/src/sbin/iked/parse.y,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 parse.y
--- parse.y 17 Nov 2010 16:43:45 - 1.14
+++ parse.y 14 Dec 2010 15:57:27 -
@@ -266,6 +266,8 @@ struct ipsec_addr_wrap *host_v4(const ch
struct ipsec_addr_wrap *host_dns(const char *, int);
struct ipsec_addr_wrap *host_if(const char *, int);
struct ipsec_addr_wrap *host_any(void);
+u_int8_tmask2prefixlen(struct sockaddr_in *);
+u_int8_tmask2prefixlen6(struct sockaddr_in6 *);
voidifa_load(void);
int ifa_exists(const char *);
struct ipsec_addr_wrap *ifa_lookup(const char *ifa_name);
@@ -1712,6 +1714,65 @@ host_any(void)
return (ipa);
}
+u_int8_t
+mask2prefixlen(struct sockaddr_in *sa_in)
+{
+ in_addr_t ina = sa_in->sin_addr.s_addr;
+
+ if (ina == 0)
+ return (0);
+ else
+ return (33 - ffs(ntohl(ina)));
+}
+
+u_int8_t
+mask2prefixlen6(struct sockaddr_in6 *sa_in6)
+{
+ u_int8_t l = 0, *ap, *ep;
+
+ /*
+* sin6_len is the size of the sockaddr so substract the offset of
+* the possibly truncated sin6_addr struct.
+*/
+ ap = (u_int8_t *)&sa_in6->sin6_addr;
+ ep = (u_int8_t *)sa_in6 + sa_in6->sin6_len;
+ for (; ap < ep; ap++) {
+ /* this "beauty" is adopted from sbin/route/show.c ... */
+ switch (*ap) {
+ case 0xff:
+ l += 8;
+ break;
+ case 0xfe:
+ l += 7;
+ return (l);
+ case 0xfc:
+ l += 6;
+ return (l);
+ case 0xf8:
+ l += 5;
+ return (l);
+ case 0xf0:
+ l += 4;
+ return (l);
+ case 0xe0:
+ l += 3;
+ return (l);
+ case 0xc0:
+ l += 2;
+ return (l);
+ case 0x80:
+ l += 1;
+ return (l);
+ case 0x00:
+ return (l);
+ default:
+ fatalx("non continguous inet6 netmask");
+ }
+ }
+
+ return (l);
+}
+
/* interface lookup routintes */
struct ipsec_addr_wrap *iftab;
@@ -1721,6 +1782,8 @@ ifa_load(void)
{
struct ifaddrs *ifap, *ifa;
struct ipsec_addr_wrap *n = NULL, *h = NULL;
+ struct sockaddr_in *sa_in;
+ struct sockaddr_in6 *sa_in6;
if (getifaddrs(&ifap) < 0)
err(1, "ifa_load: getifaddrs");
@@ -1737,17 +1800,13 @@ ifa_load(void)
if ((n->name = strdup(ifa->ifa_name)) == NULL)
err(1, "ifa_load: strdup");
if (n->af == AF_INET) {
- n->af = AF_INET;
- memcpy(&n->address, ifa->ifa_addr,
- sizeof(struct sockaddr_in));
- memcpy(&n->mask, ifa->ifa_addr,
- sizeof(struct sockaddr_in));
+ sa_in = (struct sockaddr_in *)ifa->ifa_addr;
+ memcpy(&n->address, sa_in, sizeof(*sa_in));
+ n->mask = mask2prefixlen(sa_in);
} else if (n->af == AF_INET6) {
- n->af = AF_INET6;
- memcpy(&n->address, ifa->ifa_addr,
- sizeof(struct sockaddr_in6));
- memcpy(&n->mask, ifa->ifa_addr,
- sizeof(struct sockaddr_in6));
+ sa_in6 = (struct sockaddr_in6 *)ifa->ifa_addr;
+ memcpy(&n->address, sa_in6, sizeof(*sa_in6));
+ n->mask = mask2prefixlen6(sa_in6);
}
n->next = NULL;
n->tail = n;
Re: Migrating from isakmpd to iked: interface name not recognized
Am 13.12.2010 um 18:50 schrieb Axel Rau: no IP address found for pppoe0 This happens with all devices, I have tried. Anybody succeeded in using an interface name as argument of option local? This is 4.8 stable on i386 generic. Axel --- axel@chaos1.de PGP-Key:29E99DD6 +49 151 2300 9283 computing @ chaos claudius
Migrating from isakmpd to iked: interface name not recognized
Hi all, in the man page for iked.conf, I read: "Addresses can be specified in CIDR notation (matching netblocks), as symbolic host names, interface names, or interface group names." In my iked.conf, I have local pppoe0 but iked -vn complains: no IP address found for pppoe0 /etc/iked.conf: 26: could not parse host specification . ifconfig pppoe0 | grep inet shows: inet 79.243.41.99 --> 87.186.224.28 netmask 0x Clueless: Axel --- axel@chaos1.de PGP-Key:29E99DD6 +49 151 2300 9283 computing @ chaos claudius
Re: isakmpd falling over: alternatives?
On 2010-05-26, Jacob Yocom-Piatt wrote: > i'm looking for an alternative still very early days, but Reyk just committed an ikev2 daemon, iked... http://article.gmane.org/gmane.os.openbsd.cvs/97036 http://article.gmane.org/gmane.os.openbsd.cvs/97037
Re: isakmpd falling over: alternatives?
Michiel van Baak wrote: And you want any help after talking to this list that way ? i explained my problem pretty succinctly in the first email - isakmpd is episodically unreliable, painful to debug, and i am looking for an alternative if anyone is using something else on openbsd for vpns e.g. ssh. instead of bryan responding to my query about alternatives, he condescendingly tells me what i already know about troubleshooting isakmpd: there are a dozen things to check that could be the cause of the problem e.g. endpoints too far out-of-sync, dpd not working, pf not passing esp. does it surprise you that i have a rude reply to someone in essence not reading my mail, or reading the first 2 sentences, and telling me to do what i already know to the be the case? note that at no point did i request assistance troubleshooting isakmpd, i asked about alternatives. it is also apparent that you did not take time to read my message but still have an opinion on it and my correspondingly abrasive reply to bryan's email. does this seem ridiculous to you? based on the lack of replies i speculate not many people use an ssh vpn... Nope, we run isakmpd. thanks for your input, it adds zero value. i would not be one bit surprised if part or a substantial portion of your and bryan's job security is related to the ability to 'read the chicken entrails' and keep isakmpd working properly. there are a couple of people i work with who are exceedingly good at this, as the two of you likely are, and even they cannot deny how challenging it is to debug certain problems. is it surprising i am seeking an alternative? at this point i have to conclude isakmpd is pretty much it for vpns on openbsd unless you want to run openvpn. i'll post back if ssh ends up working out.
Re: isakmpd falling over: alternatives?
On May 26, 2010, at 1:58 PM, Jacob Yocom-Piatt wrote: > Bryan wrote: >> On Tue, May 25, 2010 at 14:06, j...@fixedpointgroup.com >> wrote: >> >>> over the past several years i have encountered a variety of problems with >>> isakmpd that range from difficult to translate error messages to tunnels >>> dropping without explanation. >>> >>> > seriously... > > have you ever used isakmpd? I use it all the time between roughly 10 boxen. > i ask this because i get the impression that you have not used it much if you missed the point of my message. it totally sucks - i've been using it since 2003 and very little has changed except the ipsecctl interface making it quicker to setup tunnels. a number of people in the openbsd community have discussed the possibility of a total rewrite with me over the past several years because they too believe it is old and flaky. > > isakmpd is brittle as hell and endpoints being snapshots that are a few months apart is enough to cause serious interoperation problems. someone may or may not have developed an improved version of isakmpd that runs on openbsd, i will not name names, and that is because isakmpd is not commercial grade software. there is a lot of neat and challenging crypto code in isakmpd but, imo, further improvements are tolerated turd polishing. > > i'm looking for an alternative so i don't have to resort to excessive debugging and answering a series of 10 questions to figure out wtf is going on. i am not saying that your list of questions is the wrong way to debug this, it's totally correct, only that you're a fucking idiot for not getting the point of my original message. it is amazing that you have the patience to follow the ridiculously long trail to troubleshoot and fix isakmpd but don't see that walking this trail is due to the code being old and brittle. > And you want any help after talking to this list that way ? > based on the lack of replies i speculate not many people use an ssh vpn... Nope, we run isakmpd.
Re: isakmpd falling over: alternatives?
Bryan wrote: On Tue, May 25, 2010 at 14:06, j...@fixedpointgroup.com wrote: over the past several years i have encountered a variety of problems with isakmpd that range from difficult to translate error messages to tunnels dropping without explanation. Greetings, Did you try different hardware? Did you troubleshoot the issue and raise a question on m...@? Are you using 4.7 or even -current? What is on the distant end? is it openbsd -> openbsd, or is it something else on the other end? What network adapters are being used in both boxes? Are you using wireless to connect through to the distant end? shaky wireless could cause connection issues. I mean, have you asked any questions, or asked for help? Maybe if you took the time to explain what is wrong, you might get an answer. Make sure you have a dmesg, and can reproduce the error in 4.7 (-current or latest cvs pull is even better), and any and all error messages, and any verbose logfile output you can receive, your ipsec.conf, and pf.conf if you use that... Only you can help you... seriously... have you ever used isakmpd? i ask this because i get the impression that you have not used it much if you missed the point of my message. it totally sucks - i've been using it since 2003 and very little has changed except the ipsecctl interface making it quicker to setup tunnels. a number of people in the openbsd community have discussed the possibility of a total rewrite with me over the past several years because they too believe it is old and flaky. isakmpd is brittle as hell and endpoints being snapshots that are a few months apart is enough to cause serious interoperation problems. someone may or may not have developed an improved version of isakmpd that runs on openbsd, i will not name names, and that is because isakmpd is not commercial grade software. there is a lot of neat and challenging crypto code in isakmpd but, imo, further improvements are tolerated turd polishing. i'm looking for an alternative so i don't have to resort to excessive debugging and answering a series of 10 questions to figure out wtf is going on. i am not saying that your list of questions is the wrong way to debug this, it's totally correct, only that you're a fucking idiot for not getting the point of my original message. it is amazing that you have the patience to follow the ridiculously long trail to troubleshoot and fix isakmpd but don't see that walking this trail is due to the code being old and brittle. based on the lack of replies i speculate not many people use an ssh vpn...
Re: isakmpd falling over: alternatives?
On Tue, May 25, 2010 at 14:06, j...@fixedpointgroup.com wrote: > over the past several years i have encountered a variety of problems with > isakmpd that range from difficult to translate error messages to tunnels > dropping without explanation. > > > Greetings, Did you try different hardware? Did you troubleshoot the issue and raise a question on m...@? Are you using 4.7 or even -current? What is on the distant end? is it openbsd -> openbsd, or is it something else on the other end? What network adapters are being used in both boxes? Are you using wireless to connect through to the distant end? shaky wireless could cause connection issues. I mean, have you asked any questions, or asked for help? Maybe if you took the time to explain what is wrong, you might get an answer. Make sure you have a dmesg, and can reproduce the error in 4.7 (-current or latest cvs pull is even better), and any and all error messages, and any verbose logfile output you can receive, your ipsec.conf, and pf.conf if you use that... Only you can help you... Regards, Bryan
isakmpd falling over: alternatives?
over the past several years i have encountered a variety of problems with isakmpd that range from difficult to translate error messages to tunnels dropping without explanation. i have just recently had a rash of tunnel dropping, which can frequently be fixed by one endpoint doing pkill -x isakmpd isakmpd -Kv ipsecctl -f /etc/ipsec.conf in this most recent case doing this at both ends of the tunnel repeatedly does not fix the problem. i am sick of trying to work with isakmpd so i am interested in finding an alternative. the possibility of doing an ssh-based vpn seems appealing but i am not sure it will perform in the same capacity or have its own problems. i would appreciate input on this topic. cheers, jake
Re: isakmpd: tiny patch
This has been committed. Thanks.
-mark
lum@
===
Hello,
while playing with isakmpd, I found that it would be nice to have a
complement for the "isakmpd: exiting" log entry.
Index: isakmpd.c
===
RCS file: /cvs/src/sbin/isakmpd/isakmpd.c,v
retrieving revision 1.97
diff -u -r1.97 isakmpd.c
--- isakmpd.c 12 May 2008 19:15:02 - 1.97
+++ isakmpd.c 7 Apr 2010 17:16:47 -
@@ -398,6 +398,7 @@
log_to(stderr);
parse_args(argc, argv);
log_init(debug);
+ log_print("isakmpd: starting");
/* Open protocols and services databases. */
setprotoent(1);
Re: isakmpd will not initiate connection to Cisco ASA
Looks like they are sending a delete. I guess I will delete and recreate this tunnel isakmpd: Peer 1.1.1.1 made us delete live SA for proto 1, initiator id: 1.1.1.1, responde r id: 2.2.2.2 On Tue, Nov 17, 2009 at 10:37 AM, Christoph Leser wrote: > Are you sure that obsd does not try to initiate the connection at least > once? > > I have noticed the following problem with cisco: > > Some Cisco models delete the security association after an inactivity > timeout, they call it "Cisco IPSec Security Association Idle Timers". > > When this happens, openBSDs drop the information for this tunnel and is > unable to recreate it. Cisco keeps the information and can reestablish the > connection when someone pings or otherwise addresses the remote end. > > I had a short conversation about this with Hans-Jvrg Hvxer, but cannot say > whether this behaviour is desired or considered a bug. > > I would try to delete the tunnel complete and configure it again while > running tcpdump on the external interface ( or enable isakmpd packet > capture, see the -L switch of isakmpd ). > > This will at least answer the question, whether openBSD attempts to > establish the connection when the tunnel is defined for the first time. > > Regards > > Christoph > > > -Urspr|ngliche Nachricht- > > Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] > > Im Auftrag von Chris Bullock > > Gesendet: Dienstag, 17. November 2009 15:45 > > An: misc@openbsd.org > > Betreff: isakmpd will not initiate connection to Cisco ASA > > > > > > We have many tunnels and for some reason I just set up a > > tunnel with a Cisco ASA and we can not initiate the > > connection from the OpenBSD side. If the Cisco side pings a > > device on the OpenBSD side the tunnel comes up. On the Cisco > > side they have bidirectional enabled, and they are not seeing > > the OpenBSD try to initiate the tunnel. Any help would be > > appreciated, Regards, Chris Bullock
Re: isakmpd will not initiate connection to Cisco ASA
I have seen this same behaviour with a configured Cisco ASA endpoint. The Cisco end needs to ping our network to initiate the connection, and from watching the IPSEC negotiations from the isakmpd capture files, the Cisco end rejects our proposal, but we accept their proposal. As Dag says, both ends are supposedly configured for the same encryption scheme, although the Cisco rejects our proposal. Cam Dag Richards wrote: I recently had a problem that looked similar. I would try to bring up the tunnels configured in ipsec.conf. No Phase 2 A dump on the external iface revealed that we were sending Phase 1 initiation. Their end was configured for a different encryption scheme, than ours ( even though we had agreed on one ). Since they were showing up with a vlaid PSK we accepted the values they proposed, whereas they rejected our proposal's. tcpdump -nvs1400 port 500 Christoph Leser wrote: Are you sure that obsd does not try to initiate the connection at least once? I have noticed the following problem with cisco: Some Cisco models delete the security association after an inactivity timeout, they call it "Cisco IPSec Security Association Idle Timers". When this happens, openBSDs drop the information for this tunnel and is unable to recreate it. Cisco keeps the information and can reestablish the connection when someone pings or otherwise addresses the remote end. I had a short conversation about this with Hans-Jvrg Hvxer, but cannot say whether this behaviour is desired or considered a bug. I would try to delete the tunnel complete and configure it again while running tcpdump on the external interface ( or enable isakmpd packet capture, see the -L switch of isakmpd ). This will at least answer the question, whether openBSD attempts to establish the connection when the tunnel is defined for the first time. Regards Christoph -Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Chris Bullock Gesendet: Dienstag, 17. November 2009 15:45 An: misc@openbsd.org Betreff: isakmpd will not initiate connection to Cisco ASA We have many tunnels and for some reason I just set up a tunnel with a Cisco ASA and we can not initiate the connection from the OpenBSD side. If the Cisco side pings a device on the OpenBSD side the tunnel comes up. On the Cisco side they have bidirectional enabled, and they are not seeing the OpenBSD try to initiate the tunnel. Any help would be appreciated, Regards, Chris Bullock
Re: isakmpd will not initiate connection to Cisco ASA
I recently had a problem that looked similar. I would try to bring up the tunnels configured in ipsec.conf. No Phase 2 A dump on the external iface revealed that we were sending Phase 1 initiation. Their end was configured for a different encryption scheme, than ours ( even though we had agreed on one ). Since they were showing up with a vlaid PSK we accepted the values they proposed, whereas they rejected our proposal's. tcpdump -nvs1400 port 500 Christoph Leser wrote: Are you sure that obsd does not try to initiate the connection at least once? I have noticed the following problem with cisco: Some Cisco models delete the security association after an inactivity timeout, they call it "Cisco IPSec Security Association Idle Timers". When this happens, openBSDs drop the information for this tunnel and is unable to recreate it. Cisco keeps the information and can reestablish the connection when someone pings or otherwise addresses the remote end. I had a short conversation about this with Hans-Jvrg Hvxer, but cannot say whether this behaviour is desired or considered a bug. I would try to delete the tunnel complete and configure it again while running tcpdump on the external interface ( or enable isakmpd packet capture, see the -L switch of isakmpd ). This will at least answer the question, whether openBSD attempts to establish the connection when the tunnel is defined for the first time. Regards Christoph -Urspr|ngliche Nachricht- Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] Im Auftrag von Chris Bullock Gesendet: Dienstag, 17. November 2009 15:45 An: misc@openbsd.org Betreff: isakmpd will not initiate connection to Cisco ASA We have many tunnels and for some reason I just set up a tunnel with a Cisco ASA and we can not initiate the connection from the OpenBSD side. If the Cisco side pings a device on the OpenBSD side the tunnel comes up. On the Cisco side they have bidirectional enabled, and they are not seeing the OpenBSD try to initiate the tunnel. Any help would be appreciated, Regards, Chris Bullock
Re: isakmpd will not initiate connection to Cisco ASA
Are you sure that obsd does not try to initiate the connection at least once? I have noticed the following problem with cisco: Some Cisco models delete the security association after an inactivity timeout, they call it "Cisco IPSec Security Association Idle Timers". When this happens, openBSDs drop the information for this tunnel and is unable to recreate it. Cisco keeps the information and can reestablish the connection when someone pings or otherwise addresses the remote end. I had a short conversation about this with Hans-Jvrg Hvxer, but cannot say whether this behaviour is desired or considered a bug. I would try to delete the tunnel complete and configure it again while running tcpdump on the external interface ( or enable isakmpd packet capture, see the -L switch of isakmpd ). This will at least answer the question, whether openBSD attempts to establish the connection when the tunnel is defined for the first time. Regards Christoph > -Urspr|ngliche Nachricht- > Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] > Im Auftrag von Chris Bullock > Gesendet: Dienstag, 17. November 2009 15:45 > An: misc@openbsd.org > Betreff: isakmpd will not initiate connection to Cisco ASA > > > We have many tunnels and for some reason I just set up a > tunnel with a Cisco ASA and we can not initiate the > connection from the OpenBSD side. If the Cisco side pings a > device on the OpenBSD side the tunnel comes up. On the Cisco > side they have bidirectional enabled, and they are not seeing > the OpenBSD try to initiate the tunnel. Any help would be > appreciated, Regards, Chris Bullock
isakmpd will not initiate connection to Cisco ASA
We have many tunnels and for some reason I just set up a tunnel with a Cisco ASA and we can not initiate the connection from the OpenBSD side. If the Cisco side pings a device on the OpenBSD side the tunnel comes up. On the Cisco side they have bidirectional enabled, and they are not seeing the OpenBSD try to initiate the tunnel. Any help would be appreciated, Regards, Chris Bullock
isakmpd tunnels dropping routes to subnet
Hi List
I have several Soekris OpenBSD boxes running a mix of 4.3, 4.4 and 4.5
all connecting multiple subnets together on a central server running
OpenBSD 4.5 (this server is a Dell Poweredge 860).
Most of the routers work, but some of them drop the routes to one of my
subnets. This happens to be the most critical subnet and so causes
quite a problem. The really odd thing is that when I run isakmpd in
debug mode (on the problem routers) the subnet route does not get
dropped. Even more odd/annoying is this problem is intermittent and
tends to only affect one of the routers at any one time.
The problem routers all have an internal network of 10.x.0.0/24. My
central location is 10.100.0.0/24 (this is the one that gets dropped by
the remote routers). My routers that don't have a problem are either on
a 192.168.x.0/24 network and/or are running IPCOP.
A sample of one of the problem router ipsec.conf:-
---snip---
local_network="10.30.0.0/24"
remote_networks="{ 10.100.0.0/24, 192.168.10.0/24, 192.168.254.0/24,
10.10.0.0/24, 10.20.0.0/24, 10.40.0.0/24, 10.50.0.0/24, 10.60.0.0/24 }"
local_peer="10.30.0.1"
remote_peer="xxx.xxx.xxx.xxx"
key="**"
# IPSec tunnel
ike active esp from $local_network to $remote_networks local $local_peer
peer $remote_peer psk $key
---snip---
The central location routers has this entry for this router:-
---snip---
ike esp from { 10.100.0.0/24, 192.168.10.0/24, 192.168.254.0/24,
10.10.0.0/24, 10.20.0.0/24, 10.40.0.0/24, 10.50.0.0/24, 10.60.0.0/24 }
to 10.30.0.0/24 local $me peer xxx.xxx.xxx.xxx psk **
---snip---
Thanks in advance!!!
Danny
This message has been scanned for viruses
Updated: Dynamic IP issues with isakmpd
Per my earlier post I'm trying to debug an IPSec Tunnel between two
Soekris boxes running OpenBSD 4.5. One side of the connection has
static IP, the other is a DSL connection and uses dynamic IP. When the
IP address changes the tunnel drops and the only way I've come up with
to restore it is to log into the remote side and do the following
shell commands:
# kill $(cat /var/run/isakmpd.pid)
# /sbin/isakmpd -K
# /sbin/ipsecctl -f /etc/ipsec.conf
I just spent an hour working on the remote side and I've come up with
more information on the problem. Particularly with isakmpd
My /etc/ipsec.conf looks like this:
my_fqdn="myfqdn.example.com"
my_ip="1.2.3.4"
my_network="192.168.64.0/24"
remote_fqdn="remotefqdn.example.com"
remote_ip="5.6.7.8"
remote_network="192.168.65.0/24"
ike dynamic esp from { $my_ip $my_network} \
to { $remote_fqdn $remote_network} \
local $my_ip peer $remote_fqdn \
srcid $my_fqdn dstid $remote_fqdn
ike dynamic esp from $my_ip to $remote_fqdn \
local $my_ip peer $remote_fqdn \
srcid $my_fqdn dstid $remote_fqdn
Through dhclient-script and dhclient-exit-hooks I'm able to do this:
# ipsecctl -F -D my_ip=${new_ip_address} -f /etc/ipsec.conf
At the time that dhclient changes my IP address but, this doesn't
work. Isakmpd complains thusly:
Aug 29 16:19:53 stompbox isakmpd[14934]: udp_create: 1.2.3.4:500 must
exist as a listener too
Aug 29 16:19:53 stompbox isakmpd[14934]: exchange_establish: transport
"udp" for peer "peer-5.6.7.8-local-1.2.3.4" could not be created
I believe these messages are cause by the first call to isakmpd which
happens before I know what IP address I have.
If I could get this piece of things to work I think that could solve
the rest of my problems by just running ddclient as a daemon with a
timeout of 5 minutes.
Again, Thanks for any assistance
-- Chris
P.S. my earlier post is below.
On Aug 29, 2009, at 2:09 PM, Christopher Hilton wrote:
I'm having Dynamic IP issues with dhclient, ddclient, and isakmpd,
on OpenBSD running on a Soekris net4511 as a residential gateway. My
connection is a consumer grade AT&T DSL line. My IP address changes
an average of once every 18 hours but that is not set. I have an
IPSEC tunnel configured using certificates and FQDN identifiers
between the Soekris and another OpenBSD box in my basement on a
static IP connection. This whole setup works as follows: The Soekris
get's its external IP via dhclient. Ddclient updates this address at
DynDNS.com and isakmpd should then follow by establishing the
tunnel. All of this works great on boot. When the external IP get's
changed by AT&T, isakmpd fails because it continues to use the old
IP address for the IKE exchange. I can restore the tunnel with the
following shell commands:
# kill $(cat /var/run/isakmpd.pid)
# /usr/sbin/isakmpd -K
# /usr/sbin/ipsecctl -F -f /etc/ipsec.conf
Shouldn't the ipsec tunnel get restored by just the third command?
Things that I've tried. I've changed the dhclient-script to one that
calls enter and exit hooks like the stock ISC dhclient does and I've
added a little bit of scripting there to capture the IP address
change event but when I add the call to do the updates within this
script dhclient fails and dies. I'm inclined to believe that this is
a timeout issue since the exact same modifications work on a Soekris
Net5501. The only differences that I can see between the two of them
are that ddclient takes about 8 ~ 10 seconds on the Net4511 and
about 1.5 seconds on the Net5501.
I've also tried running sshd on the box and having it available so I
could just log in and manage the transition on my own but that seems
to fail also. Do I need to restart pf after an address change on my
external interface?
Thanks for any help
-- Chris
Re: ipsec.conf ipsecctl isakmpd
On Aug 10, 2009, at 6:37 PM, Christopher Sean Hilton wrote: I have a couple of questions regarding setting up ipsec. I've read the "4 minutes" page and modified the older setup to work with 2 OpenBSD 4.5 boxes. That's enough to get me going with an IPsec tunnel by IP addresses but one side of my connection is a consumer grade DSL line which wants to have it's address changed every 5 minutes (sigh). I obviously need to setup ipsec with FQDN. I initially tried to do this with certificates but I couldn't get things to work so I've rolled back to using public keys and everything appears to be okay. My question is this: When you use certficates does isakmpd still use /etc/isakmpd/private/local.key as the private key for the crypto negotiation or can that be changed. Thanks for the followups. IT looks like local.key is the key if you don't use the local tag in your configuration as in: ike passive esp from hisname.hisnet.histld to myname.mynet.mytld \ local my_identifier Thanks again. -- Chris Chris Hilton tildeChris -- http://myblog.vindaloo.com email -- chris/at/vindaloo/ dot/com .~ ~ .--.~ ~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~. "I'm on the outside looking inside, What do I see? Much confusion, disillution, all around me." -- Ian McDonald / Peter Sinfield
Re: ipsec.conf ipsecctl isakmpd
On Mon, Aug 10, 2009 at 06:37:41PM -0400, Christopher Sean Hilton wrote: > I have a couple of questions regarding setting up ipsec. > > I've read the "4 minutes" page and modified the older setup to work with > 2 OpenBSD 4.5 boxes. That's enough to get me going with an IPsec tunnel > by IP addresses but one side of my connection is a consumer grade DSL > line which wants to have it's address changed every 5 minutes (sigh). I > obviously need to setup ipsec with FQDN. I initially tried to do this > with certificates but I couldn't get things to work so I've rolled back > to using public keys and everything appears to be okay. > > My question is this: When you use certficates does isakmpd still use > > /etc/isakmpd/private/local.key > > as the private key for the crypto negotiation or can that be changed. By default isakmpd will use local.key, if you wish to use more than one private key you can rename the key to match the value of your ISAKMP Phase1-ID. For example, if your Phase1-ID is ID-type=IPV4_ADDR and Address=10.10.10.10 the corresponding key file would be /etc/isakmpd/private/10.10.10.10 Hoep this helps -- Mathieu Sauve-Frankel
ipsec.conf ipsecctl isakmpd
I have a couple of questions regarding setting up ipsec. I've read the "4 minutes" page and modified the older setup to work with 2 OpenBSD 4.5 boxes. That's enough to get me going with an IPsec tunnel by IP addresses but one side of my connection is a consumer grade DSL line which wants to have it's address changed every 5 minutes (sigh). I obviously need to setup ipsec with FQDN. I initially tried to do this with certificates but I couldn't get things to work so I've rolled back to using public keys and everything appears to be okay. My question is this: When you use certficates does isakmpd still use /etc/isakmpd/private/local.key as the private key for the crypto negotiation or can that be changed. -- Chris Chris Hilton tildeChris -- http://myblog.vindaloo.com email -- chris/at/vindaloo/ dot/com .~ ~ .--.~ ~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~. "I'm on the outside looking inside, What do I see? Much confusion, disillution, all around me." -- Ian McDonald / Peter Sinfield
isakmpd question
Hey List !
quick question... Is there a way to clear one specific VPN in the
ipsecctl reference table or a really need to clear the entire table ? (
ipsecctl -F )
Example... I got a bunch of VPN ( 50 + ) , need to flush the state of
this particular one:
BSD 4.3 // config in /etc/ipsec.conf
# IPSec encapsulation of GRE tunnel OSPF between office
ike esp transport from { 10.200.0.10 } to { 192.168.1.200 } \
local ip.my.primary.office peer ip.my.remote.office \
main auth hmac-sha1 enc aes-256 group modp1024 \
quick auth hmac-sha1 enc aes-256 group modp1024
Regards
Marcus
Re: isakmpd log file - time in human form?
Sorry, I had a blackout, the time is obvious. mp -Original Message- From: Petvalsky, Martin Sent: Wednesday, April 22, 2009 11:14 AM To: 'misc@openbsd.org' Subject: isakmpd log file - time in human form? Hello, I am debugging an IPsec tunnel by running isakmpd -L -d -DA=90 > /root/scripts/isakmpd.log 2>&1 and I can't find a way how to switch or convert the time to a human readable form. Logfile shows: ... 103749.319100 Default log_debug_cmd: log level changed from 0 to 90 for class 0 [priv] 103749.319341 Default log_debug_cmd: log level changed from 0 to 90 for class 1 [priv] ... The problem I am dealing with happens after a longer time, I suspect incorrect phase 2 re-establishment so I need to understand the time records. Please help me, if you know how. Thank you, Martin Petvalsky
isakmpd log file - time in human form?
Hello, I am debugging an IPsec tunnel by running isakmpd -L -d -DA=90 > /root/scripts/isakmpd.log 2>&1 and I can't find a way how to switch or convert the time to a human readable form. Logfile shows: ... 103749.319100 Default log_debug_cmd: log level changed from 0 to 90 for class 0 [priv] 103749.319341 Default log_debug_cmd: log level changed from 0 to 90 for class 1 [priv] ... The problem I am dealing with happens after a longer time, I suspect incorrect phase 2 re-establishment so I need to understand the time records. Please help me, if you know how. Thank you, Martin Petvalsky
Problem with isakmpd, PAYLOAD_MALFORMED and packet lengths
Hi misc, I've been trying to configure the following IPSec client using certificates, but with no success. I want to use it a roadwarrior setup: http://www.ncp-e.com/en/vpn-szenarien-produkte/vpn-produkte/secure-entry-client.html Of course, I'm using isakmpd on the OpenBSD side (4.3). I did manage to get it working with PSK though. The problem is reported on the client side like this (error line): Ike: phase1:name(NCP test) - error - PAYLOAD_MALFORMED isakmpd reports that phase 1 has finished though: 203820.350607 Default isakmpd: phase 1 done: [snip] There are a couple of odd things that I'm noticing. When I run isakmpd to dump everything to /var/run/isakmpd.pcap, I then review it with tcpdump, one of the packets is like this (I've changed the IP addresses to ficticious ones): 18:40:45.034602 200.1.2.3.500 > 190.1.8.1.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 6ae7205b40eda6dc->1673892cac8a5b55 msgid: len: 200 payload: ID len: 12 type: IPV4_ADDR = 200.1.2.3 payload: SIG len: 132 payload: NOTIFICATION len: 28 notification: INITIAL CONTACT (6ae7205b40eda6dc->1673892cac8a5b55) [ttl 0] (id 1, len 228) As you can see, the length is of 200 octets. But then, when capturing the same thing on the Windows box, using wireshark, I get this: Frame 9 (260 bytes on wire, 260 bytes captured) Ethernet II, Src: Riverdel_c6:42:91 (00:30:b8:c6:42:91), Dst: Dell_58:de:fb (00:15:c5:58:de:fb) Internet Protocol, Src: 200.1.2.3 (200.1.2.3), Dst: 190.1.8.1 (190.1.8.1) User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500) Internet Security Association and Key Management Protocol Initiator cookie: 6AE7205B40EDA6DC Responder cookie: 1673892CAC8A5B55 Next payload: Identification (5) Version: 1.0 Exchange type: Identity Protection (Main Mode) (2) Flags: 0x81 Message ID: 0x Length: 204 Encrypted payload (176 bytes) It seems to be of 204 bytes. I got this very same result when capturing on the physical interface of the VPN gateway, but I can't find the pcap file right now. So there's nothing in the middle changing this value. Also the Flags fields seem to differ. Also, right now, for some reason, the client is trying to use udpencap (it wasn't in the previous example), and I'm getting udp checksum errors. I did get the certificates authentication working with thegreenbowclient, but couldn't get it to work when using Windows Mobile (my real objective), so I'm moving on with this one (by the way, did any of you have any luck configuring thegreenbow using Windows Mobile with a OpenBSD VPN gateway?). So I really don't know if isakmpd is messing with the packets somewhere. Here's my isakmpd.conf file: [General] Default-phase-1-lifetime=86400,60:86400 Default-phase-2-lifetime=3600,60:86400 Retransmits=5 Exchange-max-time=120 Listen-on=200.1.2.3 [Phase 1] default=checkpoint [checkpoint] Phase=1 Transport=udp Local-address=200.1.2.3 Address=200.1.2.3 Configuration=Default-main-mode [Phase 2] Connections=VPN-Checkpoint [VPN-Checkpoint] Phase=2 ISAKMP-peer=checkpoint Configuration=Default-quick-mode Local-ID=network_corporate Remote-ID=client_thegreenbow [network_corporate] ID-type=IPV4_ADDR_SUBNET Network=192.168.18.0 Netmask=255.255.255.0 [client_thegreenbow] ID-type=IPV4_ADDR_SUBNET Network=10.9.0.0 Netmask=255.255.0.0 [Default-main-mode] DOI=IPSEC EXCHANGE_TYPE=ID_PROT Transforms=3DES-SHA-GRP2-RSA_SIG #Transforms=3DES-SHA-GRP2 [Default-quick-mode] DOI=IPSEC EXCHANGE_TYPE=QUICK_MODE Suites=QM-ESP-3DES-SHA-SUITE [X509-certificates] CA-directory= /etc/isakmpd/ca/ Cert-directory= /etc/isakmpd/certs/ CRL-directory= /etc/isakmpd/crls/ Private-key=/etc/isakmpd/private/ncp.key My isakmpd.policy file: KeyNote-Version: 2 Authorizer: "POLICY" I haven't used ipsec.conf for this, as I haven't found examples using X.509 certificates. Any help with this will be greatly appreciated, Thanks Martmn.
Re: isakmpd does not initiate quick mode after main mode is established
I found that some of my problems are related to 'DELETE' messages from the peer ( cisco ASA's , for example ). There is another thread in this forum discussion this issue. Hans-Joerg Hoexer said that obsd/isakmpd should handle this case, but he will look into it. I would be interested to know if your problems are related to these 'DELETE' messages from the remote side. I see varying behaviour when these messages come in: . Sometimes the flows are deleted, and any further traffic gives 'no route to host' . Sometimes the flows are still shown ( in ipssecctl -sflow or netstat -rn -f encap ) and I see traffic on enc0, but no encap on the external interface. What do you see, when the connection dies? Regards Christoph > -Urspr|ngliche Nachricht- > Von: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] > Im Auftrag von Christian Weisgerber > Gesendet: Sonntag, 25. Januar 2009 23:10 > An: misc@openbsd.org > Betreff: Re: isakmpd does not initiate quick mode after main > mode is established > > > Christoph Leser wrote: > > > I'm still struggling to keep my ipsec vpns running smoothly. > > FWIW, I mostly use IPsec on my home WLAN and I observe a > similar lack of reliability. My laptop sets up two IPsec > associations, one IPv4 and one IPv6, and from time to time > one of these or both fail inexplicably (no response, no > proposal chosen) but eventually get established within ten > minutes or so. > > Since this is WLAN, I have considered that packet loss may > screw up the ISAKMP negotiation, but I haven't investigated. > > I wonder how people who run a large number of IPsec > associations in production settings deal with this or if they > are seeing it at all. > > -- > Christian "naddy" Weisgerber > na...@mips.inka.de
Re: isakmpd does not initiate quick mode after main mode is established
Christoph Leser wrote: > I'm still struggling to keep my ipsec vpns running smoothly. FWIW, I mostly use IPsec on my home WLAN and I observe a similar lack of reliability. My laptop sets up two IPsec associations, one IPv4 and one IPv6, and from time to time one of these or both fail inexplicably (no response, no proposal chosen) but eventually get established within ten minutes or so. Since this is WLAN, I have considered that packet loss may screw up the ISAKMP negotiation, but I haven't investigated. I wonder how people who run a large number of IPsec associations in production settings deal with this or if they are seeing it at all. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Cisco IPSec Security Association Idle Timers and isakmpd
> -Urspr|ngliche Nachricht- > Von: dug [mailto:d...@xgs-france.com] > Gesendet: Montag, 19. Januar 2009 17:44 > An: Hans-Joerg Hoexer > Cc: Christoph Leser; misc@openbsd.org > Betreff: Re: Cisco IPSec Security Association Idle Timers and isakmpd > > > Le 19 janv. 09 ` 17:37, Hans-Joerg Hoexer a icrit : > > > Hi, > > > > On Mon, Jan 19, 2009 at 04:56:25PM +0100, Christoph Leser wrote: > >> > >> I noticed that the cisco end of a VPN I configured on my openBSD > >> sends a > >> DELETE message after a certain amount of idle time. > > > > Which SAs get deleted? isakmp, ipsec or both? > > > > HJ. > > > > > > > When you execute netstat -rn, do you always see the SA on your > OpenBSD, after DELETE message has been sended ? > > > I cannot tell for sure. Most DELETE messages come in after an new SA has been established, so you would expect to see the SA in netstat output, wouldn't you. I would say that I see the SA, when only IPSEC is DELETED, but no SA, when IPSEC and ISAKMP is deleted.
Re: Cisco IPSec Security Association Idle Timers and isakmpd
Le 19 janv. 09 ` 17:37, Hans-Joerg Hoexer a icrit : Hi, On Mon, Jan 19, 2009 at 04:56:25PM +0100, Christoph Leser wrote: I noticed that the cisco end of a VPN I configured on my openBSD sends a DELETE message after a certain amount of idle time. Which SAs get deleted? isakmp, ipsec or both? HJ. When you execute netstat -rn, do you always see the SA on your OpenBSD, after DELETE message has been sended ?
Re: Cisco IPSec Security Association Idle Timers and isakmpd
Hi, On Mon, Jan 19, 2009 at 04:56:25PM +0100, Christoph Leser wrote: > > I noticed that the cisco end of a VPN I configured on my openBSD sends a > DELETE message after a certain amount of idle time. Which SAs get deleted? isakmp, ipsec or both? HJ.
Cisco IPSec Security Association Idle Timers and isakmpd
Hi, I noticed that the cisco end of a VPN I configured on my openBSD sends a DELETE message after a certain amount of idle time. This feature is described in http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ftsaidle .html#wp1045897 The effect is, that the VPN no longer works. openBSD still shows the routes active ( in netstat -rnf encap ) and sends packets out to the remote site. It does not try to reestablish the phase 2 sa. Is this a bug or is it that just an incompatibility with ciscos 'idle time' feature ( which may not be 'standard' ) Regards Christoph
isakmpd does not initiate quick mode after main mode is established
I'm still struggling to keep my ipsec vpns running smoothly. Is there a reference to a more detailed description of the allowed isakmp exchanges? Watching tcpdump for some time gives me a rough impression of what is going on, but it is hard to tell what's wrong ( if anything at all ) when the exchanges proceed other than they normally do. For example I see that 'normally' my isakmpd enters into phase-2 exchange immediately after phase-1 is established. But sometimes it delays to initiate phase-2 for up to 10 minutes ater phase-1 completes, and it often fails in these case ( no response from remote ). Any hints to books or online material are welcome. Thanks and regards Christoph
lifetime-related problems with isakmpd
Hello. I am trying to use an OpenBSD 4.3 box as the terminator of a VPN to a business partner, but we're having some problems. From time to time, my counterparty sees packets with an old SPI. This coincides with me seeing packets from my internal network missing trying to hit the default route out instead of being routed through the VPN, which leads me to suspect that the VPN tunnel gets torn down at that moment. We suspect problems related to timing. We are trying to use 86400 seconds lifetime for phase 1 and 3600 seconds for phase 2. I have tried to specify this, both using /etc/ipsec.conf and ipsecctl to drive isakmpd, and /etc/isakmpd/isakmpd.conf directly, skipping ipsecctl. But I still see attribute LIFE_DURATION = 1200 in QUICK_MODE exchanges and 3600 in ID_PROT exchanges. What am I missing here? I'm at my wit's end, all suggestions welcome. I include the configurations tried, and an exerpt of the isakmpd.pcap file that shows the problem I'm seeing. The report generated by SIGUSR1 shows the same as the tcpdump: lifetimes of 3600 and 1200 secs for main- and quick-mode, respectively. If there is any other information I can provide, please tell me. I don't know what system my counterparty is using for VPN, but I can probably find out, if it's relevant. Also, please Cc me on replies, as I'm not subscribed to the list. >From ipsec.conf: ike esp from x.x.x.101/32 to y.y.y.0/24 peer z.z.z.1 \ main auth hmac-sha1 enc 3des group modp1024 life 86400 \ quick auth hmac-md5 enc 3des group none life 3600 \ psk *** >From isakmpd.conf (obviously, isakmpd.conf was not present when trying to use ipsec.conf and ipsecctl): [General] Retransmits= 5 Listen-on= x.x.x.90 Renegotiate-on-HUP= yes [Phase 1] z.z.z.1=peer-other [Phase 2] Connections=VPN-other [peer-other] Phase= 1 Address=z.z.z.1 Configuration= other-main-mode Authentication= [VPN-other] Phase= 2 ISAKMP-peer=peer-other Configuration= other-quick-mode Local-ID= my-internal-net Remote-ID= other-subnet [my-internal-net] ID-type=IPV4_ADDR_SUBNET Network=x.x.x.101 Netmask=255.255.255.255 [other-subnet] ID-type=IPV4_ADDR_SUBNET Network=y.y.y.0 Netmask=255.255.255.0 [other-main-mode] EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA,3DES-MD5 Life= LIFE_86400_SECS [other-quick-mode] EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-3DES-MD5-SUITE Life= LIFE_3600_SECS [LIFE_86400_SECS] LIFE_TYPE= SECONDS LIFE_DURATION= 86400,60:86400 [LIFE_3600_SECS] LIFE_TYPE= SECONDS LIFE_DURATION= 3600,60:86400 tcpdump of isakmpd.pcap shows (sorry about overlong lines): 23:04:45.330914 x.x.x.90.500 > z.z.z.1.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 99a52e9f544cf112->9aeaa9d500dd1f88 msgid: 6d8579bb len: 152 payload: HASH len: 24 payload: SA len: 48 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 36 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0x58981dda payload: TRANSFORM len: 24 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 1200 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_MD5 payload: NONCE len: 20 payload: ID len: 16 type: IPV4_ADDR_SUBNET = x.x.x.101/255.255.255.255 payload: ID len: 16 type: IPV4_ADDR_SUBNET = y.y.y.0/255.255.255.0 [ttl 0] (id 1, len 180) 23:04:45.543109 z.z.z.1.500 > x.x.x.90.500: [udp sum ok] isakmp v1.0 exchange QUICK_MODE cookie: 99a52e9f544cf112->9aeaa9d500dd1f88 msgid: 6d8579bb len: 164 payload: HASH len: 24 payload: SA len: 48 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 36 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 1 SPI: 0xeb872e73 payload: TRANSFORM len: 24 transform: 1 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 1200 attribute ENCAPSULATION_MODE = TUNNEL attribute AUTHENTICATION_ALGORITHM = HMAC_MD5 payload: NONCE len: 24 payload: ID len: 16 type: IPV4_ADDR_SUBNET = x.x.x.101/255.255.255.255 payload: ID len: 16 type: IPV4_ADDR_SUBNET = y.y.y.0/255.255.255.0 [ttl 0] (id 1, len 192) 23:04:45.560126 x.x.x.90.500 > z.z.z.1.500: [ud
Re: Transport Mode ipsec(4) and inet6(4) gre(4) (WAS: isakmpd + gre crashing)
As mentioned in another post to this list recently I use IPv6 to secure my tunnels when roaming to get pre-allocated IPv6 on my laptop.. Look for 'totd' in the subject and I think you'll see some useful examples. Thanks, -- Todd Fries .. t...@fries.net _ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | "..in support of free software solutions." \ 250797 (FWD) | \ \\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt Penned by Brian A. Seklecki on 20081224 16:23.55, we have: > All: > > Back in 01/2006, circa 3.8, there was a thread related to the use of > gre(4) and Transport Mode ipsec(4) in isakmpd(8) to protect v4 tunnels. > > There was a repeatable kernel panic related to gre(4) packets needing a > smaller MTU as they are encapsualted in ipsec(4) packets, before being > transmited. > > I haven't looked if we have support, but gre(4) w/ ipv6 address and > stf(4) seem to be best options out there for secure v6 tunnels. > > That is, explicitly, gre(4) inside ipv6, since we dont' have stf(4). > > I can revisit that bug in our lab, except with a slightly larger > encapsulation packet overhead :) > > I'm wondering if a tranditional ipv6 isakmp(8) ipsec tunnel (using IPv4 > enpoints?!) is a safe alternative, or what other solutions people are > cooking up on OpenBSD for tunneling IPv6 security. > > Thanks for your feedback and safe holidays to all! > > ~BAS > > On Mon, 9 Jan 2006, Jason Taylor wrote: > >> Hi Brian, >> >> I did a few more tests this evening and I think you are right about the >> MTU issue. In OpenBSD 3.8, you can set the MTU of a GRE interface. I >> set the mtu of the GRE tunnel on one end (Perspex, which runs 3.8) and >> transferred a large file. It worked wonderfully and I am now in the >> process of updating my soekri to the latest 3.8. I think what is >> happening is the GRE tunnel sets its MTU according to the MTU of the >> physical interface, in my case fxp0 and sis0 and does not take into >> account the added overhead of IPsec... >> >> >> Cheers, >> >> /Jason >> >> On Jan 9, 2006, at 4:41 PM, Brian A. Seklecki wrote: >> >>> >>>> But as soon as I start an scp from Perspex to Soekris, Perspex reboots >>>> after a few hundred kb. Unfortunately, Perspex is in a datacenter and I >>>> do not have console access to it to see what the heck is happening at that >>>> exact moment. >>> >>> I don't recall. But for the record (IPSEC inside GRE): >>> >>> If the Transport IPSEC connection is negotiated between two hosts >>> inside the GRE tunnel private subnet and the IPSEC connection goes >>> down, the data flows in cleartext. *bad* >>> >>> The opposite would be (GRE-inside-IPSEC-Transport): >>> >>> If the Transport IPSEC tunnel is built between the two hosts` public >>> interfaces and the GRE tunnel is built normally and thus encrypted, >>> things should work. Of course, we run into the crash. >>> >>> The trick was I tried it on OpenBSD/Sparc where there is >>> no-such-thing as "Flash back to the BIOS" and it turns out a Sun >>> "watchdog timer" is getting hit. Watchdog timers on i386 must cause >>> the BIOS to reset. So the problem is in-kernel and the config is >>> probably too obscure for developers to spend time on. >>> >>> My solution was to re-IP my network properly, and use IP Supernets/ >>> summarization/ subnet aggregation thus consolidating the need for so >>> many spokes on a hub-and-spoke VPN config. >>> >>> ~~BAS >>> >>>> >>>> I noticed that there were no responses to your thread, but I was wondering >>>> if you had worked out your problem or if you decided to go the ipsec >>>> encapsulated in gre. >>>> >>>> Cheers, >>>> >>>> /Jason >>>> -- >>>> Jason Taylor >>>> e: j...@jtaylor.ca >>>> m: 514-815-8204 >>>> >>>> >>> >>> l8* >>> -lava >>> >>> x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >> > > l8* > -lava (Brian A. Seklecki - Pittsburgh, PA, USA) > http://www.spiritual-machines.org/ > > "Show me a young conservative and I'll show you someone with no heart. > Show me an old liberal and I'll show you someone with no brains." > ~ Winston Churchill
Transport Mode ipsec(4) and inet6(4) gre(4) (WAS: isakmpd + gre crashing)
All: Back in 01/2006, circa 3.8, there was a thread related to the use of gre(4) and Transport Mode ipsec(4) in isakmpd(8) to protect v4 tunnels. There was a repeatable kernel panic related to gre(4) packets needing a smaller MTU as they are encapsualted in ipsec(4) packets, before being transmited. I haven't looked if we have support, but gre(4) w/ ipv6 address and stf(4) seem to be best options out there for secure v6 tunnels. That is, explicitly, gre(4) inside ipv6, since we dont' have stf(4). I can revisit that bug in our lab, except with a slightly larger encapsulation packet overhead :) I'm wondering if a tranditional ipv6 isakmp(8) ipsec tunnel (using IPv4 enpoints?!) is a safe alternative, or what other solutions people are cooking up on OpenBSD for tunneling IPv6 security. Thanks for your feedback and safe holidays to all! ~BAS On Mon, 9 Jan 2006, Jason Taylor wrote: Hi Brian, I did a few more tests this evening and I think you are right about the MTU issue. In OpenBSD 3.8, you can set the MTU of a GRE interface. I set the mtu of the GRE tunnel on one end (Perspex, which runs 3.8) and transferred a large file. It worked wonderfully and I am now in the process of updating my soekri to the latest 3.8. I think what is happening is the GRE tunnel sets its MTU according to the MTU of the physical interface, in my case fxp0 and sis0 and does not take into account the added overhead of IPsec... Cheers, /Jason On Jan 9, 2006, at 4:41 PM, Brian A. Seklecki wrote: But as soon as I start an scp from Perspex to Soekris, Perspex reboots after a few hundred kb. Unfortunately, Perspex is in a datacenter and I do not have console access to it to see what the heck is happening at that exact moment. I don't recall. But for the record (IPSEC inside GRE): If the Transport IPSEC connection is negotiated between two hosts inside the GRE tunnel private subnet and the IPSEC connection goes down, the data flows in cleartext. *bad* The opposite would be (GRE-inside-IPSEC-Transport): If the Transport IPSEC tunnel is built between the two hosts` public interfaces and the GRE tunnel is built normally and thus encrypted, things should work. Of course, we run into the crash. The trick was I tried it on OpenBSD/Sparc where there is no-such-thing as "Flash back to the BIOS" and it turns out a Sun "watchdog timer" is getting hit. Watchdog timers on i386 must cause the BIOS to reset. So the problem is in-kernel and the config is probably too obscure for developers to spend time on. My solution was to re-IP my network properly, and use IP Supernets/ summarization/ subnet aggregation thus consolidating the need for so many spokes on a hub-and-spoke VPN config. ~~BAS I noticed that there were no responses to your thread, but I was wondering if you had worked out your problem or if you decided to go the ipsec encapsulated in gre. Cheers, /Jason -- Jason Taylor e: j...@jtaylor.ca m: 514-815-8204 l8* -lava x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 l8* -lava (Brian A. Seklecki - Pittsburgh, PA, USA) http://www.spiritual-machines.org/ "Show me a young conservative and I'll show you someone with no heart. Show me an old liberal and I'll show you someone with no brains." ~ Winston Churchill
Re: ISAKMPD <-> cisco : attribute ENCAPSULATION_MODE = 61443 (unknown)
Hi, On Tue, 25.11.2008 at 12:11:42 +0100, Christoph Leser <[EMAIL PROTECTED]> wrote: > But it uses 3, if it initiates the exchange. > > if so, I would guess that is the reason for the 'NO PROPOSAL CHOSEN' messages. > Can I configure 61443 es encapsulation mode in isakmpd.conf? I'm not aware of such a facility, but you could set the OpenBSD side to be passive, and maybe the Cisco to retry more often, and/or for a longer time. That way the Cisco has more opportunity to initiate the connection and suggest his way of doing things to OpenBSD. Saying "NO PROPOSAL CHOSEN" until renegotiation timers run out means that you don't have a tunnel after that. Just my 0.2 cents... Kind regards, --Toni++
Re: ISAKMPD <-> cisco : attribute ENCAPSULATION_MODE = 61443 (unknown)
thanks for the clarification. Indeed I can see in the traces that obsd isakmpd accepts 61443 and send out it's reply with the same value. But it uses 3, if it initiates the exchange. if so, I would guess that is the reason for the 'NO PROPOSAL CHOSEN' messages. Can I configure 61443 es encapsulation mode in isakmpd.conf? Thanks again Christoph > -Urspr|ngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Im Auftrag von Stuart Henderson > Gesendet: Dienstag, 25. November 2008 11:51 > An: misc@openbsd.org > Betreff: Re: ISAKMPD <-> cisco : attribute ENCAPSULATION_MODE > = 61443 (unknown) > > > On 2008-11-25, Christoph Leser <[EMAIL PROTECTED]> wrote: > > I see the above message in the tcpdump of > /var/run/isakmpd.pcap, when > > a cisco router establishes quick mode to my openbsd. The > connect works > > ok, just wondering what this message could mean. I have only seen > > 'ENCAPSULATION MODE = TUNNEL' in this context. > > That's the encapsulation mode used by > draft-ietf-ipsec-nat-t-ike. The non-draft version uses 3 not 61443. > > (There is also 61433 used by some broken Watchguard products). > > > As connect setup fails in the opposite direction ( with NO PROPOSAL > > CHOSEN from cisco ), using the same parameters. > > You need a lot more information to work out what's happening here.
Re: ISAKMPD <-> cisco : attribute ENCAPSULATION_MODE = 61443 (unknown)
On 2008-11-25, Christoph Leser <[EMAIL PROTECTED]> wrote: > I see the above message in the tcpdump of /var/run/isakmpd.pcap, when a > cisco router establishes quick mode to my openbsd. The connect works ok, > just wondering what this message could mean. I have only seen > 'ENCAPSULATION MODE = TUNNEL' in this context. That's the encapsulation mode used by draft-ietf-ipsec-nat-t-ike. The non-draft version uses 3 not 61443. (There is also 61433 used by some broken Watchguard products). > As connect setup fails in the opposite direction ( with NO PROPOSAL > CHOSEN from cisco ), using the same parameters. You need a lot more information to work out what's happening here.
ISAKMPD <-> cisco : attribute ENCAPSULATION_MODE = 61443 (unknown)
Hi, I see the above message in the tcpdump of /var/run/isakmpd.pcap, when a cisco router establishes quick mode to my openbsd. The connect works ok, just wondering what this message could mean. I have only seen 'ENCAPSULATION MODE = TUNNEL' in this context. As connect setup fails in the opposite direction ( with NO PROPOSAL CHOSEN from cisco ), using the same parameters. regards christoph
Re: isakmpd routing woes
> -Urspr|ngliche Nachricht- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Im Auftrag von Carlos Laviola > Gesendet: Donnerstag, 6. November 2008 13:34 > An: misc@openbsd.org > Betreff: isakmpd routing woes > > > Hello, > > > > I have three /24 networks connected to each other through > multihomed OpenBSD 4.0 servers using isakmpd(8). Recently, > new point-to-point links have been installed between each of > those networks on separate interfaces, and I would like to > make it so traffic coming from/through specific (single) IPs > in each of those networks reaches other specific single IPs > in the other networks. Simply using route(8) was not enough, > so I'm wondering if anyone knows if and how this can be done > -- if this can still be done through isakmpd, great, but a > way to bypass it so that the traffic can be redirected to the > interfaces with the new links would also be enough. > > > > Thanks in advance! > > Carlos > > > > [ Please Cc replies to me if possible, as I'm not subscribed > to the list. ] > > > As far as I understand, the routes defined through isakmpd takes presidence over routes defined via "route add" command. But you can make isakmpd ignore specific ip addresses by adding bypass rules to your ipsec.conf like flow esp from a.b.c.0/24 to 10.105.60.100/32 type bypass would bypass the ipsec tunnel between a.b.c.0/24 and 10.105.60.0/24 if the target address is 10.150.60.100. Hope this helps Regards
isakmpd routing woes
Hello, I have three /24 networks connected to each other through multihomed OpenBSD 4.0 servers using isakmpd(8). Recently, new point-to-point links have been installed between each of those networks on separate interfaces, and I would like to make it so traffic coming from/through specific (single) IPs in each of those networks reaches other specific single IPs in the other networks. Simply using route(8) was not enough, so I'm wondering if anyone knows if and how this can be done -- if this can still be done through isakmpd, great, but a way to bypass it so that the traffic can be redirected to the interfaces with the new links would also be enough. Thanks in advance! Carlos [ Please Cc replies to me if possible, as I'm not subscribed to the list. ]
Re: OpenBSD + isakmpd + VPN concentrator 3060
On Fri, Sep 26 2008 at 03:19, Christoph Leser wrote: > This is interesting. We suffer from spurious connection losses since we > started with OBSD ipsec. > Do you have any details what caused your problem, and why setting > DPD-check-interval helped? The problem was the following : Tunnels were established well but, in case of internet connections problems, the vpn went down and never came up again. Once the vpn went down, the work around was simply to kill isakmpd and restart it. Not very simple when the vpn went down at 2 AM (and users complaining at 8) Analysing an idle VPN connection (we were lucky to have a test environnement), I saw that Cisco 3030 was emitting isakmp_info packets every 20 seconds. I cut the internet link, waited 1 min and then replugged the cable. tcpdump showed that my OpenBSD Box didn't loose its SAs but Cisco 3030 was trying to create new ones. At this point Isakmp daemons on both sides can't talk to each other again. As DPD was enabled on the cisco side and the techs were unable to tell me if it's the standard configuration or not, I found this way to enable DPD on the OpenBSD side. It corrected the problem as both side tryed to restart isakmp negociations after a short internet failure. Claer > > In our environnement (we manage openbsd tunnels to cisco 3030 > > which is out of our scope) we debugged a strange problem when > > the connection goes down. The tunnels won't come back after a > > small link shutdown. > > > > The problem was Cisco 3030 was doing DPD check and not the OpenBSD. > > > > If it's the case for you too, you should add these lines to > > /etc/isakmpd/isakmpd.conf : > > > > --- isakmpd.conf --- > > [General] > > DPD-check-interval= 30 > > --- isakmpd.conf ---
Re: OpenBSD + isakmpd + VPN concentrator 3060
This is interesting. We suffer from spurious connection losses since we started with OBSD ipsec. Do you have any details what caused your problem, and why setting DPD-check-interval helped? > In our environnement (we manage openbsd tunnels to cisco 3030 > which is out of our scope) we debugged a strange problem when > the connection goes down. The tunnels won't come back after a > small link shutdown. > > The problem was Cisco 3030 was doing DPD check and not the OpenBSD. > > If it's the case for you too, you should add these lines to > /etc/isakmpd/isakmpd.conf : > > --- isakmpd.conf --- > [General] > DPD-check-interval= 30 > --- isakmpd.conf ---
Re: OpenBSD + isakmpd + VPN concentrator 3060
Claer wrote: On Fri, Sep 26 2008 at 45:07, Mariusz Makowski wrote: I finally was able to setup vpn connection. Other side was configured in wrong way and sum of all my ipsec.conf look in this way: -- ipsec.conf -- other_peer = "c.c.c.c_public_ip" ike esp tunnel from a.a.a.a_net to d.d.d.d_net peer $other_peer \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group modp1024 \ psk "somekey" -- ipsec.conf -- In our environnement (we manage openbsd tunnels to cisco 3030 which is out of our scope) we debugged a strange problem when the connection goes down. The tunnels won't come back after a small link shutdown. The problem was Cisco 3030 was doing DPD check and not the OpenBSD. If it's the case for you too, you should add these lines to /etc/isakmpd/isakmpd.conf : --- isakmpd.conf --- [General] DPD-check-interval= 30 --- isakmpd.conf --- Thanks for this. But i have another problem, a.a.a.a_net is not configured on my network interface, it's a just net that must be done nat on this. I was reading a bit about doing nat on obsd and ipsec. I've tried to do so: -- conf -- ifconfig lo1 inet a.a.a.a_net route add -net d.d.d.d_net a.a.a.a_host and pf.conf: nat on lo1 from e.e.e.e_net to d.d.d.d_net -> a.a.a.a_host -- conf -- But it isn't seem to work. Packets are showing on lo1, but there are not going threw the flow/enc0 interface. The route will not work. Instead, you should use pf and route-to directive. Finally i managed to do nat in correct way, propably i was mistyped some pf.conf configuration. Both ways of adding route are working. route add -net d.d.d.d_net a.a.a.a_host and pf.conf: and pass in quick on $int_if \ route-to (lo1 a.a.a.a_host)\ from e.e.e.e_net to d.d.d.d_net But packets after nat are ignoring encap flows, and they are trying to go out by default gateway. -- tcpdump lo1 -- 09:38:20.497416 a.a.a.a_hostb > d.d.d.d_host: icmp: echo request 09:38:20.497421 a.a.a.a_hostb d.d.d.d_host: icmp: echo request -- tcpdump lo1 -- flows: flow esp in from d.d.d.d_net to a.a.a.a_net peer c.c.c.c_public_ip srcid b.b.b.b_public_ip dstid c.c.c.c_public_ip type use flow esp out from a.a.a.a_net to d.d.d.d_net peer c.c.c.c_public_ip srcid b.b.b.b_public_ip dstid c.c.c.c_public_ip type require image :): e.e.e.e_net (em0) | a.a.a.a_net (lo1) b.b.b.b_public_ip --- c.c.c.c_public_ip d.d.d.d_net Regard, Mariusz Makowski Mariusz Makowski wrote: Mariusz Makowski wrote: Hello, Firstly i want to mention that it's my begining with ipsec/isakmpd tunneling. My problem is about making connection from OpenBSD 4.3 to Cisco VPN concentrator 3060. Cisco concentrator is out of my range so i can't check log there and i only wish that configuration there is done well. Here it is my example: a.a.a.a_net b.b.b.b_public_ip --- c.c.c.c_public_ip d.d.d.d_net What i wan't to achiev is: - comunication from a.a.a.a_net to d.d.d.d_net What i know about cisco configuration: - VPN concentrator 3060 - c.c.c.c_public_ip - d.d.d.d_net - VPN Method: IPSec - Encryption: 3DES - Key exchange IKE - Pre-Shared Key: somekey - Perfect Forward Secrecy: Yes - Group 2 (1024 bits) - Hashing: SHA-1 - Diffie-Hellman: Yes - Group 2 - Time Lifetime: 28800 seconds - Encapsulation Mode: Tunnel - Negotiation Mode: Main OpenBSD: - clean instalation of 4.3 - no pf yet - em0: a.a.a.a_net - em1: b.b.b.b_public_ip After couple hours of reading stuff on internet and reading some configuration files i achivied this configuration: -- isakmpd.conf -- [General] Listen-on= b.b.b.b_public_ip [Phase 1] c.c.c.c_public_ip= CONN [Phase 2] Connections = LINK [CONN] Phase= 1 Transport= udp Address = c.c.c.c_public_ip Configuration= Default-Main-Mode Authentication = somekey [LINK] Phase= 2 ISAKMP-Peer = HP Configuration= Default-Quick-Mode Local-ID = LAN-1 Remote-ID= LAN-2 [LAN-1] ID-Type = IPV4_ADDR_SUBNET Network = a.a.a.a_net Netmask = a.a.a.a_netmask [LAN-2] ID-Type = IPV4_ADDR_SUBNET Network = d.d.d.d_net Netmask = d.d.d.d_netmask [Default-Main-Mode] DOI = IPSEC Exchange_Type= ID_PROT Transforms = 3DES-SHA [Default-Quick-Mode] DOI = IPSEC Exchange_Type= QUICK_MODE Suites = QM-ESP-3DES-SHA-SUITE [3DES-SHA] ENCRYPTION_ALGORITHM = 3DES_CBC HASH_ALGORITHM = SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_1024 Life = LIFE_3600_SECS [QM-ESP-3DES-SHA-SUITE] Protocols= QM-ESP-3DES-SHA [QM-ESP-3DES-SHA-PFS-SUITE] Protocols
Re: OpenBSD + isakmpd + VPN concentrator 3060
On Fri, Sep 26 2008 at 45:07, Mariusz Makowski wrote: > I finally was able to setup vpn connection. > Other side was configured in wrong way and sum of all my ipsec.conf look in > this way: > > -- ipsec.conf -- > other_peer = "c.c.c.c_public_ip" > > > ike esp tunnel from a.a.a.a_net to d.d.d.d_net peer $other_peer \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha1 enc 3des group modp1024 \ > psk "somekey" > -- ipsec.conf -- In our environnement (we manage openbsd tunnels to cisco 3030 which is out of our scope) we debugged a strange problem when the connection goes down. The tunnels won't come back after a small link shutdown. The problem was Cisco 3030 was doing DPD check and not the OpenBSD. If it's the case for you too, you should add these lines to /etc/isakmpd/isakmpd.conf : --- isakmpd.conf --- [General] DPD-check-interval= 30 --- isakmpd.conf --- > But i have another problem, a.a.a.a_net is not configured on my network > interface, it's a just net that must be done nat on this. > I was reading a bit about doing nat on obsd and ipsec. > I've tried to do so: > > -- conf -- > ifconfig lo1 inet a.a.a.a_net > route add -net d.d.d.d_net a.a.a.a_host and pf.conf: > nat on lo1 from e.e.e.e_net to d.d.d.d_net -> a.a.a.a_host -- conf -- > > But it isn't seem to work. Packets are showing on lo1, but there are not > going threw the flow/enc0 interface. The route will not work. Instead, you should use pf and route-to directive. > -- tcpdump lo1 -- > 09:38:20.497416 a.a.a.a_hostb > d.d.d.d_host: icmp: echo request > 09:38:20.497421 a.a.a.a_hostb d.d.d.d_host: icmp: echo request > -- tcpdump lo1 -- > > flows: > flow esp in from d.d.d.d_net to a.a.a.a_net peer c.c.c.c_public_ip srcid > b.b.b.b_public_ip dstid c.c.c.c_public_ip type use > flow esp out from a.a.a.a_net to d.d.d.d_net peer c.c.c.c_public_ip srcid > b.b.b.b_public_ip dstid c.c.c.c_public_ip type require > > image :): > e.e.e.e_net (em0) | a.a.a.a_net (lo1) b.b.b.b_public_ip --- > c.c.c.c_public_ip d.d.d.d_net > > Regard, > Mariusz Makowski > > > Mariusz Makowski wrote: >> Mariusz Makowski wrote: >>> Hello, >>> >>> Firstly i want to mention that it's my begining with ipsec/isakmpd >>> tunneling. >>> >>> My problem is about making connection from OpenBSD 4.3 to Cisco VPN >>> concentrator 3060. >>> Cisco concentrator is out of my range so i can't check log there and i >>> only wish that configuration there is done well. >>> >>> Here it is my example: >>> >>> a.a.a.a_net b.b.b.b_public_ip --- c.c.c.c_public_ip >>> d.d.d.d_net >>> >>> What i wan't to achiev is: - comunication from a.a.a.a_net to d.d.d.d_net >>> >>> What i know about cisco configuration: >>> - VPN concentrator 3060 >>> - c.c.c.c_public_ip >>> - d.d.d.d_net >>> - VPN Method: IPSec >>> - Encryption: 3DES >>> - Key exchange IKE >>> - Pre-Shared Key: somekey >>> - Perfect Forward Secrecy: Yes - Group 2 (1024 bits) - Hashing: SHA-1 >>> - Diffie-Hellman: Yes - Group 2 - Time Lifetime: 28800 seconds >>> - Encapsulation Mode: Tunnel >>> - Negotiation Mode: Main >>> >>> OpenBSD: >>> - clean instalation of 4.3 >>> - no pf yet >>> - em0: a.a.a.a_net >>> - em1: b.b.b.b_public_ip >>> >>> After couple hours of reading stuff on internet and reading some >>> configuration files i achivied this configuration: >>> >>> -- isakmpd.conf -- >>> [General] >>> Listen-on= b.b.b.b_public_ip >>> >>> [Phase 1] >>> c.c.c.c_public_ip= CONN >>> >>> [Phase 2] >>> Connections = LINK >>> >>> [CONN] >>> Phase= 1 >>> Transport= udp >>> Address = c.c.c.c_public_ip >>> Configuration= Default-Main-Mode >>> Authentication = somekey >>> >>> [LINK] >>> Phase= 2 >>> ISAKMP-Peer = HP >>> Configuration= Default-Quick-Mode >>> Local-ID = LAN-1 >>> Remote-ID= LAN-2 >>> >>> [LAN-1] >>> ID-Type = IPV4_ADDR_SUBNET >>> Network = a.a.a.a_net >>> Netmask = a.a.a.a_netmask >>> >>> [LAN-2] >>> ID-Type = IPV4_
Re: OpenBSD + isakmpd + VPN concentrator 3060
I finally was able to setup vpn connection. Other side was configured in wrong way and sum of all my ipsec.conf look in this way: -- ipsec.conf -- other_peer = "c.c.c.c_public_ip" ike esp tunnel from a.a.a.a_net to d.d.d.d_net peer $other_peer \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group modp1024 \ psk "somekey" -- ipsec.conf -- But i have another problem, a.a.a.a_net is not configured on my network interface, it's a just net that must be done nat on this. I was reading a bit about doing nat on obsd and ipsec. I've tried to do so: -- conf -- ifconfig lo1 inet a.a.a.a_net route add -net d.d.d.d_net a.a.a.a_host and pf.conf: nat on lo1 from e.e.e.e_net to d.d.d.d_net -> a.a.a.a_host -- conf -- But it isn't seem to work. Packets are showing on lo1, but there are not going threw the flow/enc0 interface. -- tcpdump lo1 -- 09:38:20.497416 a.a.a.a_hostb > d.d.d.d_host: icmp: echo request 09:38:20.497421 a.a.a.a_hostb d.d.d.d_host: icmp: echo request -- tcpdump lo1 -- flows: flow esp in from d.d.d.d_net to a.a.a.a_net peer c.c.c.c_public_ip srcid b.b.b.b_public_ip dstid c.c.c.c_public_ip type use flow esp out from a.a.a.a_net to d.d.d.d_net peer c.c.c.c_public_ip srcid b.b.b.b_public_ip dstid c.c.c.c_public_ip type require image :): e.e.e.e_net (em0) | a.a.a.a_net (lo1) b.b.b.b_public_ip --- c.c.c.c_public_ip d.d.d.d_net Regard, Mariusz Makowski Mariusz Makowski wrote: Mariusz Makowski wrote: Hello, Firstly i want to mention that it's my begining with ipsec/isakmpd tunneling. My problem is about making connection from OpenBSD 4.3 to Cisco VPN concentrator 3060. Cisco concentrator is out of my range so i can't check log there and i only wish that configuration there is done well. Here it is my example: a.a.a.a_net b.b.b.b_public_ip --- c.c.c.c_public_ip d.d.d.d_net What i wan't to achiev is: - comunication from a.a.a.a_net to d.d.d.d_net What i know about cisco configuration: - VPN concentrator 3060 - c.c.c.c_public_ip - d.d.d.d_net - VPN Method: IPSec - Encryption: 3DES - Key exchange IKE - Pre-Shared Key: somekey - Perfect Forward Secrecy: Yes - Group 2 (1024 bits) - Hashing: SHA-1 - Diffie-Hellman: Yes - Group 2 - Time Lifetime: 28800 seconds - Encapsulation Mode: Tunnel - Negotiation Mode: Main OpenBSD: - clean instalation of 4.3 - no pf yet - em0: a.a.a.a_net - em1: b.b.b.b_public_ip After couple hours of reading stuff on internet and reading some configuration files i achivied this configuration: -- isakmpd.conf -- [General] Listen-on= b.b.b.b_public_ip [Phase 1] c.c.c.c_public_ip= CONN [Phase 2] Connections = LINK [CONN] Phase= 1 Transport= udp Address = c.c.c.c_public_ip Configuration= Default-Main-Mode Authentication = somekey [LINK] Phase= 2 ISAKMP-Peer = HP Configuration= Default-Quick-Mode Local-ID = LAN-1 Remote-ID= LAN-2 [LAN-1] ID-Type = IPV4_ADDR_SUBNET Network = a.a.a.a_net Netmask = a.a.a.a_netmask [LAN-2] ID-Type = IPV4_ADDR_SUBNET Network = d.d.d.d_net Netmask = d.d.d.d_netmask [Default-Main-Mode] DOI = IPSEC Exchange_Type= ID_PROT Transforms = 3DES-SHA [Default-Quick-Mode] DOI = IPSEC Exchange_Type= QUICK_MODE Suites = QM-ESP-3DES-SHA-SUITE [3DES-SHA] ENCRYPTION_ALGORITHM = 3DES_CBC HASH_ALGORITHM = SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_1024 Life = LIFE_3600_SECS [QM-ESP-3DES-SHA-SUITE] Protocols= QM-ESP-3DES-SHA [QM-ESP-3DES-SHA-PFS-SUITE] Protocols= QM-ESP-3DES-SHA-PFS [QM-ESP-3DES-SHA] PROTOCOL_ID = IPSEC_ESP Transforms = QM-ESP-3DES-SHA-XF [QM-ESP-3DES-SHA-PFS] PROTOCOL_ID = IPSEC_ESP Transforms = QM-ESP-3DES-SHA-PFS-XF [QM-ESP-3DES-SHA-TRP] PROTOCOL_ID = IPSEC_ESP Transforms = QM-ESP-3DES-SHA-TRP-XF [QM-ESP-3DES-SHA-XF] TRANSFORM_ID = 3DES ENCAPSULATION_MODE = TUNNEL AUTHENTICATION_ALGORITHM = HMAC_SHA Life = LIFE_28800_SECS [QM-ESP-3DES-SHA-PFS-XF] TRANSFORM_ID = 3DES ENCAPSULATION_MODE = TUNNEL AUTHENTICATION_ALGORITHM = HMAC_SHA GROUP_DESCRIPTION= MODP_1024 Life = LIFE_28800_SECS [QM-ESP-3DES-SHA-TRP-XF] TRANSFORM_ID = 3DES ENCAPSULATION_MODE = TRANSPORT AUTHENTICATION_ALGORITHM = HMAC_SHA Life = LIFE_28800_SECS [LIFE_3600_SECS] LIFE_TYPE= SECONDS LIFE_DURATION= 3600,1800:7200 [LIFE_28800_SECS] LIFE_TYPE
Re: OpenBSD + isakmpd + VPN concentrator 3060
Hi, On Sun, 21.09.2008 at 16:04:11 +0200, Mariusz Makowski <[EMAIL PROTECTED]> wrote: > a.a.a.a_net b.b.b.b_public_ip --- c.c.c.c_public_ip d.d.d.d_net > > What i wan't to achiev is: - comunication from a.a.a.a_net to d.d.d.d_net > -- isakmpd.conf -- > [General] > Listen-on= b.b.b.b_public_ip > > [Phase 1] > c.c.c.c_public_ip= CONN > > [Phase 2] > Connections = LINK > > [CONN] > Phase= 1 > Transport= udp > Address = c.c.c.c_public_ip > Configuration= Default-Main-Mode > Authentication = somekey > > [LINK] > Phase= 2 > ISAKMP-Peer = HP This should imho read 'CONN' instead of 'HP'. > 164004.288475 Exch 10 exchange_finalize: 0x85b87500 > policy responder phase 2 doi 1 exchange 5 step 0 You need to specify a policy. Kind regards, --Toni++
Re: isakmpd on 4.3: pf_key_v2_write: writev failed
On Fri, Sep 19, 2008 at 12:33:36AM +0200, Lukas Ratajski wrote: > IPsec tunnel between two computers - a Soekris net5501 running > [...] > key_encrypt: bits 256: The crypto driver for the net5501 does not support 256bit AES. you have to switch to 128bit AES keys or backport revision 1.15 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/pci/glxsb.c (and replace M_ZERO with a call to bzero()). -m
Re: OpenBSD + isakmpd + VPN concentrator 3060
Mariusz Makowski wrote: Hello, Firstly i want to mention that it's my begining with ipsec/isakmpd tunneling. My problem is about making connection from OpenBSD 4.3 to Cisco VPN concentrator 3060. Cisco concentrator is out of my range so i can't check log there and i only wish that configuration there is done well. Here it is my example: a.a.a.a_net b.b.b.b_public_ip --- c.c.c.c_public_ip d.d.d.d_net What i wan't to achiev is: - comunication from a.a.a.a_net to d.d.d.d_net What i know about cisco configuration: - VPN concentrator 3060 - c.c.c.c_public_ip - d.d.d.d_net - VPN Method: IPSec - Encryption: 3DES - Key exchange IKE - Pre-Shared Key: somekey - Perfect Forward Secrecy: Yes - Group 2 (1024 bits) - Hashing: SHA-1 - Diffie-Hellman: Yes - Group 2 - Time Lifetime: 28800 seconds - Encapsulation Mode: Tunnel - Negotiation Mode: Main OpenBSD: - clean instalation of 4.3 - no pf yet - em0: a.a.a.a_net - em1: b.b.b.b_public_ip After couple hours of reading stuff on internet and reading some configuration files i achivied this configuration: -- isakmpd.conf -- [General] Listen-on= b.b.b.b_public_ip [Phase 1] c.c.c.c_public_ip= CONN [Phase 2] Connections = LINK [CONN] Phase= 1 Transport= udp Address = c.c.c.c_public_ip Configuration= Default-Main-Mode Authentication = somekey [LINK] Phase= 2 ISAKMP-Peer = HP Configuration= Default-Quick-Mode Local-ID = LAN-1 Remote-ID= LAN-2 [LAN-1] ID-Type = IPV4_ADDR_SUBNET Network = a.a.a.a_net Netmask = a.a.a.a_netmask [LAN-2] ID-Type = IPV4_ADDR_SUBNET Network = d.d.d.d_net Netmask = d.d.d.d_netmask [Default-Main-Mode] DOI = IPSEC Exchange_Type= ID_PROT Transforms = 3DES-SHA [Default-Quick-Mode] DOI = IPSEC Exchange_Type= QUICK_MODE Suites = QM-ESP-3DES-SHA-SUITE [3DES-SHA] ENCRYPTION_ALGORITHM = 3DES_CBC HASH_ALGORITHM = SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_1024 Life = LIFE_3600_SECS [QM-ESP-3DES-SHA-SUITE] Protocols= QM-ESP-3DES-SHA [QM-ESP-3DES-SHA-PFS-SUITE] Protocols= QM-ESP-3DES-SHA-PFS [QM-ESP-3DES-SHA] PROTOCOL_ID = IPSEC_ESP Transforms = QM-ESP-3DES-SHA-XF [QM-ESP-3DES-SHA-PFS] PROTOCOL_ID = IPSEC_ESP Transforms = QM-ESP-3DES-SHA-PFS-XF [QM-ESP-3DES-SHA-TRP] PROTOCOL_ID = IPSEC_ESP Transforms = QM-ESP-3DES-SHA-TRP-XF [QM-ESP-3DES-SHA-XF] TRANSFORM_ID = 3DES ENCAPSULATION_MODE = TUNNEL AUTHENTICATION_ALGORITHM = HMAC_SHA Life = LIFE_28800_SECS [QM-ESP-3DES-SHA-PFS-XF] TRANSFORM_ID = 3DES ENCAPSULATION_MODE = TUNNEL AUTHENTICATION_ALGORITHM = HMAC_SHA GROUP_DESCRIPTION= MODP_1024 Life = LIFE_28800_SECS [QM-ESP-3DES-SHA-TRP-XF] TRANSFORM_ID = 3DES ENCAPSULATION_MODE = TRANSPORT AUTHENTICATION_ALGORITHM = HMAC_SHA Life = LIFE_28800_SECS [LIFE_3600_SECS] LIFE_TYPE= SECONDS LIFE_DURATION= 3600,1800:7200 [LIFE_28800_SECS] LIFE_TYPE = SECONDS LIFE_DURATION = 28800 -- isakmpd.conf -- After this i am able to get threw first phase. But i am unable to get the second. Here it is my debug: -- isakmpd -d -DA=10 -- 164003.690124 Default log_debug_cmd: log level changed from 0 to 10 for class 0 [priv] 164003.690315 Default log_debug_cmd: log level changed from 0 to 10 for class 1 [priv] 164003.690379 Default log_debug_cmd: log level changed from 0 to 10 for class 2 [priv] 164003.690437 Default log_debug_cmd: log level changed from 0 to 10 for class 3 [priv] 164003.690493 Default log_debug_cmd: log level changed from 0 to 10 for class 4 [priv] 164003.690554 Default log_debug_cmd: log level changed from 0 to 10 for class 5 [priv] 164003.690610 Default log_debug_cmd: log level changed from 0 to 10 for class 6 [priv] 164003.690670 Default log_debug_cmd: log level changed from 0 to 10 for class 7 [priv] 164003.690726 Default log_debug_cmd: log level changed from 0 to 10 for class 8 [priv] 164003.690787 Default log_debug_cmd: log level changed from 0 to 10 for class 9 [priv] 164003.690844 Default log_debug_cmd: log level changed from 0 to 10 for class 10 [priv] 164003.691747 Misc 10 monitor_init: privileges dropped for child process 164003.839514 Timr 10 timer_add_event: event connection_checker(0x8848bdf0) added last, expiration in 0s 164003.841346 Timr 10 timer_handle_expirations: event connection_checker(0x8848bdf0) 164003.841426 Timr 10 timer_add_event: event connection_che
OpenBSD + isakmpd + VPN concentrator 3060
Hello, Firstly i want to mention that it's my begining with ipsec/isakmpd tunneling. My problem is about making connection from OpenBSD 4.3 to Cisco VPN concentrator 3060. Cisco concentrator is out of my range so i can't check log there and i only wish that configuration there is done well. Here it is my example: a.a.a.a_net b.b.b.b_public_ip --- c.c.c.c_public_ip d.d.d.d_net What i wan't to achiev is: - comunication from a.a.a.a_net to d.d.d.d_net What i know about cisco configuration: - VPN concentrator 3060 - c.c.c.c_public_ip - d.d.d.d_net - VPN Method: IPSec - Encryption: 3DES - Key exchange IKE - Pre-Shared Key: somekey - Perfect Forward Secrecy: Yes - Group 2 (1024 bits) - Hashing: SHA-1 - Diffie-Hellman: Yes - Group 2 - Time Lifetime: 28800 seconds - Encapsulation Mode: Tunnel - Negotiation Mode: Main OpenBSD: - clean instalation of 4.3 - no pf yet - em0: a.a.a.a_net - em1: b.b.b.b_public_ip After couple hours of reading stuff on internet and reading some configuration files i achivied this configuration: -- isakmpd.conf -- [General] Listen-on= b.b.b.b_public_ip [Phase 1] c.c.c.c_public_ip= CONN [Phase 2] Connections = LINK [CONN] Phase= 1 Transport= udp Address = c.c.c.c_public_ip Configuration= Default-Main-Mode Authentication = somekey [LINK] Phase= 2 ISAKMP-Peer = HP Configuration= Default-Quick-Mode Local-ID = LAN-1 Remote-ID= LAN-2 [LAN-1] ID-Type = IPV4_ADDR_SUBNET Network = a.a.a.a_net Netmask = a.a.a.a_netmask [LAN-2] ID-Type = IPV4_ADDR_SUBNET Network = d.d.d.d_net Netmask = d.d.d.d_netmask [Default-Main-Mode] DOI = IPSEC Exchange_Type= ID_PROT Transforms = 3DES-SHA [Default-Quick-Mode] DOI = IPSEC Exchange_Type= QUICK_MODE Suites = QM-ESP-3DES-SHA-SUITE [3DES-SHA] ENCRYPTION_ALGORITHM = 3DES_CBC HASH_ALGORITHM = SHA AUTHENTICATION_METHOD= PRE_SHARED GROUP_DESCRIPTION= MODP_1024 Life = LIFE_3600_SECS [QM-ESP-3DES-SHA-SUITE] Protocols= QM-ESP-3DES-SHA [QM-ESP-3DES-SHA-PFS-SUITE] Protocols= QM-ESP-3DES-SHA-PFS [QM-ESP-3DES-SHA] PROTOCOL_ID = IPSEC_ESP Transforms = QM-ESP-3DES-SHA-XF [QM-ESP-3DES-SHA-PFS] PROTOCOL_ID = IPSEC_ESP Transforms = QM-ESP-3DES-SHA-PFS-XF [QM-ESP-3DES-SHA-TRP] PROTOCOL_ID = IPSEC_ESP Transforms = QM-ESP-3DES-SHA-TRP-XF [QM-ESP-3DES-SHA-XF] TRANSFORM_ID = 3DES ENCAPSULATION_MODE = TUNNEL AUTHENTICATION_ALGORITHM = HMAC_SHA Life = LIFE_28800_SECS [QM-ESP-3DES-SHA-PFS-XF] TRANSFORM_ID = 3DES ENCAPSULATION_MODE = TUNNEL AUTHENTICATION_ALGORITHM = HMAC_SHA GROUP_DESCRIPTION= MODP_1024 Life = LIFE_28800_SECS [QM-ESP-3DES-SHA-TRP-XF] TRANSFORM_ID = 3DES ENCAPSULATION_MODE = TRANSPORT AUTHENTICATION_ALGORITHM = HMAC_SHA Life = LIFE_28800_SECS [LIFE_3600_SECS] LIFE_TYPE= SECONDS LIFE_DURATION= 3600,1800:7200 [LIFE_28800_SECS] LIFE_TYPE = SECONDS LIFE_DURATION = 28800 -- isakmpd.conf -- After this i am able to get threw first phase. But i am unable to get the second. Here it is my debug: -- isakmpd -d -DA=10 -- 164003.690124 Default log_debug_cmd: log level changed from 0 to 10 for class 0 [priv] 164003.690315 Default log_debug_cmd: log level changed from 0 to 10 for class 1 [priv] 164003.690379 Default log_debug_cmd: log level changed from 0 to 10 for class 2 [priv] 164003.690437 Default log_debug_cmd: log level changed from 0 to 10 for class 3 [priv] 164003.690493 Default log_debug_cmd: log level changed from 0 to 10 for class 4 [priv] 164003.690554 Default log_debug_cmd: log level changed from 0 to 10 for class 5 [priv] 164003.690610 Default log_debug_cmd: log level changed from 0 to 10 for class 6 [priv] 164003.690670 Default log_debug_cmd: log level changed from 0 to 10 for class 7 [priv] 164003.690726 Default log_debug_cmd: log level changed from 0 to 10 for class 8 [priv] 164003.690787 Default log_debug_cmd: log level changed from 0 to 10 for class 9 [priv] 164003.690844 Default log_debug_cmd: log level changed from 0 to 10 for class 10 [priv] 164003.691747 Misc 10 monitor_init: privileges dropped for child process 164003.839514 Timr 10 timer_add_event: event connection_checker(0x8848bdf0) added last, expiration in 0s 164003.841346 Timr 10 timer_handle_expirations: event connection_checker(0x8848bdf0) 164003.841426 Timr 10 timer_add_event: event connection_checker(0x8848bdf0) added last
isakmpd question (isakmpd.conf -> ipsec.conf)
Hi,
in my VPN setup, I want to authenticate sites to each other using X.509
certificates. In my "classic" isakmpd.conf, I have this:
[IPSEC-mobile-clients]
Phase= 2
Configuration= mobile-quick-mode
Local-ID= default-route
Remote-ID= dummy-remote
[default-route]
ID-type=IPV4_ADDR_SUBNET
Network=0.0.0.0
Netmask=0.0.0.0
[dummy-remote]
ID-type=IPV4_ADDR
Address=0.0.0.0
In my isakmpd.policy, I delegate to the individual certs. This works ok
for my few dozen clients, but they have to have all the same
configuration (ie, the least common denominator "wins").
Since people recommend using ipsec.conf, I wanted to transform this
setup to using ipsec.conf. In my ipsec.conf, I have:
myip=1.2.3.4
ike passive esp tunnel from $myip to any \
main auth hmac-sha1 enc aes-256 group modp1536 \
quick auth hmac-sha1 enc aes-256 group modp1536 \
srcid $myip dstid [EMAIL PROTECTED]
This keeps isakmpd looking in
/etc/isakmpd/pubkeys//ufqdn/[EMAIL PROTECTED] for a public key
that I presumably have to create using keynote (right)?
In any case, I have the certificates in place that I want to use
instead, but they don't get touched, ever.
I'm testing this with 4.3 and a snapshot from August 25th on one
("gateway") side, and Linux+isakmpd on the other side, configured as a
road warrior, but "in production", this would also have to work with
existing counterparts of all kinds, most of them Windows boxen.
Any help is very much appreciated!
Kind regards,
--Toni++
isakmpd on 4.3: pf_key_v2_write: writev failed
Hello everyone, I am experiencing a problem here which - despite of deep analysis, RTFMing and trying to understand some portions of isakmpd code - seems impossible to solve for me. I am trying to establish a simple IPsec tunnel between two computers - a Soekris net5501 running OpenBSD 4.3 and a MacBook running OS X 10.4.11 with IPsecuritas. I already learned a huge amount about IPsec and its basics thanks to the excellent documentation, but it seems this is really beyond my comprehension (as of now, at least) - thus I kindly ask for your help. First off, the OS X side worked and still works perfectly in other configurations (establishing tunnels to a slightly different OpenBSD 4.3 machine). I'll try to describe what happens: On the IPsecuritas side the tunnel is established perfectly. The connection manager shows a green LED. If I try to ping the OpenBSD machine, ESP packets are sent over the wire/air (tried both) and arrive at the interface of the OpenBSD machine. So far so good. On the OpenBSD machine, things look like this (isakmpd debuglevel ALL is set to 60). Phases 1 and 2 seem to be established, but when it comes to pass the information about the established tunnel to the kernel, an error occurs: pf_key_v2_write: writev (8, 0x88a3f680, 16) failed: Invalid argument "ipsecctl -sa" shows neither flows, nor SAD entries. "ipsecctl -m" during tunnel establishment shows nothing. Although, when I order IPsecuritas to tear down the tunnel, it yields: sadb_delflow: satype esp vers 2 len 16 seq 9 pid 16638 src_mask: 0.0.0.0 dst_mask: 255.255.255.255 protocol: proto 0 flags 0 flow_type: type require direction out src_flow: 0.0.0.0 dst_flow: 10.2.0.4 sadb_delflow: satype esp vers 2 len 2 seq 9 pid 16638 errno 3: No such process sadb_delete: satype esp vers 2 len 10 seq 10 pid 16638 sa: spi 0x091f6215 auth none enc none state larval replay 0 flags 0 address_src: 10.2.0.1 address_dst: 10.2.0.4 sadb_delete: satype esp vers 2 len 2 seq 10 pid 16638 errno 3: No such process sadb_delflow: satype esp vers 2 len 16 seq 11 pid 16638 src_mask: 255.255.255.255 dst_mask: 0.0.0.0 protocol: proto 0 flags 0 flow_type: type use direction in src_flow: 10.2.0.4 dst_flow: 0.0.0.0 sadb_delflow: satype esp vers 2 len 2 seq 11 pid 16638 errno 3: No such process sadb_delete: satype esp vers 2 len 10 seq 12 pid 16638 sa: spi 0x06e0f06e auth none enc none state larval replay 0 flags 0 address_src: 10.2.0.4 address_dst: 10.2.0.1 sadb_delete: satype esp vers 2 len 2 seq 12 pid 16638 errno 3: No such process sadb_getspi: satype esp vers 2 len 10 seq 13 pid 16638 address_src: 10.2.0.4 address_dst: 10.2.0.1 spirange: min 0x0100 max 0x sadb_getspi: satype esp vers 2 len 10 seq 13 pid 16638 sa: spi 0x9f37b12e auth none enc none state mature replay 0 flags 0 address_src: 10.2.0.4 address_dst: 10.2.0.1 sadb_add: satype esp vers 2 len 49 seq 14 pid 16638 sa: spi 0x075f3e1e auth hmac-sha1 enc aes state mature replay 16 flags 4 lifetime_hard: alloc 0 bytes 0 add 1800 first 0 lifetime_soft: alloc 0 bytes 0 add 1620 first 0 address_src: 10.2.0.1 address_dst: 10.2.0.4 key_auth: bits 160: b3dd92e5008ba542a1444ce948b1bbbe644d4c8f key_encrypt: bits 256: c5fc5aae3c2d3be536b2b688192fd4340d06930b6647cc0cf60a7c5a018b305d identity_src: type prefix id 0: 10.2.0.1/32 identity_dst: type prefix id 0: 10.2.0.4/32 src_mask: 0.0.0.0 dst_mask: 255.255.255.255 protocol: proto 0 flags 0 flow_type: type unknown direction out src_flow: 0.0.0.0 dst_flow: 10.2.0.4 "route show" (encap section) shows nothing "route monitor" during tunnel establishment also yields no information, it seems that nothing is getting touched at all. I've googled already, and found only references to an old bug in 2.x times which yielded the same error. No occurrence of this error in relation to further OpenBSD releases. My version is a fresh over-the- net installation of 4.3. On a different box (similar to the Soekris) I experienced no such problems. Kernel and userland are perfectly synchronized, no tweaking involved. The error occurs both when using X.509 certificates and pre-shared keys (PSK in this particular case below). Sep 19 00:22:07 nimrod isakmpd[16638]: virtual_clone: old 0x81462680 new 0x81462c80 (main is 0x81462cc0) Sep 19 00:22:07 nimrod isakmpd[16638]: message_parse_payloads: offset 28 payload SA Sep 19 00:22:07 nimrod isakmpd[16638]: message_parse_payloads: offset 84 payload VENDOR Sep 19 00:22:07 nimrod isakmpd[16638]: message_parse_payloads:
Re: isakmpd
Hi, On Sat, 23.08.2008 at 13:30:28 +0200, Daniel Rapp <[EMAIL PROTECTED]> wrote: > I have a openbsd (4.2) firewall with a tunnel config in isakmpd.conf and i > want to add a roadwarrior tunnel to.. this should work roughly like this: [Phase 1] 1.2.3.4=Your-Main-Connection # that you have already Default=Mobile-User [Phase 2] Connections=main-connection Passive-Connections=mobile-user [Your-Main-Connection] ... # just keep the whole setup [Mobile-User] Phase= 1 ID= local-id ... [local-id] ID-type=your.id.type # I like "IPV4_ADDR" Address=1.2.3.4 # tag and value depend # on ID-type, obviously [mobile-user] Phase= 2 Local-id= default-route remote-id dummy-machine [default-route] ID-type=IPV4_ADDR_SUBNET Network=0.0.0.0 Netmask=0.0.0.0 [dummy-machine] ID-type=IPV4_ADDR Address=0.0.0.0 This is about it. I also like using IKE config mode, which adds Flags= ikecfg to the [Mobile-User] section, plus an appropriate client entry. I like UFQDNs for that, so I have something like [ufqdn/[EMAIL PROTECTED] Address=10.1.2.3 Netmask=255.255.255.255 Nameserver= 10.4.5.6 The whole thing works with an isakpd.policy file that grant access to the [EMAIL PROTECTED] id, and certificates that carry these IDs. Btw, don't use self-signed certificates - they don't buy you anything. You can add connections like this in an additive manner to isakmpd.conf, but there are some problems when networking gets more complicated. The recommended way to set up VPNs appears to be using ipsec.conf these days, so you should probably read about that first, although I'm a bit stumped as to why one wants to disable policy checking, as per ipsec.conf(5): "Note that it will probably need to be run with at least the -K option, to avoid keynote(4) policy checking.". But then, I may simply not have understood this paragraph myself, yet. Kind regards, --Toni++
Re: isakmpd
On Sat, 2008-08-23 at 13:30 +0200, Daniel Rapp wrote: > Hi, i am looking for example configs on isakmpd where there is more then one > tunnel.. > > I have a openbsd (4.2) firewall with a tunnel config in isakmpd.conf and i > want to add a roadwarrior tunnel to.. There should be a wiki somewhere with lots of known-good-working isakmpd(8) / isakmpd.conf(5) examples. ~BAS > I think i have seen some sample config before but i cant seem to find any > now.. > > Any help would be appreciated.. > > /Daniel > -- Brian A. Seklecki <[EMAIL PROTECTED]> Collaborative Fusion, Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Re: isakmpd "from XX to any"; possible to offer choice of algorithm?
jared r r spiegel wrote: On Fri, Aug 29, 2008 at 11:02:18PM +, Stuart Henderson wrote: Now someone would like to add a device which (like some other devices connecting to this machine) is not on a fixed address so it needs to use the "to any" rule. Though it supports AES in phase 2, only DES or 3DES are permitted in phase 1 (which of course is already set to AES on other devices). just checked isakmpd.conf(5), it says you can have a list of proposed transforms (instead of just one). but i do recall for certain that i NEVER got that to work. any list of anything, i never got to work; transform lists, the thing where you're supposed to be able to specify a range of time/byte durations, etcetc :/ I used the following for phase 1 in my isakmpd.conf: [General] ... Default-phase-1-ID = My-Phase-1-Id [My-Phase-1-Id] Id-Type = FQDN Name= router.ant.uni-bremen.de [Phase 1] Default = Peer-Default [Peer-Default] Phase = 1 Transport = udp Configuration = Default-id-prot [Default-id-prot] DOI = IPSEC EXCHANGE_TYPE = ID_PROT Transforms = 3DES-SHA-RSA_SIG,AES-SHA-RSA_SIG This worked w/o problems. HTH, Heinrich -- Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-4664 Fax :-3341
Re: isakmpd "from XX to any"; possible to offer choice of algorithm?
On Fri, Aug 29, 2008 at 11:02:18PM +, Stuart Henderson wrote: > Now someone would like to add a device which (like some other devices > connecting to this machine) is not on a fixed address so it needs to > use the "to any" rule. Though it supports AES in phase 2, only DES or > 3DES are permitted in phase 1 (which of course is already set to AES > on other devices). just checked isakmpd.conf(5), it says you can have a list of proposed transforms (instead of just one). but i do recall for certain that i NEVER got that to work. any list of anything, i never got to work; transform lists, the thing where you're supposed to be able to specify a range of time/byte durations, etcetc :/ -- jared
Re: isakmpd "from XX to any"; possible to offer choice of algorithm?
On Fri, Aug 29, 2008 at 11:02:18PM +, Stuart Henderson wrote: > Does anyone know of a way, either using ipsec.conf or isakmpd.conf, > to permit use of _either_ AES _or_ 3DES in phase 1? Or do I need to go > to all the other endpoints and reconfigure them to a common algorithm > (i.e. 3DES)? when i was doing certs, i was identifying hosts based on USER_FQDN, iirc. i believe this works in phaseI ID. if so, perhaps it is possible to either omit main mode from ipsec.conf, or just do this particular client entirely in isakmpd.conf. but anyway, within the ISAKMP-peer section for that one host, iirc you can define what its phase 1 config is, and in there you can bring the 3DES into play. if the cert the peer has is only FQDN, and its the same FQDN as other peers have, then i think you're pretty much screwed wrt being able to one-off this guy real super easy, but USER_FQDN can provide this granularity. i *do* remember having a lot of trouble with the Default-phase-1-ID for some reason somewhere... dunno if it'd be relevant.. it's been a while. -- jared
isakmpd "from XX to any"; possible to offer choice of algorithm?
I've got a number of VPN clients using X.509 certs to access a
central site configured by ipsec.conf like this.
ike passive esp \
from {$SOMENET, 192.168.40.0/21} to any \
main auth hmac-sha1 enc aes group grp2 \
quick auth hmac-sha1 enc aes group grp2 \
tag ipsec-$id
Now someone would like to add a device which (like some other devices
connecting to this machine) is not on a fixed address so it needs to
use the "to any" rule. Though it supports AES in phase 2, only DES or
3DES are permitted in phase 1 (which of course is already set to AES
on other devices).
Does anyone know of a way, either using ipsec.conf or isakmpd.conf,
to permit use of _either_ AES _or_ 3DES in phase 1? Or do I need to go
to all the other endpoints and reconfigure them to a common algorithm
(i.e. 3DES)?
(it's not especially useful information, but central site is running
May 2 2008 code, clients are mixed cheap CPE routers - draytek/zyxel
etc. hence the problem. :)
Re: Any Ideas ? isakmpd loggs: exchange_setup_p1: unknown exchange type QUICK_MODE
Solution: Due to a kind of Typo in isakmpd.conf the local keying deamon tried to use the phase2 definitions for negociating an incoming p1 request. Thanks to anyone who put some thoughts on the question. Kinde regards, Stefan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Sczekalla Sent: Friday, August 22, 2008 5:40 PM To: misc@openbsd.org Subject: Any Ideas ? isakmpd loggs: exchange_setup_p1: unknown exchange type QUICK_MODE ... and send no answer back to xxx.yyy.zzz.uuu My Host is an OpenBSD 3.8, the other - remote ( xxx.yyy.zzz.uuu ) is a securepoint using strongswan. 17:11:22.476524 xxx.yyy.zzz.uuu.500 > aaa.bbb.ccc.ddd.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 26e5b1720844a0fa-> msgid: len: 212 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 0 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = MD5 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 payload: VENDOR len: 20 payload: VENDOR len: 12 payload: VENDOR len: 20 (supports DPD v1.0) payload: VENDOR len: 20 (supports NAT-T, RFC 3947) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02\n) payload: VENDOR len: 20 (supports v1 NAT-T, draft-ietf-ipsec-nat-t-ike-00) [ttl 0] (id 1, len 240) Any Ideas why this packet ist not answered by my Openbsd-BOX ? I double-checked my configs twice and have two additional well running tunnels. Kind regards, Stefan
isakmpd
Hi, i am looking for example configs on isakmpd where there is more then one tunnel.. I have a openbsd (4.2) firewall with a tunnel config in isakmpd.conf and i want to add a roadwarrior tunnel to.. I think i have seen some sample config before but i cant seem to find any now.. Any help would be appreciated.. /Daniel
Any Ideas ? isakmpd loggs: exchange_setup_p1: unknown exchange type QUICK_MODE
... and send no answer back to xxx.yyy.zzz.uuu My Host is an OpenBSD 3.8, the other - remote ( xxx.yyy.zzz.uuu ) is a securepoint using strongswan. 17:11:22.476524 xxx.yyy.zzz.uuu.500 > aaa.bbb.ccc.ddd.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 26e5b1720844a0fa-> msgid: len: 212 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 0 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = MD5 attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 payload: VENDOR len: 20 payload: VENDOR len: 12 payload: VENDOR len: 20 (supports DPD v1.0) payload: VENDOR len: 20 (supports NAT-T, RFC 3947) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02\n) payload: VENDOR len: 20 (supports v1 NAT-T, draft-ietf-ipsec-nat-t-ike-00) [ttl 0] (id 1, len 240) Any Ideas why this packet ist not answered by my Openbsd-BOX ? I double-checked my configs twice and have two additional well running tunnels. Kind regards, Stefan
isakmpd & multiple CAs within one file?
Hi folks, Tinyca allows to export a chain of CA certificates within one file, but it took me quite some time to recognize that isakmpd can't handle this. Or can it? Regards Harri
isakmpd times out on rolled-over client certificate
Hi all I have an OBSD4.3 VPN gateway that authenticates users based on their certificate and an isakmpd.policy, which works just fine. Now a user had to renew his certificate: same CA, same CA certificate, same Subject DN, same EVERYTHING. I'd have expected that he'd just need to close the VPN tunnel, install the new certificate, authenticate again and that'd be it. But not so. isakmpd logs and sends back: isakmpd[26674]: dropped message from aaa.bbb.ccc.ddd port 500 due to notification type INVALID_ID_INFORMATION On one machine, I had to restart isakmpd to get it to accept the new certificate, on the other one I can't because I connect to it through the same VPN ... Obviously some part of the certificate gets cached somewhere in memory (isakmpd? kernel?). Tearing down old SAs for the user's IP (echo "t aaa.bbb.ccc.ddd" > /var/run/isakmpd.fifo) doen't help. Is there any way (apart from bouncing isakmpd) to force (isakmpd? kernel?) to forget the old and use the new certificate? On one occasion I had to reboot a box ... which I consider a rather drastic measure for the occasion of a user certificate renewal. tx /markus
Re: isakmpd -- NCP IPsec client: peer proposed invalid phase 2 IDs
On 2008-06-30, Harald Dunkel <[EMAIL PROTECTED]> wrote: > Mitja Mu>enih wrote: >> >> It is not a problem within isakmpd, it will accept IPV4_ADDR_SUBNET of size >> /32. >> >> As I already explained to you in a private mail, ipsecctl will export both >> 192.168.1.249 and 192.168.1.249/32 into IPV4_ADDR=192.168.1.249 while your >> windows client is sending IPV4_ADDR_SUBNET for 192.168.1.249/32, and this >> will not match. >> > > Does NCP client violate some RFC by sending IPV4_ADDR_SUBNET for > 192.168.1.249/32 ? Not that I could identify. In fact, for software implementing RFC4322, "Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32."
Re: isakmpd -- NCP IPsec client: peer proposed invalid phase 2 IDs
PS: If I don't define any remote networks in NCP client, then it tries to send all ip traffic via esp to the OpenBSD gateway, but isakmpd whoes: responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id c0a801f9: 192.168.1.249, responder id /: 0.0.0.0/0.0.0.0 The proposal packet contains : payload: ID len: 12 type: IPV4_ADDR = 192.168.1.249 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 0.0.0.0/0.0.0.0 [ttl 0] (id 1, len 872) : Regards Harri
Re: isakmpd -- NCP IPsec client: peer proposed invalid phase 2 IDs
Mitja Mu>enih wrote: It is not a problem within isakmpd, it will accept IPV4_ADDR_SUBNET of size /32. As I already explained to you in a private mail, ipsecctl will export both 192.168.1.249 and 192.168.1.249/32 into IPV4_ADDR=192.168.1.249 while your windows client is sending IPV4_ADDR_SUBNET for 192.168.1.249/32, and this will not match. Does NCP client violate some RFC by sending IPV4_ADDR_SUBNET for 192.168.1.249/32 ? I have looked into changing this ipsecctl's behaviour but I can't find a clean way to do it. Thats fine. AFAICS most IPsec installations will work on "real" subnets, so probably it is not so important. I stumbled over this just in an evaluation environment. Many thanx to all Harri
Re: isakmpd -- NCP IPsec client: peer proposed invalid phase 2 IDs
On 2008-06-30, Mitja Mu>enih <[EMAIL PROTECTED]> wrote: > It is not a problem within isakmpd, it will accept IPV4_ADDR_SUBNET of size > /32. It would make more sense for isakmpd to treat IPV4_ADDR_SUBNET /32 and IPV4_ADDR as equivalent, otherwise I think you're unable to use 0.0.0.0 to accept dynamic IP peers that do this.
Re: isakmpd -- NCP IPsec client: peer proposed invalid phase 2 IDs
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Harald Dunkel > Sent: Monday, June 30, 2008 9:17 AM > To: [EMAIL PROTECTED] > Cc: Misc OpenBSD > Subject: Re: isakmpd -- NCP IPsec client: peer proposed > invalid phase 2 IDs > > Hi Prabhu, > > I do get a connection for > > ike passive esp from 192.168.5.0/31 to 192.168.1.249 > > but not for > > ike passive esp from 192.168.5.1 to 192.168.1.249 > > (192.168.1.249 is the remote Windows laptop running NCP IPsec client.) > > So I doubt that this is a problem of aes vs 3des. AFAICS the problem > is that isakmpd doesn't accept the proposal packet with > > : > payload: ID len: 12 type: IPV4_ADDR = 192.168.1.249 > payload: ID len: 16 type: IPV4_ADDR_SUBNET = > 192.168.5.1/255.255.255.255 [ttl 0] (id 1, len 248) > : > > If I setup an IPsec tunnel between 2 OpenBSD hosts, then the > proposal packet says > > : > payload: ID len: 12 type: IPV4_ADDR = 192.168.5.3 > payload: ID len: 12 type: IPV4_ADDR = 192.168.5.1 [ttl > 0] (id 1, len 312) > : > > which seems to be fine for isakmpd. It is not a problem within isakmpd, it will accept IPV4_ADDR_SUBNET of size /32. As I already explained to you in a private mail, ipsecctl will export both 192.168.1.249 and 192.168.1.249/32 into IPV4_ADDR=192.168.1.249 while your windows client is sending IPV4_ADDR_SUBNET for 192.168.1.249/32, and this will not match. I have looked into changing this ipsecctl's behaviour but I can't find a clean way to do it. > > The questions are: > > Does NCP's IPsec client violate some RFC? > Can isakmpd adjusted to accept "IPV4_ADDR_SUBNET" in the proposal > packet, if this is fine with the RFCs? Since it's not an isakmpd's problem but a problem in ipsecctl parsing the config for isakmpd, you can always use the old-style isakmpd.conf config. Or see if your windows client can define a different destination type. > > > Regards > > Harri Mitja
Re: isakmpd -- NCP IPsec client: peer proposed invalid phase 2 IDs
Hi Prabhu, I do get a connection for ike passive esp from 192.168.5.0/31 to 192.168.1.249 but not for ike passive esp from 192.168.5.1 to 192.168.1.249 (192.168.1.249 is the remote Windows laptop running NCP IPsec client.) So I doubt that this is a problem of aes vs 3des. AFAICS the problem is that isakmpd doesn't accept the proposal packet with : payload: ID len: 12 type: IPV4_ADDR = 192.168.1.249 payload: ID len: 16 type: IPV4_ADDR_SUBNET = 192.168.5.1/255.255.255.255 [ttl 0] (id 1, len 248) : If I setup an IPsec tunnel between 2 OpenBSD hosts, then the proposal packet says : payload: ID len: 12 type: IPV4_ADDR = 192.168.5.3 payload: ID len: 12 type: IPV4_ADDR = 192.168.5.1 [ttl 0] (id 1, len 312) : which seems to be fine for isakmpd. The questions are: Does NCP's IPsec client violate some RFC? Can isakmpd adjusted to accept "IPV4_ADDR_SUBNET" in the proposal packet, if this is fine with the RFCs? Regards Harri
