lrint(INT_MAX) != INT_MAX

[hans]

This is what happens on my relatively current
OpenBSD bbb.stare.cz 6.5 GENERIC#0 armv7(BeagleBone Black)
OpenBSD ppc.stare.cz 6.5 GENERIC#0 macppc   (an old MacMini)

#include 
#include 
#include 

int
main()
{
long l;
double d = INT_MAX;

l = lrint(d);
printf("%f is %ld\n", d, l);

l = lround(d);
printf("%f is %ld\n", d, l);

return 0;
}

2147483647.00 is -1
2147483647.00 is -1

That doesn't seem right: isn't INT_MAX representable as a long,
even on these machines where sizeof(int) == sizeof(long)?
If so, shouldn't lrint(INT_MAX) == INT_MAX = lround(INT_MAX)?

On i386 (an ALIX), I see

2147483647.00 is 2147483647
2147483647.00 is -1

so lrint() returns the expected value but lround() does not.

On the amd64s I have, I see the expected:
2147483647.00 is 2147483647
2147483647.00 is 2147483647

Is this a bug or am I missing something obvious?

Jan

Re: malloc.conf on BeagleBone Black

[hans]

On May 10 18:45:49, h...@stare.cz wrote:
> > > > >   malloc() warning: unknown char in MALLOC_OPTIONS
> > 
> > if it's only some programs, then it's because those are older programs.
> 
> Yes they are. I will get back after they recompile. Thanks.

Indeed, after recompiling the ports (it was only port binaries
that complained), the warning disappeared.

Thank you

Jan

Re: malloc.conf on BeagleBone Black

[hans]

On May 10 12:29:16, t...@tedunangst.com wrote:
> hans wrote:
> > On May 10 18:02:12, o...@drijf.net wrote:
> > > hans  schreef op 10 mei 2016 17:12:23 CEST:
> > > >I started using the wonderfull malloc.conf,
> > > >setting it to CFGJPRSU. This works on amd64 and macppc and i386,
> > > >but on a freshly upgraded current/armv7 (a BeagleBone Black),
> > > >some programs report
> > > >
> > > > malloc() warning: unknown char in MALLOC_OPTIONS
> > > >
> > > >Each of the flags is documented in the malloc.conf(5) manpage.
> > > >Is there something specific about this on the BBB?
> > > >
> > > > Jan
> > > 
> > > 
> > > Well, that's a lot of flags, things will get slow Some are redundant 
> > > (included in S), some are already on by default. I would advise just to 
> > > use S and be done with it.
> > > 
> > > Why you do not get the expected results on armv7 I do not know.
> > > My guesses are: older version of libc or typo
> > 
> > This is current/armv7 (May 8).
> > I have double hecked the string.
> > 
> > > Eliminate flags until you find the offending one.
> > 
> > Hm, it's the C (canaries). The rest is OK.
> > Is there something about canaries on the BBB?
> 
> if it's only some programs, then it's because those are older programs.

Yes they are. I will get back after they recompile. Thanks.

Jan

Re: malloc.conf on BeagleBone Black

[hans]

On May 10 18:02:12, o...@drijf.net wrote:
> hans  schreef op 10 mei 2016 17:12:23 CEST:
> >I started using the wonderfull malloc.conf,
> >setting it to CFGJPRSU. This works on amd64 and macppc and i386,
> >but on a freshly upgraded current/armv7 (a BeagleBone Black),
> >some programs report
> >
> > malloc() warning: unknown char in MALLOC_OPTIONS
> >
> >Each of the flags is documented in the malloc.conf(5) manpage.
> >Is there something specific about this on the BBB?
> >
> > Jan
> 
> 
> Well, that's a lot of flags, things will get slow Some are redundant 
> (included in S), some are already on by default. I would advise just to use S 
> and be done with it.
> 
> Why you do not get the expected results on armv7 I do not know.
> My guesses are: older version of libc or typo

This is current/armv7 (May 8).
I have double hecked the string.

> Eliminate flags until you find the offending one.

Hm, it's the C (canaries). The rest is OK.
Is there something about canaries on the BBB?

Jan

malloc.conf on BeagleBone Black

[hans]

I started using the wonderfull malloc.conf,
setting it to CFGJPRSU. This works on amd64 and macppc and i386,
but on a freshly upgraded current/armv7 (a BeagleBone Black),
some programs report

malloc() warning: unknown char in MALLOC_OPTIONS

Each of the flags is documented in the malloc.conf(5) manpage.
Is there something specific about this on the BBB?

Jan

Re: tmux vs UTF8 [solved]

[hans]

On May 01 18:14:33, nicholas.marri...@gmail.com wrote:
> Jan, please make sure you are running -current (build and install tmux
> from CVS HEAD) and if the problem still exists run this

I have the HEAD tmux now.

> tmux -vvvLtest -f/dev/null new

Strangely, with this line, I don't see the problem;
with just 'tmux', I do.

That's probably not due to -v; and I just moved my ~/.tmux/xonf away.
Here it is for completeness:

set -g status-interval 60
set -g status-right '#h | #(test `apm -b` -lt 4 && echo "`apm -l`%% | ")%H:%M'

That leaves -L, and indeed, 'tmux -Ltest' works fine!

And after I exited all the tmuxes that were running,
the freshly launched one works fine too 

(Was it a stale /tmp/tmux-1000/default socket of my less-than-current tmux?)


> Then type ONE of the broken characters with the keyboard, exit tmux and
> send me the tmux-server-*.log file from the current directory.

See below. I typed an a-caron, enter, then crtl-D to exit


Thank you

Jan



1462198970.960747 server started (93180): socket /tmp/tmux-1000/test, protocol 8
1462198970.960833 on OpenBSD 5.9 GENERIC.MP#1999; libevent 1.4.15-stable 
(kqueue)
1462198970.961099 continuing cmdq 0x55dfd3dd400: flags 0, client 0x0
1462198970.961171 cmdq 0x55dfd3dd400: bind-key C-b send-prefix
1462198970.961230 preparing state for bind-key C-b send-prefix (client 0x0)
1462198970.961241 cmd_find_client: no target, return 0x0
1462198970.961253 preparing -t state: target none
1462198970.961260 preparing -s state: target none
1462198970.961281 preparing state for bind-key C-b send-prefix (client 0x0)
1462198970.961289 cmd_find_client: no target, return 0x0
1462198970.961295 preparing -t state: target none
1462198970.961301 preparing -s state: target none
1462198970.961336 continuing cmdq 0x55dfd3dd400: flags 0, client 0x0
1462198970.961348 cmdq 0x55dfd3dd400: bind-key C-o rotate-window
1462198970.961362 preparing state for bind-key C-o rotate-window (client 0x0)
1462198970.961369 cmd_find_client: no target, return 0x0
1462198970.961375 preparing -t state: target none
1462198970.961381 preparing -s state: target none
1462198970.961394 preparing state for bind-key C-o rotate-window (client 0x0)
1462198970.961407 cmd_find_client: no target, return 0x0
1462198970.961414 preparing -t state: target none
1462198970.961420 preparing -s state: target none
1462198970.961456 continuing cmdq 0x55dfd3dd400: flags 0, client 0x0
1462198970.961469 cmdq 0x55dfd3dd400: bind-key C-z suspend-client
1462198970.961482 preparing state for bind-key C-z suspend-client (client 0x0)
1462198970.961489 cmd_find_client: no target, return 0x0
1462198970.961496 preparing -t state: target none
1462198970.961501 preparing -s state: target none
1462198970.961514 preparing state for bind-key C-z suspend-client (client 0x0)
1462198970.961521 cmd_find_client: no target, return 0x0
1462198970.961527 preparing -t state: target none
1462198970.961533 preparing -s state: target none
1462198970.961560 continuing cmdq 0x55dfd3dd400: flags 0, client 0x0
1462198970.961573 cmdq 0x55dfd3dd400: bind-key Space next-layout
1462198970.961614 preparing state for bind-key Space next-layout (client 0x0)
1462198970.961622 cmd_find_client: no target, return 0x0
1462198970.961628 preparing -t state: target none
1462198970.961634 preparing -s state: target none
1462198970.961647 preparing state for bind-key Space next-layout (client 0x0)
1462198970.961654 cmd_find_client: no target, return 0x0
1462198970.961660 preparing -t state: target none
1462198970.961666 preparing -s state: target none
1462198970.961700 continuing cmdq 0x55dfd3dd400: flags 0, client 0x0
1462198970.961721 cmdq 0x55dfd3dd400: bind-key ! break-pane
1462198970.961735 preparing state for bind-key ! break-pane (client 0x0)
1462198970.961742 cmd_find_client: no target, return 0x0
1462198970.961748 preparing -t state: target none
1462198970.961754 preparing -s state: target none
1462198970.961767 preparing state for bind-key ! break-pane (client 0x0)
1462198970.961773 cmd_find_client: no target, return 0x0
1462198970.961779 preparing -t state: target none
1462198970.961785 preparing -s state: target none
1462198970.961808 continuing cmdq 0x55dfd3dd400: flags 0, client 0x0
1462198970.961820 cmdq 0x55dfd3dd400: bind-key " split-window
1462198970.961833 preparing state for bind-key " split-window (client 0x0)
1462198970.961839 cmd_find_client: no target, return 0x0
1462198970.961845 preparing -t state: target none
1462198970.961851 preparing -s state: target none
1462198970.961864 preparing state for bind-key " split-window (client 0x0)
1462198970.961871 cmd_find_client: no target, return 0x0
1462198970.961877 preparing -t state: target none
1462198970.961882 preparing -s state: target none
1462198970.961907 continuing cmdq 0x55dfd3dd400: flags 0, client 0x0
1462198970.961919 cmdq 0x55dfd3dd400: bind-key # list-buffers
1462198970.961940 preparing state for bind-key # list-buffers (client 0x0)
1462198970.961947 cmd_find

Re: tmux vs UTF8

[hans]

On May 01 19:10:03, schwa...@usta.de wrote:
> > In the last snapshot, it seems, tmux does not do UTF8 input correctly,
> > while xterm is fine. This used to work with the ~/.xsession below.
> > 
> > When typing non-ascii in xterm or in a vim-in-an-xterm
> > ot a mutt-in-an-xterm, thay appear OK. When in a tmux window,
> > they look like garbage.
> > 
> > Interestingly, if I type some Czech text into /tmp/cz 
> > (using vim in an xterm, whre it works), and then open
> > the file with vim in tmux, the text there appears fine
> > - only _new_ text typed within tmux looks broken.
> > 
> > Has anything changed in the way tmux handles UTF8?
> 
> Such generic questions are always hard to answer.
> Yes, some things changed recently, but who knows whether
> that is related?
> 
> > Is anyone else seeing this?
> 
> Trying to reproduce and then fix is a good idea.
> However, i can't reproduce so far.
> 
> Here is what i did:
> 
>   $ cd /usr/src/usr.bin/tmux/
>   $ make cleandir
>   $ make obj
>   $ make cleandir
>   $ cvs up -dP
>   $ make depend
>   $ make
>   $ doas make install
>   $ tmux

I have rebuilt my tmux from HEAD too now.

> And now, inside the tmux window, typing in accented characters
> works fine for me, both on the ksh(1) command line and inside vim(1).
> 
> Obviously, i don't have a CZ keyboard; but this shouldn't make
> the difference, or should it?

I don't think it should.

>   schwarze@isnote $ setxkbmap -query
>   rules:  base
>   model:  pc105
>   layout: us
>   options:compose:ralt,altwin:left_meta_win

>   schwarze@isnote $ locale   
>   LANG=
>   LC_COLLATE="C"
>   LC_CTYPE=en_US.UTF-8
>   LC_MONETARY="C"
>   LC_NUMERIC="C"
>   LC_TIME="C"
>   LC_MESSAGES="C"
>   LC_ALL=

hans@biblio:~$ setxkbmap -query 
rules:  base
model:  pc105
layout: us,cz
options:grp:shifts_toggle,grp_led:scroll

hans@biblio:~$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE=cs_CZ.UTF-8
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES=C
LC_ALL=


> I don't have an ~/.xmodmaprc, i don't know what is in yours,
> and i have no idea whether that's related.

Sorry  for not including that:

$ cat .xmodmaprc  
keycode  29 = y Y y Y leftarrow yen
keycode  52 = z Z z Z degree less

The default cz variant has y/z switched, I switch it back.
This is most probably not related.


> > good line: ?? (vim in xterm)
> > bad line :  (vim in tmux in xterm)
> 
> That's double encoding.  Here is information regarding the first
> character from uniname(1):
> 
>   char byte UTF-32 encod name
>  00 00011B C4 9B LATIN SMALL LETTER E WITH CARON

> If you misinterpret that as U+00C4 U+009B and encode it again,
> you get:
> 
>   char byte UTF-32 encod name
>  00 C4 C3 84 LATIN CAPITAL LETTER A WITH DIAERESIS
>  12 9B C2 9B CONTROL SEQUENCE INTRODUCER

My bad again: I am not sure I typed the same keys in those two lines.

However, the first letter in the good line is the a with a caron;
and the first letter in the bad line is capital A with a diaeresis.
But capital A with a diaeresis is not what I wanted to type,
that's where the problem is. Could this misinterpretation
be what I am seeing?

Here is include a better test of the same:
the first line contains the input obtained with pressing the keys
2 to 0 using the cz keyboard in vim in an xterm. The second line
is the input obtained by pressing the same in vim in tmux in xterm):

ěščřžýáíé
ěščřžýáíé


Jan

tmux vs UTF8

[hans]

In the last snapshot, it seems, tmux does not do UTF8 input correctly,
while xterm is fine. This used to work with the ~/.xsession below.

When typing non-ascii in xterm or in a vim-in-an-xterm
ot a mutt-in-an-xterm, thay appear OK. When in a tmux window,
they look like garbage.

Interestingly, if I type some Czech text into /tmp/cz 
(using vim in an xterm, whre it works), and then open
the file with vim in tmux, the text there appears fine
- only _new_ text typed within tmux looks broken.

Has anything changed in the way tmux handles UTF8?
Is anyone else seeing this?

Jan


$ cat ~/.xsession
#!/bin/sh

#gtf 1280 1024 60.0
#xrandr --newmode 1280x1024_60.00 108.88 1280 1360 1496 1712 1024 1025 1028 
1060 -HSync +Vsync
#xrandr --addmode VGA1 1280x1024_60.00
#xrandr --output VGA1 --mode 1280x1024_60.00

xsetroot -solid black
#xset -b -c dpms 300 600 900 m 2 0 r rate 400 30 s blank s 120 60

setxkbmap -layout "us,cz" -option "grp:shifts_toggle,grp_led:scroll"
xmodmap ~/.xmodmaprc

#xrdb -load ~/.Xresources
export XENVIRONMENT=~/.Xresources
export LC_CTYPE="cs_CZ.UTF-8"

cwm


$ cat /tmp/cz

good line: ěščřžýáíé (vim in xterm)
bad line : ěščřžýáíé (vim in tmux in xterm)

Belkin PCMCIA wifi

[hans]

I have this Belkin card (model F5D8010)
which reports on current/amd64 as

unknown vendor 0x17cb product 0x0001 (class network subclass ethernet, rev 
0x01) at cardbus1 dev 0 function 0 not configured

but does not show up as an interface.
What can I do to help make it supported?

Jan

Re: Trying to move my httpd chroot

[hans]

On Mar 16 20:58:59, alan01...@gmail.com wrote:
> I don't have enough room in / to have my htdocs there so I want to
> move it to /usr/htdocs. This is in 5.7.   No problem I thought, I've
> had to do it before.  So my /etc/httpd.conf looks like this:
> 
> chroot "/usr/htdocs"

Why din't you use he standard /var/www?

> And I get logging into /usr/htdocs/logs but httpd doesn''t seem to
> find files in /usr/htdocs.

What is your "root" directive for the server?
Remember, it's relative to the chroot.

> I get a 404 error that says OpenBSD httpd
> in it but it can't find even index.html which does exist.  I've played
> with htdocs vs htdocs/.  If I comment out the chroot line it finds
> files in /var/www/htdocs.  My /usr is in a different MBR partition
> (actually an exended one) with 129 gigs free.

You might be better off having /usr hold your /usr,
and have a biug separate /var/www for your web content.
Then you can leave httpd chroot the default.

> Anybody tried to move their htdocs?  I didn't find anything by
> searching.  I wouldn't want to write something and put it out there
> for everybody to beat on.  I did read the PDF and man pages.
> 
> Also I found that if I set httpd_flags to "-d -v" in
> /etc/rc.conf.local then booting  the machine seems to hang there.

Without -d, the httpd deamonizes into the background,
and the boot goes on. With -d, it stays running in the
foreground; only after you kill it, the boot will go on.

Jan

Re: Trying to move my httpd chroot

[hans]

On Mar 16 22:04:19, alan01...@gmail.com wrote:
> Bingo.  /usr does it.  One clue I guess was that it was logging into
> /usr/logs.  With Apache at least the chroot dir wasn't the same as the
> document root.

With default httpd, it also isn't.

> And you don't want the logs dir readable through the
> httpd.  So essentially there's htdocs and logs inside of what you
> specify as a chroot dir.

Yes.

zdump - nonexistent zone

[hans]

It seems zdump(8) just displays GMT for zones which do not exist.
Is that intended?

Jan

$ zdump Canada/* Canada/Toronto   
Canada/Atlantic   Tue Mar 15 05:22:21 2016 ADT
Canada/CentralTue Mar 15 03:22:21 2016 CDT
Canada/East-Saskatchewan  Tue Mar 15 02:22:21 2016 CST
Canada/EasternTue Mar 15 04:22:21 2016 EDT
Canada/Mountain   Tue Mar 15 02:22:21 2016 MDT
Canada/Newfoundland   Tue Mar 15 05:52:21 2016 NDT
Canada/PacificTue Mar 15 01:22:21 2016 PDT
Canada/Saskatchewan   Tue Mar 15 02:22:21 2016 CST
Canada/Yukon  Tue Mar 15 01:22:21 2016 PDT
Canada/TorontoTue Mar 15 08:22:21 2016 GMT

spamd.conf(5) wording

[hans]

Two bits seem unclear in spamd.conf(5),
at least to a non-native speaker.


 # Strings follow getcap(3) convention escapes, other than you
 # can have a bare colon (:) inside a quoted string and it
 # will deal with it.

"Other that _that_ you can have a bare colon"?


 # Lists specified with the :white: capability apply to the previous
 # list with a :black: capability.

Should that be "lists"? Or does a :white: list only apply
to the one :black: "list" immediately preceding it?

Jan

Re: /etc/hosts during install

[hans]

On Mar 12 17:25:45, rob...@peichaer.org wrote:
> On Sat, Mar 12, 2016 at 05:49:32PM +0100, hans wrote:
> > On Mar 12 16:36:37, rob...@peichaer.org wrote:
> > > On Sat, Mar 12, 2016 at 04:57:04PM +0100, hans wrote:
> > > > Has the attitude towards /etc/hosts changed again?
> > > > After a fresh install of current/i386,
> > > > 
> > > > 127.0.0.1   localhost
> > > > ::1 localhost
> > > > 192.168.22.4www.stare.cz www
> > > > 
> > > > The first two I would expect.
> > > > The last one was assigned to me via DHCP during install;
> > > > I am changing the network configuration now (to another,
> > > > static IP address), and removing it from /etc/hosts;
> > > > but it's easy to have a stale DHCP address
> > > > assigned during install left in /etc/hosts.
> > > > 
> > > > I believe it was discussed on the list before,
> > > > and the decision was not to do this.
> > > > Has the rationale changed?
> > > > 
> > > > Jan
> > > 
> > > You're probably referring to this commit from 2 years ago and since then
> > > nothing changed with respect to adding static entries to /etc/hosts.
> > > 
> > >revision 1.682
> > >date: 2013/07/21 22:06:51;  author: halex;  state: Exp;  lines: +1 -6;
> > >stop adding static entries to /etc/hosts for dynamic ip addresses
> > > 
> > >"do it NOW" deraadt@
> > 
> > Yes, that's what I was referring to; thanks.
> > 
> > This is a fresh install, and I sure didn't put it there myself.
> > How could this entry ended up in my /etc/hosts ?
> > 
> > The file /etc/hosts is in the Attic since Fri Sep 5 07:22:29 2014 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/Attic/hosts
> > The remove message says
> > 
> > Make the installer create the /etc/hosts template.
> > While here, re-add a missing 'echo' from install.sh.
> > 
> > Could it be where it got back?
> > 
> > Jan
> 
> No, I don't think so. The corresponding change in install.sh from ajacoutot@
> (rev. 1.258) just writes the two localhost entries to the hosts file instead
> of using a static hosts template file containing these two localhost entries.
> 
> I just did a test install myself to verify the current installer behaviour.
> Having one interface and using 'dhcp' to configure it results in the two
> localhost lines and nothing more. I used the latest snapshot for that.

I am sorry - I was wrong in the original descripton.
The address and name was installed _manually_ during the install
(as opposed to dhcp).

Is it desirable to have it in /etc/hosts in that case?

Jan

Re: /etc/hosts during install

[hans]

On Mar 12 16:36:37, rob...@peichaer.org wrote:
> On Sat, Mar 12, 2016 at 04:57:04PM +0100, hans wrote:
> > Has the attitude towards /etc/hosts changed again?
> > After a fresh install of current/i386,
> > 
> > 127.0.0.1   localhost
> > ::1 localhost
> > 192.168.22.4www.stare.cz www
> > 
> > The first two I would expect.
> > The last one was assigned to me via DHCP during install;
> > I am changing the network configuration now (to another,
> > static IP address), and removing it from /etc/hosts;
> > but it's easy to have a stale DHCP address
> > assigned during install left in /etc/hosts.
> > 
> > I believe it was discussed on the list before,
> > and the decision was not to do this.
> > Has the rationale changed?
> > 
> > Jan
> 
> You're probably referring to this commit from 2 years ago and since then
> nothing changed with respect to adding static entries to /etc/hosts.
> 
>revision 1.682
>date: 2013/07/21 22:06:51;  author: halex;  state: Exp;  lines: +1 -6;
>stop adding static entries to /etc/hosts for dynamic ip addresses
> 
>"do it NOW" deraadt@

Yes, that's what I was referring to; thanks.

This is a fresh install, and I sure didn't put it there myself.
How could this entry ended up in my /etc/hosts ?

The file /etc/hosts is in the Attic since Fri Sep 5 07:22:29 2014 
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/Attic/hosts
The remove message says

Make the installer create the /etc/hosts template.
While here, re-add a missing 'echo' from install.sh.

Could it be where it got back?

Jan

/etc/hosts during install

[hans]

Has the attitude towards /etc/hosts changed again?
After a fresh install of current/i386,

127.0.0.1   localhost
::1 localhost
192.168.22.4www.stare.cz www

The first two I would expect.
The last one was assigned to me via DHCP during install;
I am changing the network configuration now (to another,
static IP address), and removing it from /etc/hosts;
but it's easy to have a stale DHCP address
assigned during install left in /etc/hosts.

I believe it was discussed on the list before,
and the decision was not to do this.
Has the rationale changed?

Jan

Firejail in OpenBSD?

[hans peter]

Hello,
Firejail secures* the everyday apps that a user uses on an example
Desktop machine: Firefox, transmission, etc.:
https://firejail.wordpress.com/ Is there any alternatives on OpenBSD for
Firejail? Or could it be ported? *The sandbox is lightweight, the
overhead is low. There are no complicated configuration files to edit, no
socket connections open, no daemons running in the background. Many
thanks, http://www.openbsdfoundation.org/campaign2016.html

cron - approval failed

[hans]

This is what cron said to me on a current/macppc,
when incidentally, the machine was just (re)booting:

On Dec 28 12:00:01, root wrote:
> approval failed for hans


Dec 28 12:00:04 www syslogd: exiting on signal 15
Dec 28 12:00:53 www syslogd: start
Dec 28 12:00:53 www /bsd: syncing disks... done
Dec 28 12:00:53 www /bsd:  support
Dec 28 12:00:53 www /bsd: o
Dec 28 12:00:53 www /bsd: [ using 501892 bytes of bsd ELF symbol table ]
[...]


Could someone please elaborate on the cron behaviour
when the cron minute is a reboot minute?
In particular, what "aproval" is needed in that case?

Jan

Re: Cisco IPSEC proposals

[Hans-Joerg Hoexer]

On Thu, Mar 05, 2009 at 02:32:36PM -0700, Cameron Schaus wrote:
> I recently configured an IPSEC tunnel between OpenBSD 4.4 machine and a Cisco 
> gateway.  I had trouble during the key exchange because I had configured DH 
> group 2.  The Cisco sent a proposal for DH group 5 with a lifetime of 7800 
> seconds, along with a proposal for DH group 2 with a lifetime of 00015180 
> seconds.
>
> The key exchange would not complete until I changed the OpenBSD side to use 
> DH group 5.  The only difference in the proposal appears to be the lifetime.
>
> Does anyone know why the Cisco would send a lifetime of 00015180 seconds (the 
> Cisco tech said he configured it for 86400 seconds)?

0x15180 is 86400 decimal

> I'm also interested why OpenBSD responded with NO_PROPOSAL_CHOSEN in this 
> instance?
>
>payload: SA len: 160 DOI: 1(IPSEC) situation: IDENTITY_ONLY
>payload: PROPOSAL len: 148 proposal: 1 proto: ISAKMP spisz: 0
> xforms: 4
>payload: TRANSFORM len: 32
>transform: 1 ID: ISAKMP
>attribute ENCRYPTION_ALGORITHM = 3DES_CBC
>attribute HASH_ALGORITHM = SHA
>attribute GROUP_DESCRIPTION = MODP_1536
>attribute AUTHENTICATION_METHOD = PRE_SHARED
>attribute LIFE_TYPE = SECONDS
>attribute LIFE_DURATION = 7800
>payload: TRANSFORM len: 36
>transform: 2 ID: ISAKMP
>attribute ENCRYPTION_ALGORITHM = 3DES_CBC
>attribute HASH_ALGORITHM = SHA
>attribute GROUP_DESCRIPTION = MODP_1024
>attribute AUTHENTICATION_METHOD = PRE_SHARED
>attribute LIFE_TYPE = SECONDS
>attribute LIFE_DURATION = 00015180
>
> Mar  5 08:30:28 gw1 isakmpd[6650]: dropped message from x.x.x.x port 500 due 
> to notification type NO_PROPOSAL_CHOSEN
>
> Thanks,
> Cam

ПОЗДРАВЛЯЕ

[HANS BENS]

B!Tengo nueva direcciC3n de correo!Ahora puedes escribirme 
a:hans.b...@yahoo.com.co



- PP0Q P0P4QP5Q
 Q
P;P5P:QQP>P=P=P>P9 P?P>QQQ P2QP8P3QP0P;P0 PQ P>P1Q   P5P9 Q
QPP;P;.P!P(P, PP2Q
QQP0P;P8P8 P2 Q
P5QP8 PP=QP5QP=P5Q 
P;P>QP5QP5Q. P-P1P8P;P5Q P=P>PP=QQ
 QP8Q
P;P>P< 17. P!P2QP6P8QP5Q
Q Q
 
P=P0QP8PP7P4QP0P2P;P5P=P8Q. P! QP2P0P6P5P=P8P5P<, 
P3-P6P0 PP8QP5P;Q PP8P=P:P>P;QP=Q P4P>P;P6P=QP?QP5P4P>Q
QP0P2P8QQ
,PP0QP5 P8PPP=P0

Re: Cisco IPSec Security Association Idle Timers and isakmpd

[Hans-Joerg Hoexer]

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.

Re: IPSec to Checkpoint

[Hans-Joerg Hoexer]

Support for specifying aes key sizes was added february 2008, thus 4.2
does not provide this.

On Wed, Nov 12, 2008 at 03:17:17PM +, Joe Warren-Meeks wrote:
> On Wed, Nov 12, 2008 at 02:35:35PM +0100, Claer wrote:
> 
> Hey there,
> 
> OK, so I've switched to ipsec.conf and it is alot easier!
> 
> However, I'm still struggling to use aes 256.
> 
> I have the following:
> 
> ike esp from 195.24.xxx.x/25 to 62.232.yyy.y/27 \
> local 195.24.aaa.aa peer 62.232.bbb.bbb \
> main auth hmac-sha1 enc aes group modp1024 \
> quick auth hmac-sha1 enc aes psk sudomakemeagoat
> 
> This uses aes128. Is there any way to get aes256 working? Note: I'm on
> 4.2, was 256 support added later? If not, is there any way I could
> enable 256 on 4.2?
> 
>  -- joe.
> 
> I can't believe Alan Davies would do that. I absolutely love him!

Re: Using OpenBGPD as a route-server

[Hans Vosbergen]

Hi Claudio,

Thanks, this has been helpfull. However i really need that bit of control
from the peer's configuration end.

You wouldn't happen to know how i can achieve the following?:

A peer sends the following communities to the RS: 1234:1234 1234:7547
1234:8392

I want the route-server to send the routes received in the communities (yes
they all contain the same routes) to every peer on the RS, except for those
with AS 7547 and 8392.

Was also wondering why you have that prepend rule in #5 while transparent-as
is configured?

Regards,
Hans

On Wed, Oct 29, 2008 at 12:08 PM, Claudio Jeker <[EMAIL PROTECTED]>wrote:

>  On Tue, Oct 28, 2008 at 04:24:02PM +0100, Hans Vosbergen wrote:
> > Hi Misc,
> >
> > I am trying to make OpenBGPD work as a route-server for a little hobby
> > project I am working on.
> >
> > As it's very hard to find configuration examples for this usage on the
> web i
> > have to turn here.
> >
> > What I am trying to achieve:
> > - A route-server acting as a transparent route distributor.
> > - Control by neighbours who their prefixes are announced to, based on
> > communities.
> >
> > Making OpenBGP work as a transparent AS was the easy part. However I'm
> stuck
> > in the communities control part.
> >
> > How it is supposed to work, my route-server has AS1234 in my test
> > environment.
> >
> > If a neighbour announces:
> > 1. { community 1234:1234 } -- Their prefixes will be announced to EVERY
> > other neighbour.
> > 2. { community 1234:} -- Their prefixes will ONLY be announced to
> ,
> > ie: 1234:8943 will only send the prefixes to AS8943.
> > 3. { community 1234:1234 1234: } -- Their prefixes will be announced
> to
> > every other neighbour EXCEPT .
> >
> > I have been able to achieve the first 2 ways the prefix control should
> work,
> > but I can't manage to get the 3rd to work. Before moving to OpenBGPD I
> > managed to produce the way I want it to work in Quagga but I simply do
> not
> > want to use that.
> >
> > Would anyone have an idea on how to make OpenBGPD not announce prefixes
> to
> > specific neighbours if they appear in the 1234:1234 1234: list?
> >
>
> The route server I set up uses more or less this config:
>
> # global configuration
> AS $ASNUM
> router-id $IP
> transparent-as yes
>
> network $LAN
>
> group RS {
>announce all
>max-prefix 5000 restart 15
>set nexthop no-modify
> #   softreconfig in no
>
>neighbor $LAN {
>descr "RS peer"
>passive
>}
> }
>
> # filter out prefixes longer than 24 or shorter than 8 bits
> deny from any prefixlen 8 >< 24
>
> # do not accept a default route, multicast and experimental networks
> deny from any prefix 0.0.0.0/0
> deny from any prefix 10.0.0.0/8 prefixlen >= 8
> deny from any prefix 127.0.0.0/8 prefixlen >= 8
> deny from any prefix 169.254.0.0/16 prefixlen >= 16
> deny from any prefix 172.16.0.0/12 prefixlen >= 12
> deny from any prefix 192.0.2.0/24 prefixlen >= 24
> deny from any prefix 192.168.0.0/16 prefixlen >= 16
> deny from any prefix 224.0.0.0/4 prefixlen >= 4
> deny from any prefix 224.0.0.0/4 prefixlen >= 4
> deny from any prefix 240.0.0.0/4 prefixlen >= 4
>
> # we set's these communities to identify from where
> # it learned a route:
> match from any set community $ASNUM:neighbor-as
>
> # 1. Prepend RS $ASNUM to *all* RS-Peers
> match from group RS community $ASNUM:65500 set prepend-self 1
>
> # 2. Prepend RS $ASNUM to *selected* RS-Peer N-times
> # (N can be 1 to 3)
> match to group RS community 65501:neighbor-as set prepend-self 1
> match to group RS community 65502:neighbor-as set prepend-self 2
> match to group RS community 65503:neighbor-as set prepend-self 3
>
> # 3. Do *not* announce to RS-Peers with AS 
> deny to group RS community $ASNUM:neighbor-as
>
> # 4. Do *not* announce to *ANY* RS-Peers
> deny to group RS community $ASNUM:65535
>
> # 5. Prepend own announcement by one
> match to group RS prefix $LAN set prepend-self 1
>
> Works like a champ without any additional per peer config :)
> --
> :wq Claudio

Using OpenBGPD as a route-server

[Hans Vosbergen]

Hi Misc,

I am trying to make OpenBGPD work as a route-server for a little hobby
project I am working on.

As it's very hard to find configuration examples for this usage on the web i
have to turn here.

What I am trying to achieve:
- A route-server acting as a transparent route distributor.
- Control by neighbours who their prefixes are announced to, based on
communities.

Making OpenBGP work as a transparent AS was the easy part. However I'm stuck
in the communities control part.

How it is supposed to work, my route-server has AS1234 in my test
environment.

If a neighbour announces:
1. { community 1234:1234 } -- Their prefixes will be announced to EVERY
other neighbour.
2. { community 1234:} -- Their prefixes will ONLY be announced to ,
ie: 1234:8943 will only send the prefixes to AS8943.
3. { community 1234:1234 1234: } -- Their prefixes will be announced to
every other neighbour EXCEPT .

I have been able to achieve the first 2 ways the prefix control should work,
but I can't manage to get the 3rd to work. Before moving to OpenBGPD I
managed to produce the way I want it to work in Quagga but I simply do not
want to use that.

Would anyone have an idea on how to make OpenBGPD not announce prefixes to
specific neighbours if they appear in the 1234:1234 1234: list?

My configuration:
--
AS 1234
router-id 10.0.0.60
fib-update no
log updates
listen on 10.0.0.60

nexthop qualify via bgp
transparent-as yes

group "peers-rs-v4" {
announce IPv4 unicast
softreconfig in yes
enforce neighbor-as yes

neighbor 10.0.0.61 {
descr "juniperm5"
remote-as 65501
announce all
passive
}
neighbor 10.0.0.64 {
descr "foundryxmr"
remote-as 65502
announce all
passive
}
neighbor 10.0.0.63 {
descr "cisco7200"
remote-as 65503
announce all
passive
}
}

deny from any
deny from any prefix 0.0.0.0/0
deny from any prefix 10.0.0.0/8 prefixlen >= 8
deny from any prefix 172.16.0.0/12 prefixlen >= 12
deny from any prefix { 192.168.0.0/16 169.254.0.0/16 } prefixlen >= 16
deny from any prefix 169.254.0.0/16 prefixlen <= 32

deny from any community *:*
deny to any community *:*

# Community 1234:65502 goes to AS65502
allow from any community 1234:65502
allow to 10.0.0.64 community 1234:65502

# Community 1234:1234 goes to everyone
allow from any community 1234:1234
allow to any community 1234:1234

Re: ipsec.conf and AES 256

[Hans-Joerg Hoexer]

On Mon, Nov 19, 2007 at 12:26:16PM +0100, Mitja Mu?eni? wrote:
> As far as I can tell, currently in ipsec.conf there is no way to use AES
> with KEY_LENGHT=256. Is anybody working on adding this? Otherwise I might
> try it when the time permits. 
> 
> I'm thinking that isakmpd should first learn about a new default transform,
> let's say AES256 - then adding that into ipsecctl/ipsec.conf should be
> pretty much trivial. 

this sounds like a reasonable approach to me.

> 
> The other route is not to add this new default transform to isakmpd, but to
> have ipsecctl generate a config with a non-default transform - this does not
> touch isakmpd at all, but is less than trivial in ipsecctl.
> 
> Thoughts, anyone?
> 
> Mitja

Re: Wasting our Freedom

[Hans-Jürgen Koch]

Am Montag 17 September 2007 15:15 schrieb Jason Dixon:

> 
> The GPL places additional restrictions on code.  It is therefore less  
> free than the BSD.
> 
> Free code + restrictions = non-free code.

The legal restriction that people must not enter your house uninvited
by smashing the door adds to your freedom, don't you think so?

Hans

Re: IPSec

[Hans-Joerg Hoexer]

Hi,

could you try the attached diff, please?

Index: message.c
===
RCS file: /cvs/src/sbin/isakmpd/message.c,v
retrieving revision 1.126
diff -u -p -r1.126 message.c
--- message.c   2 Jun 2007 01:29:11 -   1.126
+++ message.c   3 Sep 2007 22:30:46 -
@@ -927,6 +927,7 @@ message_validate_notify(struct message *
if (type < ISAKMP_NOTIFY_INVALID_PAYLOAD_TYPE ||
(type >= ISAKMP_NOTIFY_RESERVED_MIN &&
type < ISAKMP_NOTIFY_PRIVATE_MIN) ||
+   type == ISAKMP_NOTIFY_STATUS_CONNECTED ||
(type >= ISAKMP_NOTIFY_STATUS_RESERVED1_MIN &&
type <= ISAKMP_NOTIFY_STATUS_RESERVED1_MAX) ||
(type >= ISAKMP_NOTIFY_STATUS_DOI_MIN &&

Re: IPSEC.CONF with Dynamic IP address (parse HOST name) doesnt seem to work

[Hans-Joerg Hoexer]

Just use a recent snapshot.  Support for names instead of ip addresses has
been added, mh, at least a year ago.

HJ.

On Tue, Sep 04, 2007 at 12:32:55PM +0200, * VLGroup Forums wrote:
> Hello everyone,
> 
> I have several VPN tunnels between OBSD 3.8 systems (LAN to LAN via
> VPN). These all have fixed IP addresses and all works
> fine  :-) . However, now I have a OBSD 3.8 system that gets a Dynamic IP
> address. I mapped that address to a hostname using DynDNS.org
> Using ipcheck.py (a python program) it keeps the DynDns.org DNS servers
> up-to-date when a IP change occurs. So far, so good.
> 
> I was hoping to  " simply "  use the DynDns host name in the IPSEC.CONF
> file, but that doesnt seem to work :-(( .
> For this mail I changed the name to "remote5.dyndns.org". The "real"
> name pings ok can  Ii can use it to SSH into the machine.
> 
> #
> # IPSEC to remote location 5
> # Active host, remote location is passive
> #
> ike esp from 172.17.0.0/16  to 192.168.76.0/22 peer remote5.dyndns.org
> ike esp from   to 192.168.76.0/22 peer remote5.dyndns.org
> ike esp from   to remote5.dyndns.org
> 
> Note the "remote5.dyndns.org" instead of a IP address.
> 
> When I load this config file I get :
> 
> # ipsecctl -f /etc/ipsec.conf
> 
> /etc/ipsec.conf: 46: could not parse host specification
> /etc/ipsec.conf: 47: could not parse host specification
> /etc/ipsec.conf: 48: could not parse host specification
> ipsecctl: Syntax error in config file: ipsec rules not loaded
> 
> How to get around this, that is, get the host named 'parsed' inside the
> ipsec.conf file towards the
> correct IP address ?
> 
> regards
> Wiljoh

Re: IPSec

[Hans-Joerg Hoexer]

Hi,

On Mon, Sep 03, 2007 at 03:11:35PM +0100, Josi Costa wrote:
> Sep  3 15:05:16 obsd1 isakmpd[25239]: dropped message from
> 172.26.10.83 port 500 due to notification type NO_PROPOSAL_CHOSEN
> Sep  3 15:05:16 obsd1 isakmpd[25239]: responder_recv_HASH_SA_NONCE:
> KEY_EXCH payload without a group desc. attribute
> Sep  3 15:05:16 obsd1 isakmpd[25239]: dropped message from
> 172.26.10.83 port 500 due to notification type NO_PROPOSAL_CHOSEN
> Sep  3 15:05:16 obsd1 isakmpd[25239]: responder_recv_HASH_SA_NONCE:
> peer proposed invalid phase 2 IDs: initiator id ac1a0a53:
> 172.26.10.83, responder id 0a80/ff80:
> 10.0.0.128/255.255.255.128

isakmpd tells you, that the peer sent the wront phase 2 ID.

Here, you tell ISA to propose these IDs, but...

> Remote Network 'OBSD1' IP Subnets:
> Subnet: 10.0.0.1/255.255.255.255
> Subnet: 10.0.0.2/255.255.255.254
> Subnet: 10.0.0.4/255.255.255.252
> Subnet: 10.0.0.8/255.255.255.248
> Subnet: 10.0.0.16/255.255.255.240
> Subnet: 10.0.0.32/255.255.255.224
> Subnet: 10.0.0.64/255.255.255.192
> Subnet: 10.0.0.128/255.255.255.128

here you tell isakmpd to accept only 10.0.1.0/24, which is never proposed
by the peer:

--- /etc/ipsec.conf ---

ike dynamic esp from 10.0.0.0/24 to 10.0.1.0/24 peer 172.26.10.83 \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des \
psk teste tag teste


To get started, tell ISA to only use one remote subnet, ie. 10.0.1.0/24

Re: IPSec

[Hans-Joerg Hoexer]

On Mon, Sep 03, 2007 at 02:45:46PM +0100, Josi Costa wrote:
> 3des, sha1, PFS disabled.

ok, then enable pfs, use modp1024

Re: IPSec

[Hans-Joerg Hoexer]

Hi,

which transforms are configured on the ISA server for phase 2?

On Mon, Sep 03, 2007 at 02:21:24PM +0100, Josi Costa wrote:
> How can I solve this? Any docs about it? Debugging?
> 
> On 9/3/07, Hans-Joerg Hoexer <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On Mon, Sep 03, 2007 at 12:59:48PM +0100, JosC) Costa wrote:
> > >
> > > Sep  3 13:49:55 obsd1 isakmpd[1074]: dropped message from 172.26.10.83
> > > port 500 due to notification type NO_PROPOSAL_CHOSEN
> > > Sep  3 13:49:55 obsd1 isakmpd[1074]: responder_recv_HASH_SA_NONCE:
> > > KEY_EXCH payload without a group desc. attribute
> > > Sep  3 13:49:55 obsd1 isakmpd[1074]: dropped message from 172.26.10.83
> > > port 500 due to notification type NO_PROPOSAL_CHOSEN
> > > Sep  3 13:49:55 obsd1 isakmpd[1074]: responder_recv_HASH_SA_NONCE:
> > > KEY_EXCH payload without a group desc. attribute
> >
> > isakmpd does not like the transforms for phase 2 proposed by the other
> > peer.  It seems, that phase 2 has no group description.
> >
> > >
> > > --- /etc/ipsec.conf ---
> > >
> > > ike dynamic esp from 10.0.0.0/24 to 10.0.1.0/24 peer 172.26.10.83 \
> > > main auth hmac-sha1 enc 3des group modp1024 \
> > > quick auth hmac-sha1 enc 3des \
> > > psk teste tag teste
> > >
> > > In the ISA Server is configured correctly for the Phase-1 and Phase-2
> > > encriptions and auths.
> > >
> > > Any help here?
> > >
> > >
> > > On 8/31/07, Jeff Quast <[EMAIL PROTECTED]> wrote:
> > > > I tried to learn with HOWTO's, I didnt have the internet at home at
> > > > the time. I printed out maybe 50 pages of various HOWTO's.
> > > >
> > > > When I got home, I found none of them were up to date with the current
> > > > (easy) capabilities of OpenBSD using ipsec.conf and ipsecctl... I
> > > > ended up learning how to do ipsec with just the manuals.
> > > >
> > > > You'd be amazed how easy it went.
> > > >
> > > > On 8/31/07, JosC) Costa <[EMAIL PROTECTED]> wrote:
> > > > > Hello,
> > > > >
> > > > > Anyone knows a really good IPSec howto besides the man pages?

Re: IPSec

[Hans-Joerg Hoexer]

Hi,

On Mon, Sep 03, 2007 at 12:59:48PM +0100, Josi Costa wrote:
> 
> Sep  3 13:49:55 obsd1 isakmpd[1074]: dropped message from 172.26.10.83
> port 500 due to notification type NO_PROPOSAL_CHOSEN
> Sep  3 13:49:55 obsd1 isakmpd[1074]: responder_recv_HASH_SA_NONCE:
> KEY_EXCH payload without a group desc. attribute
> Sep  3 13:49:55 obsd1 isakmpd[1074]: dropped message from 172.26.10.83
> port 500 due to notification type NO_PROPOSAL_CHOSEN
> Sep  3 13:49:55 obsd1 isakmpd[1074]: responder_recv_HASH_SA_NONCE:
> KEY_EXCH payload without a group desc. attribute

isakmpd does not like the transforms for phase 2 proposed by the other
peer.  It seems, that phase 2 has no group description.

> 
> --- /etc/ipsec.conf ---
> 
> ike dynamic esp from 10.0.0.0/24 to 10.0.1.0/24 peer 172.26.10.83 \
> main auth hmac-sha1 enc 3des group modp1024 \
> quick auth hmac-sha1 enc 3des \
> psk teste tag teste
> 
> In the ISA Server is configured correctly for the Phase-1 and Phase-2
> encriptions and auths.
> 
> Any help here?
> 
> 
> On 8/31/07, Jeff Quast <[EMAIL PROTECTED]> wrote:
> > I tried to learn with HOWTO's, I didnt have the internet at home at
> > the time. I printed out maybe 50 pages of various HOWTO's.
> >
> > When I got home, I found none of them were up to date with the current
> > (easy) capabilities of OpenBSD using ipsec.conf and ipsecctl... I
> > ended up learning how to do ipsec with just the manuals.
> >
> > You'd be amazed how easy it went.
> >
> > On 8/31/07, JosC) Costa <[EMAIL PROTECTED]> wrote:
> > > Hello,
> > >
> > > Anyone knows a really good IPSec howto besides the man pages?

Re: ipsec vpn?

[Hans-Joerg Hoexer]

On Thu, Aug 16, 2007 at 06:43:34PM -0700, Steve B wrote:
> I made a few changes and did some more testing this evening.
> 
> 1. I changed the /etc/ipsec.conf to bring it in line with the Greenbow
> default transforms that Hans-Joerg recommened.
> 
> # cat /etc/ipsec.conf
> ike dynamic esp tunnel from any to 192.168.1.0/24 \
> main  auth hmac-sha1 enc 3des group modp1024 \
> quick auth hmac-sha1 enc 3des \
> psk abc123
> 
> 2. I created the basic polciy file:
> 
> # cat /etc/isakmpd/isakmpd.policy
> KeyNote-Version: 2
> Authorizer: "POLICY"
> 
> 3. Being lazy I rebooted the server and tried starting isakmpd manually
> without the "-K". It would not start. When I tried starting it with "-dLv" I
> got the message:
> 
> 180252.969043 Default check_file_secrecy_fd: not loading
> /etc/isakmpd/isakmpd.policy - too open permissions
> 180252.970281 Default policy_init: cannot read /etc/isakmpd/isakmpd.policy:
> Operation not permitted
> 
> So I went back and started it with "-K".

please go back to step 2, however this time set the permissions of
/etc/isakmpd/isakmpd.policy to 600.


> 4. I then turned on packet tracing as Stuart suggested, tried logging in,
> turned packet tracing off and ran tcpdump on the file:
> 
> # echo "p on" > /var/run/isakmpd.fifo
> 
> # echo "p off" > /var/run/isakmpd.fifo
> 
> # tcpdump -r /var/run/isakmpd.pcap -vvn
> tcpdump: WARNING: snaplen raised from 96 to 65536
> 18:08:57.938430 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp
> v1.0 exchange ID_PROT
> cookie: ed67c89ed96545fb-> msgid:  len: 160
> payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
> payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0
> xforms: 1
> payload: TRANSFORM len: 32
> transform: 0 ID: ISAKMP
> attribute ENCRYPTION_ALGORITHM = 3DES_CBC
> attribute HASH_ALGORITHM = SHA
> attribute AUTHENTICATION_METHOD = PRE_SHARED
> attribute GROUP_DESCRIPTION = MODP_1024
> attribute LIFE_TYPE = SECONDS
> attribute LIFE_DURATION = 3600
> payload: VENDOR len: 20 (supports v1 NAT-T,
> draft-ietf-ipsec-nat-t-ike-00)
> payload: VENDOR len: 20 (supports v2 NAT-T,
> draft-ietf-ipsec-nat-t-ike-02)
> payload: VENDOR len: 20 (supports v3 NAT-T,
> draft-ietf-ipsec-nat-t-ike-03)
> payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 188)
> 18:08:57.944015 64.119.37.74.500 > 64.119.40.170.500: [udp sum ok] isakmp
> v1.0 exchange INFO
> cookie: cfef30980a709fe2-> msgid:  len: 40
> payload: NOTIFICATION len: 12
> notification: NO PROPOSAL CHOSEN [ttl 0] (id 1, len 68)
> 
> 5. OK, no good. Nothing jumped out at me in the tcpdump so I changed from
> dynamic to passive, and tried again:
> 
> # cat /etc/ipsec.conf
> ike passive esp tunnel from any to 192.168.1.0/24 \
> main  auth hmac-sha1 enc 3des group modp1024 \
> quick auth hmac-sha1 enc 3des \
> psk abc123
> 
> # ipsecctl -f /etc/ipsec.conf
> 
> killed the isakmpd daemon and restarted it with -K", turned packet tracing
> back on and tried everything again. Got more detail but nothing jumps out at
> me.
> 
> # tcpdump -r /var/run/isakmpd.pcap -vvn
> tcpdump: WARNING: snaplen raised from 96 to 65536
> 18:08:57.938430 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp
> v1.0 exchange ID_PROT
> cookie: ed67c89ed96545fb-> msgid:  len: 160
> payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
> payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0
> xforms: 1
> payload: TRANSFORM len: 32
> transform: 0 ID: ISAKMP
> attribute ENCRYPTION_ALGORITHM = 3DES_CBC
> attribute HASH_ALGORITHM = SHA
> attribute AUTHENTICATION_METHOD = PRE_SHARED
> attribute GROUP_DESCRIPTION = MODP_1024
> attribute LIFE_TYPE = SECONDS
> attribute LIFE_DURATION = 3600
> payload: VENDOR len: 20 (supports v1 NAT-T,
> draft-ietf-ipsec-nat-t-ike-00)
> payload: VENDOR len: 20 (supports v2 NAT-T,
> draft-ietf-ipsec-nat-t-ike-02)
> payload: VENDOR len: 20 (supports v3 NAT-T,
> draft-ietf-ipsec-nat-t-ike-03)
> payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 188)
> 18:08:57.944015 64.11

Re: ipsec vpn?

[Hans-Joerg Hoexer]

Can you try to run isakmpd without "-K" and use a 2 line isakmpd.policy
like this:

KeyNote-Version: 2
Authorizer: "POLICY"

This policy accepts anything, so this should be done only for testing.


On Thu, Aug 16, 2007 at 02:53:44AM +0300, Sergey Prysiazhnyi wrote:
> On Wed, Aug 15, 2007 at 10:37:59PM +0200, Hans-Joerg Hoexer wrote:
> > On Mon, Aug 13, 2007 at 01:30:11AM +0300, Sergey Prysiazhnyi wrote:
> > > ike dynamic from any to any \
> > > main auth  hmac-sha1 enc aes group modp1024 \
> > >   quick auth hmac-sha1 enc aes psk secret
> > > 
> > > ; ike passive, ike passive esp, ike esp, etc - no results.
> > 
> > On the openbsd gateway you need something like this
> > 
> > ike passive from any to 10.1.1.0/24 \
> > main auth hmac-sha1 enc 3des group modp1024 \
> > quick auth hmac-sha1 enc 3des psk secret
> > 
> > The default transform of the greenbowclient for phase 1 is
> > 3des/sha1/modp1024, for phase 1 3des/sha1.
> 
> Thank you Hans-Joerg, but it is still useless for me: :( 
> 
> sudo cat /etc/ipsec.conf
> ike passive from any to 10.1.1.0/24 \
> main auth hmac-sha1 enc 3des group modp1024 \
>   quick auth hmac-sha1 enc 3des psk secret
> 
> pf.conf rules relative to ipsec:
> 
> set skip on { lo enc0 }
> 
> pass in on $ext_if proto udp to ($ext_if) port { 500, 4500 }
> pass out on $ext_if proto udp from ($ext_if) to port { 500, 4500 }
> pass in on $ext_if proto esp to ($ext_if)
> pass out on $ext_if proto esp from ($ext_if)
> pass in on enc0 proto ipencap to ($ext_if) keep state (if-bound)
> pass out on enc0 proto ipencap from ($ext_if) keep state (if-bound)
> 
> further:
> 
> isakmpd -dKv &
> ipsecctl -F
> ipsecctl -f /etc/ipsec.conf
> 
> greenbowclient: all parameters are in accordance with ipsec.conf on gateway 
> side:
> 
> logs on gw - 
> 
> 023255.538907 Default isakmpd: phase 1 done: initiator id c0a80321: 
> 192.168.3.33, responder id 5851eaa2: 88.81.XX.XX, src: 88.81.XX.XX dst: 
> 77.123.XX.XX
> 023255.558498 Default responder_recv_HASH_SA_NONCE: peer proposed invalid 
> phase 2 IDs: initiator id c0a80321: 192.168.3.33, responder id 
> 0a010100/ff00: 10.1.1.0/255.255.255.0
> 023255.558643 Default dropped message from 77.123.XX.XX port 60056 due to 
> notification type NO_PROPOSAL_CHOSEN
> 023302.570472 Default responder_recv_HASH_SA_NONCE: peer proposed invalid 
> phase 2 IDs: initiator id c0a80321: 192.168.3.33, responder id 
> 0a010100/ff00: 10.1.1.0/255.255.255.0
> 023302.570660 Default dropped message from 77.123.XX.XX port 60056 due to 
> notification type NO_PROPOSAL_CHOSEN
> 
> greenbowclient logs - 
> 
> 20070816 023245 Default IKE daemon is removing SAs...
> 20070816 023250 Default Reinitializing IKE daemon
> 20070816 023250 Default IKE daemon reinitialized 
> 20070816 023258 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode  [SA] [VID] 
> [VID] [VID] [VID]
> 20070816 023258 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode  [SA] [VID] 
> [VID] [VID] [VID] [VID]
> 20070816 023258 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode  [KEY_EXCH] 
> [NONCE] [NAT_D] [NAT_D]
> 20070816 023258 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode  [KEY_EXCH] 
> [NONCE] [NAT_D] [NAT_D]
> 20070816 023258 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode  [HASH] [ID]
> 20070816 023258 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode  [HASH] [ID] 
> [NOTIFY]
> 20070816 023258 Default phase 1 done: initiator id 192.168.3.33, responder id 
> 88.81.234.162
> 20070816 023258 Default (SA CnxVpn1-CnxVpn1-P2) SEND phase 2 Quick Mode  
> [HASH] [SA] [NONCE] [ID] [ID]
> 20070816 023258 Default (SA CnxVpn1-P1) RECV Informational  [HASH] [NOTIFY] 
> with NO_PROPOSAL_CHOSEN error
> 20070816 023305 Default (SA CnxVpn1-CnxVpn1-P2) SEND phase 2 Quick Mode  
> [HASH] [SA] [NONCE] [ID] [ID]
> 20070816 023305 Default (SA CnxVpn1-P1) RECV Informational  [HASH] [NOTIFY] 
> with NO_PROPOSAL_CHOSEN error
> 20070816 023328 Default (SA CnxVpn1-P1) SEND Informational  [HASH] [NOTIFY] 
> type DPD_R_U_THERE
> 20070816 023328 Default (SA CnxVpn1-P1) RECV Informational  [HASH] [NOTIFY] 
> type DPD_R_U_THERE_ACK
> 
> PS: gw on 4.1-stable, roaming users behind OpenBSD box on 4.2.
> 
> My continued thanks,
> 
> -- 
> Sergey Prysiazhnyi

Re: ipsec vpn?

[Hans Hoexer]

And I should mention, that in the "any to any" case you can not use -K and
you have to specify an isakmpd.policy file.

On Wed, Aug 15, 2007 at 10:37:59PM +0200, Hans-Joerg Hoexer wrote:
> On Mon, Aug 13, 2007 at 01:30:11AM +0300, Sergey Prysiazhnyi wrote:
> > ike dynamic from any to any \
> > main auth  hmac-sha1 enc aes group modp1024 \
> > quick auth hmac-sha1 enc aes psk secret
> > 
> > ; ike passive, ike passive esp, ike esp, etc - no results.
> 
> On the openbsd gateway you need something like this
> 
> ike passive from any to 10.1.1.0/24 \
>   main auth hmac-sha1 enc 3des group modp1024 \
>   quick auth hmac-sha1 enc 3des psk secret
> 
> The default transform of the greenbowclient for phase 1 is
> 3des/sha1/modp1024, for phase 1 3des/sha1.

Re: ipsec vpn?

[Hans-Joerg Hoexer]

On Mon, Aug 13, 2007 at 01:30:11AM +0300, Sergey Prysiazhnyi wrote:
> ike dynamic from any to any \
> main auth  hmac-sha1 enc aes group modp1024 \
>   quick auth hmac-sha1 enc aes psk secret
> 
> ; ike passive, ike passive esp, ike esp, etc - no results.

On the openbsd gateway you need something like this

ike passive from any to 10.1.1.0/24 \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des psk secret

The default transform of the greenbowclient for phase 1 is
3des/sha1/modp1024, for phase 1 3des/sha1.

Re: VPN Connection from 4.1 to WatchGuard

[Hans-Joerg Hoexer]

On Thu, Aug 09, 2007 at 02:22:31AM +0200, James Lepthien wrote:
> Hi,
>
> I have set  up a vpn from my OpenBSD Box (4.1-current) to our company 
> WatchGuard X700. My problem is that the re-keying
> isn't always working and my tunnel does not come up if I send traffic to 
> the destination network. I must manually
> restart the isakmpd and then start the tunnel by using ipsecctl -f 
> /etc/ipsec.conf. I see some strange errors in my /var/log/messages
> even when the tunnel is up. What do these errors mean?:
>
> Aug  9 01:52:40 voldemort isakmpd[20491]: attribute_unacceptable: 
> ENCRYPTION_ALGORITHM: got 3DES_CBC, expected AES_CBC
>
...
>
> My ipsec.conf looks like this:
>
> ike esp from $ext_IP to $peer_GW
> ike esp from $ext_IP to $peer_LAN peer $peer_GW
> ike esp from $int_LAN to $peer_LAN \
>   peer $peer_GW \
>   main auth hmac-sha1 enc 3des group modp1024 \
>   quick auth hmac-sha1 enc 3des group none \
>   psk ""

this enables 3des/sha1/modp1024 only for the third rule.  The first and
second rule will both use the default values (aes/sha1/modp1024 for phase
1 and aes/sha2-256 for phase 2).

try this:

ike esp from $ext_IP to $peer_GW \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group none \
  psk ""
ike esp from $ext_IP to $peer_LAN peer $peer_GW \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group none \
  psk ""
ike esp from $int_LAN to $peer_LAN peer $peer_GW \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group none \
  psk ""

Re: isakmpd active mode and phase 1 build-up

[Hans-Joerg Hoexer]

On Thu, Aug 02, 2007 at 10:23:59PM +0200, Sven Ulland wrote:
>
> I'm very (that's putting it mildly) interested in the issues with 4.0
> that you mention. Would you be able to shed some more light on which
> issues they were, or point me to references? It would be most
> interesting.

I'm not sure, but I think there was an issued caused by that [1] commit
which we backed out some time later [2].  This means it should be fixed in
4.0, however, it is obviously not.  I'll try to reproduce this.

Cheers,
HJ.

[1] 
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin//isakmpd/sa.c?rev=1.104&content-type=text/x-cvsweb-markup
[2] 
http://www.openbsd.org/cgi-bin/cvsweb/src/sbin//isakmpd/sa.c?rev=1.109&content-type=text/x-cvsweb-markup

Re: isakmpd active mode and phase 1 build-up

[Hans-Joerg Hoexer]

Hi,

On Thu, Aug 02, 2007 at 09:23:59PM +0200, Sven Ulland wrote:
> I am running OpenBSD 4.0 on amd64, and I'm seeing that isakmpd builds
> up a large amount of redundant phase 1 tunnels for one of our peers.
> It will only report these when prompted with 'echo r > \
> isakmpd.fifo', it's not shown in 'ipsecctl -s all'. This is causing
> one of our peer VPN endpoints to run out of available tunnel resources
> and drop packets. I am running two OpenBSD 4.0 VPN boxes in a
> redundant setup with carp and sasyncd.
>
> isakmpd in OpenBSD 4.0 is by default started with the -S flag, that
> the manual says "will not delete SAs on shutdown by sending delete
> messages to all peers", suitable for carp/sasyncd setups. What it
> doesn't say, however, is that it also enables ui_daemon_passive.
> According to isakmpd(8) in CURRENT: "In passive mode no packets are
> sent to peers." Active/passive mode is not documented in 4.0 manpages,
> but the functionality is there.

In a sasyncd/carp setup isamkpd is started in a passive mode using -S.  On
the machine that is carp master, sasyncd triggers isakmpd to start
negotiations.  On the backup machine, isamkpd stays in passive mode an
does nothing.

However, this should be done by the controling sasyncd only.  This
commands are not meant to be used by the user.  Therefore I guess we
decided to not document this in the man pgae...

> I was having recurrent problems with tunnels not being established.
> Our isakmpd just sat there, not wanting to establish tunnels where our
> end is set to be active in isakmpd.conf. It mostly ignored incoming
> tunnel requests from peers (connection entries configured as passive
> in isakmpd.conf) as well.

Is this after a fresh reboot or after restart sasync/isakmpd by hand?

> Upon looking at the source, it was clear that 'echo M active > \
> isakmpd.fifo' disables ui_daemon_passive (i.e. makes it active). This
> is also mentioned in CURRENT's isakmpd(8). Enabling this caused all
> our tunnels to suddenly establish and there was much rejoicing.
>
> Now after a while, I saw that isakmpd might have become a little bit
> *too* active. I should only be having one phase 1 tunnel to each peer,
> but there has been set up around 470 (varies; I've seen 960 at worst)
> phase 1 tunnels to one peer in particular. I can't remember anything
> other than that it runs Cisco. I can dig up more info if it helps.
>
> The following is gathered from /var/log/daemon after doing an 'echo \
> r > isakmpd.fifo'. Excerpt:
>
>  sa_report: 0x47b4d800 TMUK phase 1 doi 1 flags 0xb
>  sa_report: icookie 1fe44ce55975a07f rcookie 876ef79120c13acc
>  sa_report: msgid  refcnt 3
>  sa_report: life secs 28800 kb 0
>  sa_report: suite 1 proto 1
>  sa_report: spi_sz[0] 0 spi[0] 0x0 spi_sz[1] 0 spi[1] 0x0
>  sa_report: initiator id: 81f0402: 129.240.64.2, \
> responder id: d562735: 213.98.7.53, \
> src: 129.240.64.2 dst: 213.98.7.53
>
> There are 470 of these right now. They all have different 0x
> identifiers and different {i,r}cookie. Other than that, they are
> identical.
>
> They are also listed in the {udp_encap,transport}_report. Example:
>
>  transport_report: transport 0x45a30200 flags 0 refcnt 1
>  udp_report: fd 9 src 129.240.64.2:500 dst 213.98.7.53:500
>
> Except for the 0x ID, they are identical. refcnt is always 1,
> and fd is 9 on all of them.
>
> Now, this leads to two questions:
> 1) Is there something strange or wrong with the active/passive setting
> on 4.0? I mean, since isakmpd is started default in passive mode and
> -S and 'echo M {active,passive} > isakmpd.fifo' is not documented in
> the man pages. -S is, but it doesn't mention active/passive mode
> directly.

M {active, passive} is meant to be issued by sasyncd only.

> 2) What could cause the massive phase 1 build-up I'm seeing? I'll be
> starting the debug process now, and I'll post back if I can find
> anything relevant.

could you please try to upgrade to 4.1-stable?  If I remember correctly,
there were some issues with 4.0.

Thanks,
HJ.

Re: IPSec Keylifetime using ipsecctl and ipsec.conf?

[Hans-Joerg Hoexer]

Hi,

On Thu, Jul 26, 2007 at 10:04:31AM +0200, [EMAIL PROTECTED] wrote:
> Hi,
> 
> I am using ipsecctl and /etc/ipsec.conf to create an IPSec tunnel to a  
> WatchGuard Firebox X700 in my company. It works fine, but the  
> re-keying always makes some trouble, it does not always work. My  
> question now is, how can I set the keylifetimes for phase 1 and 2 in  
> /etc/ipsec.conf? Is there a way to do this? The manpage does not give  
> any more info...

sorry, you can't.

However, you can use isakmpd.conf to set the default lifetimes.  Please
see isakmpd.conf(5) for details.

isakmpd.conf:
[General]
Default-phase-1-lifetime=   3600,60:86400
Default-phase-2-lifetime=   1200,60:86400

> 
> I am running an OpenBSD 4.1 current. My ipsec.conf file looks like this:
> 
> ike esp from 10.240.1.0/24 to 192.168.128.0/24 \
>   peer 1.2.3.4 \
>   main auth hmac-sha1 enc 3des group modp1024 \
>   quick auth hmac-sha1 enc 3des group none \
>   psk ""
> 
> Regards,
> James

Re: Use certificate subjec/ASN1 t in ipsec.conf ?

[Hans-Joerg Hoexer]

Hi,

the Subject Alternative Name of your certificate will be used as phase 2
IDs, ie. that's what is sent.  If you want to use the Subject Canonical
Name, you have to additionlly provide an isakmpd.policy file and you have
to run isakmpd without the "-K" option.  See isakpmd.policy(5).

On Fri, Jul 20, 2007 at 07:09:18PM +0200, Markus Wernig wrote:
> Hi all
> 
> I'm setting up a OBSD 4.1 ipsec gateway, against which users will 
> authenticate using x509 certificates. They all use personal certificates 
> (key usage: digSig), which contains their user name and Email in the 
> subject. I need to authenticate them by the whole subject, but can't 
> seem to find out how.
> 
> I can authenticate them (i.e. it works) if I just use the email address 
> from the certificate as a filter in ipsec.conf along the lines:
> 
> ike passive esp tunnel from any to 192.168.0/24 srcid gate.my.domain 
> dstid [EMAIL PROTECTED]
> ike passive esp tunnel from 192.168.0/24 to any srcid gate.my.domain 
> dstid [EMAIL PROTECTED]
> 
> But what I need would look something like:
> 
> ike passive esp tunnel from any to 192.168.0/24 srcid gate.my.domain 
> dstid "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org"
> ike passive esp tunnel from 192.168.0/24 to any srcid gate.my.domain 
> dstid "/C=CH/CN=John Doe/[EMAIL PROTECTED]/O=My Org"
> 
> When I configure this, with all possible variations of quoting and 
> backslashes, isakmpd tells me in the log file:
> 
> Jul 20 18:52:15 gate isakmpd[8707]: ipsec_validate_id_information: 
> dubious ID information accepted
> Jul 20 18:52:15 gate isakmpd[8707]: ike_phase_1_recv_ID: received remote 
> ID other than expected /C=CH/CN=John
> 
> Apropos the subjectAltName: openssl tells me about the certificate:
> 
> [...]
> X509v3 Subject Alternative Name:
> email:[EMAIL PROTECTED]
> [...]
> 
> Is there a way to see what is getting sent? isakmpd does not seem to 
> like the spaces in the /CN, is there a way to quote this for him?
> Is this possible at all?
> 
> thx for any hint
> 
> /markus

Re: ipsec vpn with os x clients

[Hans-Joerg Hoexer]

Hi,

On Thu, Jul 12, 2007 at 05:38:47PM -0800, eric wrote:
> I have an OpenBSD 4.1 (OpenBSD  4.1 GENERIC#1435 i386) acting  
> as a PPPoE NAT router & firewall to my ISP. I'd like to replace my OS  
> X 10.4 Server IPSEC VPN with the OpenBSD system. My "road warrior"  
> clients are all OS X 10.4.10. I read that 10.4 supports AES  
> encryption but advertises 3DES by default. I'm happy to use 3DES for  
> now, as isakmpd reported proposal errors when i configured for AES.
> 
> Much of the (excellent) IPsec documentation refers either to site-to- 
> site configuration and not road warrior clients or is outdated and  
> refers to isakmpd.conf
> 
> # cat ipsec.conf
> ike dynamic from any to any \
>  main auth hmac-sha1 enc 3des group modp1024 \
>  quick auth hmac-sha1 enc 3des psk TheSecret
> 

this should be "ike passive from ..."

> I start isakmpd with 'isakmpd -K4dv'
> 
> I load ipsec.conf with 'ipsecctl -f /etc/ipsec.conf'
> 
> I then monitor key exchanges with 'ipsecctl -m'
> 
> Once i load ipsec.conf I get the following from isakmpd, repeating  
> every 25secs or so:
> 171653.48 Default udp_create: no address configured for "peer- 
> default"
> 171653.422357 Default exchange_establish: transport "udp" for peer  
> "peer-default" could not be created
> 
> I'm testing this entirely from my internal subnet. PF is configured  
> to 'pass quick on { $int_if enc0 }'
> 
> My OS X VPN client setup includes the OpenBSD server's IP, my OpenBSD  
> username and password, and the PSK. I click Connect.
> 
> isakmpd reports:
> 172358.016652 Default isakmpd: phase 1 done: initiator id ac1e0114:  
> 172.30.1.20, responder id , src: 172.30.1.1 dst:  
> 172.30.1.20
> 172430.679924 Default message_recv: invalid cookie(s)  
> bacca5c8db12e3b9 78c4c4508b02cbe4
> 172430.680286 Default dropped message from 172.30.1.20 port 500 due  
> to notification type INVALID_COOKIE
> 172430.680826 Default message_recv: invalid cookie(s)  
> bacca5c8db12e3b9 a162b17df4ce9921
> 172430.681041 Default dropped message from 172.30.1.20 port 500 due  
> to notification type INVALID_COOKIE
> 
> The INVALID_COOKIE messages repeat until the Mac gives up or I  
> cancel. Then I get:
> 
> 172450.699914 Default transport_send_messages: giving up on exchange  
> IPsec-0.0.0.0/0-0.0.0.0/0, no response from peer 172.30.1.20:500
> 172450.700387 Default transport_send_messages: giving up on exchange  
> IPsec-::/0-::/0, no response from peer 172.30.1.20:500
> 
> ipsecctl -m reports this:
> 
> sadb_getspi: satype esp vers 2 len 10 seq 1 pid 15108
> address_src: 172.30.1.20
> address_dst: 172.30.1.1
> spirange: min 0x0100 max 0x
> sadb_getspi: satype esp vers 2 len 10 seq 1 pid 15108
> sa: spi 0x272f2a24 auth none enc none
> state mature replay 0 flags 0
> address_src: 172.30.1.20
> address_dst: 172.30.1.1
> sadb_getspi: satype esp vers 2 len 10 seq 2 pid 15108
> address_src: 172.30.1.20
> address_dst: 172.30.1.1
> spirange: min 0x0100 max 0x
> sadb_getspi: satype esp vers 2 len 10 seq 2 pid 15108
> sa: spi 0xee7e7297 auth none enc none
> state mature replay 0 flags 0
> address_src: 172.30.1.20
> address_dst: 172.30.1.1
> 
> Does anybody have any documentation on using Mac clients with IPSEC?
> 
> I sincerely appreciate any assistance and am willing to provide any  
> additional requested information. Thank you.

Highpoint RocketRAID 1740.

[Hans Almqvist]

Hi all!!

I have got hold of a "Highpoint RocketRAID 1740" SATA disk controller.
Is there anyone out there thats got a driver for it?

/Hasse

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: isakmpd on OpenBSD 3.7 and OpenBSD 4.0

[Hans-Joerg Hoexer]

Hi,

please check the errata page for 3.7 [1], patch 6 solves this issue [2].

[1] http://www.openbsd.org/errata37.html.
[2] ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.7/common/006_nat-t.patch

HJ.

On Mon, Jun 25, 2007 at 11:35:19AM -0400, catalin visinescu wrote:
> Hello,
>
>   I see that OpenBSD 3.7 isakmpd and OpenBSD 4.0 isakmpd do not establish 
> security associations. I get an INVALID-PAYLOAD-TYPE message. isakmpd 3.7 
> does not seem to understand payload RESERVED.
>
>   Is there a way I can run isakmpd 4.0 downgraded or any other way to get the 
> two of them to work together?
>
>   Thank you,
> ./catalin
> 
>
> -
> Ask a question on any topic and get answers from real people. Go to Yahoo! 
> Answers. 

Re: Specifying > 1 encryption algorithm in ipsec.conf(5) versus isakmpd.conf(5)

[Hans-Joerg Hoexer]

On Mon, May 28, 2007 at 07:02:39PM +0930, Damon McMahon wrote:
> Greetings,
> 
> How would I specify that blowfish, AES and 3DES should be accepted -  
> in that order - in ipsec.conf(5) to configure isakmpd(8)?

this is not supported by ipsec.conf(5).

> 
> In the deprecated isakmpd.conf(5) for Main Mode I did this:
> 
>   Transforms = BLF-SHA,AES-SHA,3DES-SHA
> 
> and for Quick Mode I did this:
> 
>   Suites = QM-ESP-BLF-SHA-PFS-SUITE,QM-ESP-AES-SHA-PFS-SUITE,QM- 
> ESP-3DES-SHA-PFS-SUITE
> 
> However, in ipsec.conf(5) the following results in a Syntax Error  
> message for lines 2 and 3:
> 
>   ike from $ipsec_from to $ipsec_to \
>   main enc { blowfish, aes, 3des } \
>   quick enc { blowfish, aes, 3des }
> 
> Any advice will be appreciated.
> 
> Kind regards,
> Damon

Re: couple of questions

[Hans Hoexer]

yes, that's possible.  See brconfig(8) for instructions.

On Sun, May 06, 2007 at 10:07:42PM +0200, Joachim Schipper wrote:
> On Sun, May 06, 2007 at 02:56:14PM -0400, Paolo Supino wrote:
...
> > 2. I have another project where I'm expanding a network to an adjacent 
> > building and I can't run cables between the building so I will be 
> > setting up a wifi connection between the 2 buildings. I intend to use 
> > OpenBSD on both ends of the wifi link. The network in the new building 
> > will only have 3 computer and has to be on the same Ethernet segment as 
> > the original network. Is it possible to tunnel Ethernet frames over an 
> > IPSEC tunnel in OpenBSD?

Re: isakmpd multiple tunnels

[Hans-Joerg Hoexer]

On Mon, Apr 16, 2007 at 10:59:41AM -0600, Tim Pushor wrote:
> Thanks for the response.
> 
> I should have been more clear. I am using isakmpd.conf and want to 
> support multiple tunnels. Am I able to just add additional tunnels/lines 
> under the [Phase 1] block that points to another relevant ISPEC 
> configuration?

yes.

> 
> Anyone?
> 
> Thanks,
> Tim
> 
> Hans-Joerg Hoexer wrote:
> >On Thu, Apr 12, 2007 at 11:25:49AM -0600, Tim Pushor wrote:
> >  
> >>Hi friends,
> >>
> >>I'm looking to add another IPSEC connection to my openbsd 3.9 firewall. 
> >>All examples I've seen are a single connection (phase 1). To support 
> >>multiple vpn's tunnels, is it as simple as adding additional lines under 
> >>[Phase 1] pointing to the new phase1 configuration block?
> >>
> >
> >yes.  However, please take a look at ipsecctl(8) and ipsec.conf(5).
> >
> >HJ.

Re: host to host ipsec link

[Hans-Joerg Hoexer]

On Sun, Apr 15, 2007 at 05:26:11PM +0200, Markus Wernig wrote:
> 
> /etc/rc.conf.local
> ipsec=YES
> isakmpd_flags="-K -f /var/run/isakmpd.fifo"

why the -f ...?  isakmpd takes care of the fifo itself.  You only need
"-K", nothing else.

Re: isakmpd multiple tunnels

[Hans-Joerg Hoexer]

On Thu, Apr 12, 2007 at 11:25:49AM -0600, Tim Pushor wrote:
> Hi friends,
> 
> I'm looking to add another IPSEC connection to my openbsd 3.9 firewall. 
> All examples I've seen are a single connection (phase 1). To support 
> multiple vpn's tunnels, is it as simple as adding additional lines under 
> [Phase 1] pointing to the new phase1 configuration block?

yes.  However, please take a look at ipsecctl(8) and ipsec.conf(5).

HJ.

Re: IPSec help..

[Hans-Joerg Hoexer]

On Wed, Apr 11, 2007 at 01:28:28PM -0600, Roy Kim wrote:
> I'm trying to setup an ipsec tunnel between an openbsd and a windows
> box using X.509 certificates. Phase 1 gets successfully negotiated but
> then things crap out at step 1 of phase 2 and I don't have a clue
> what's wrong. Any thoughts?
> 
> Isakmpd debug messages just after phase 1 is negotiated and ipsec.conf
> are as follows:
> 
> ipsec.conf:
> ike dynamic esp tunnel from 192.168.0/8 to any \
>  srcid home dstid work
> ike dynamic esp tunnel from any to 192.168.0/8 \
>  srcid work dstid home

you only need one of these two rules as ipsecctl will create
automatically the correct pairs of SAs and flows.  See ipsec.conf(5) for
details.


> 
> isakmpd output using 'isakmpd -KvdD A=50'
> 191751.046228 Timr 10 timer_add_event: event
> exchange_free_aux(0x7df9b500) added before sa_soft_expire(0x85229200),
> expiration in 120s
> 191751.047319 Exch 10 exchange_establish_p2: 0x7df9b500   policy> policy initiator phase 2 doi 1 exchange 5 step 0
> 191751.049266 Exch 10 exchange_establish_p2: icookie 395faa725fd4c3b3
> rcookie 8e784c12cb6b04bd
> 191751.050294 Exch 10 exchange_establish_p2: msgid 47ef99ad sa_list
> 191751.052677 Cryp 50 crypto_init_iv: initialized IV:
> 191751.054075 Cryp 50 033b6e99 5e66c7ba 8efd5d22 8ffe8567
> 191751.055068 Cryp 30 crypto_encrypt: before encryption:
> 191751.057166 Cryp 30 0b18 68790ed1 9f0d6417 66838f05 de3393d7
> 9ec6dcb3 0020 0001
> 191751.058368 Cryp 30 01108d28 395faa72 5fd4c3b3 8e784c12 cb6b04bd
> 3340  
> 191751.060004 Cryp 30 crypto_encrypt: after encryption:
> 191751.061996 Cryp 30 bb6cda82 ec0c809f eac5e496 3102dffb 726b62a3
> 9f0d19e6 624ee717 c65f1486
> 191751.063409 Cryp 30 a35e8fb2 c9a6b8c8 2d03723f 7d6d0c68 909c42ea
> 0bf57a7f d8c817ce 070b8719
> 191751.064686 Cryp 50 crypto_update_iv: updated IV:
> 191751.066224 Cryp 50 909c42ea 0bf57a7f d8c817ce 070b8719
> 191751.068932 Exch 40 exchange_run: exchange 0x7df9b500 finished step
> 0, advancing...
> 191751.069968 Timr 10 timer_add_event: event
> dpd_check_event(0x85229200) added before
> connection_checker(0x8522a060), expiration in 5s
> 191751.07 Exch 10 exchange_finalize: 0x7df9b500   policy> policy initiator phase 2 doi 1 exchange 5 step 1
> 191751.073402 Exch 10 exchange_finalize: icookie 395faa725fd4c3b3
> rcookie 8e784c12cb6b04bd
> 191751.074675 Exch 10 exchange_finalize: msgid 47ef99ad sa_list
> 191751.076166 Timr 10 timer_remove_event: removing event
> exchange_free_aux(0x7df9b500)
> 191751.077610 Mesg 20 message_free: freeing 0x7df9e000
> 191756.083274 Timr 10 timer_handle_expirations: event
> dpd_check_event(0x85229200)
> 191756.084314 Mesg 10 dpd_check_event: peer not responding, retry 2 of 5

Re: isakmpd, conflict using multiple rules w/o peer address

[Hans Hoexer]

Hi,

On Fri, Feb 23, 2007 at 12:09:27AM +, Stuart Henderson wrote:
> 
> @0 C set [Phase 1]:Default=peer-default force
> C set [peer-default]:Phase=1 force
> C set [peer-default]:Authentication=2 force
> C set [peer-default]:Configuration=mm-default force
> C set [peer-default]:ID=me.mylan.net-ID force
> C set [peer-default]:Remote-ID=default-ID force
> C set [default-ID]:ID-type=FQDN force
> C set [default-ID]:Name=net.100 force
> 
> @1 C set [Phase 1]:Default=peer-default force
> C set [peer-default]:Phase=1 force
> C set [peer-default]:Authentication=3 force
> C set [peer-default]:Configuration=mm-default force
> C set [peer-default]:ID=me.mylan.net-ID force
> C set [peer-default]:Remote-ID=default-ID force
> C set [default-ID]:ID-type=FQDN force
> C set [default-ID]:Name=net.101 force
> 
> obviously having the same names, the first is overwritten by the second.
> 
> Would I be totally going down the wrong route if I were to change
> the hardcoded -default and default- section names in ipsecctl/ike.c
> to something based on dstid?

yes.  There is only one "catch-all" entry for peers where the IP
address is not know, the "[Phase 1]:Default=peer-default" (see
isakmpd.conf(5)).

Therefore, it is not possible to have multiple main mode IDs,
transforms, etc. when the peer is not specified.  Thus, ipsecctl
just overwrites the IDs, transforms, etc.  I agree, this is somewhat
sloppy and will be fixed (ie. ipsecctl will fail parsing the config
file).

BTW, your example (peer not specified, multiple PSKs) does not work
in main mode at all (per design).  For such setups you'll have to
use aggressive mode, which is not recommended (please see the caveats
section of isamkpd.conf(5)).

Just use RSA keys:

ike passive esp from 10.1.10.0/24 to 10.1.44.100/24 \
quick auth hmac-sha1 enc aes group grp2 \
srcid me.mylan.net dstid net.100

ike passive esp from 10.1.10.0/24 to 10.1.44.101/24 \
quick auth hmac-sha1 enc aes group grp2 \
srcid me.mylan.net dstid net.101

HJ.

PS:  If you have to use aggressive mode, please hang on, we're
 working on some other diff that will be needed for that.

Re: ipsecctl setting up multiple SAs

[Hans-Joerg Hoexer]

more correct diff:

Index: ike.c
===
RCS file: /cvs/src/sbin/ipsecctl/ike.c,v
retrieving revision 1.54
diff -u -p -r1.54 ike.c
--- ike.c   24 Nov 2006 08:07:18 -  1.54
+++ ike.c   24 Nov 2006 10:46:19 -
@@ -38,17 +38,18 @@ static void ike_section_peer(struct ipse
 static voidike_section_ids(struct ipsec_addr_wrap *, struct ipsec_auth *,
FILE *, u_int8_t);
 static int ike_get_id_type(char *);
-static voidike_section_ipsec(struct ipsec_addr_wrap *, struct
-   ipsec_addr_wrap *, struct ipsec_addr_wrap *, FILE *);
+static voidike_section_ipsec(struct ipsec_addr_wrap *, u_int16_t, struct
+   ipsec_addr_wrap *, u_int16_t, struct ipsec_addr_wrap *,
+   char *, FILE *);
 static int ike_section_p1(struct ipsec_addr_wrap *, struct
ipsec_transforms *, FILE *, struct ike_auth *, u_int8_t);
-static int ike_section_p2(struct ipsec_addr_wrap *, struct
-   ipsec_addr_wrap *, u_int8_t, u_int8_t, struct
+static int ike_section_p2(struct ipsec_addr_wrap *, u_int16_t, struct
+   ipsec_addr_wrap *, u_int16_t, u_int8_t, u_int8_t, struct
ipsec_transforms *, FILE *, u_int8_t);
 static voidike_section_p2ids(u_int8_t, struct ipsec_addr_wrap *,
u_int16_t, struct ipsec_addr_wrap *, u_int16_t, FILE *);
-static int ike_connect(u_int8_t, struct ipsec_addr_wrap *, struct
-   ipsec_addr_wrap *, FILE *);
+static int ike_connect(u_int8_t, struct ipsec_addr_wrap *, u_int16_t,
+   struct ipsec_addr_wrap *, u_int16_t, FILE *);
 static int ike_gen_config(struct ipsec_rule *, FILE *);
 static int ike_delete_config(struct ipsec_rule *, FILE *);
 
@@ -174,33 +175,45 @@ ike_get_id_type(char *string)
 }
 
 static void
-ike_section_ipsec(struct ipsec_addr_wrap *src, struct ipsec_addr_wrap *dst,
-struct ipsec_addr_wrap *peer, FILE *fd)
+ike_section_ipsec(struct ipsec_addr_wrap *src, u_int16_t sport,
+struct ipsec_addr_wrap *dst, u_int16_t dport, struct ipsec_addr_wrap *peer,
+char *tag, FILE *fd)
 {
-   fprintf(fd, SET "[IPsec-%s-%s]:Phase=2 force\n", src->name, dst->name);
+   char*p;
+
+   if (asprintf(&p, "%s:%d-%s:%d", src->name, ntohs(sport), dst->name,
+   ntohs(dport)) == -1)
+   err(1, "ike_section_ipsec");
+
+   fprintf(fd, SET "[IPsec-%s]:Phase=2 force\n", p);
 
if (peer)
-   fprintf(fd, SET "[IPsec-%s-%s]:ISAKMP-peer=peer-%s force\n",
-   src->name, dst->name, peer->name);
+   fprintf(fd, SET "[IPsec-%s]:ISAKMP-peer=peer-%s force\n", p,
+   peer->name);
else
fprintf(fd, SET
-   "[IPsec-%s-%s]:ISAKMP-peer=peer-default force\n",
-   src->name, dst->name);
+   "[IPsec-%s]:ISAKMP-peer=peer-default force\n", p);
 
-   fprintf(fd, SET "[IPsec-%s-%s]:Configuration=qm-%s-%s force\n",
-   src->name, dst->name, src->name, dst->name);
-   fprintf(fd, SET "[IPsec-%s-%s]:Local-ID=lid-%s force\n", src->name,
-   dst->name, src->name);
-   fprintf(fd, SET "[IPsec-%s-%s]:Remote-ID=rid-%s force\n", src->name,
-   dst->name, dst->name);
+   fprintf(fd, SET "[IPsec-%s]:Configuration=qm-%s force\n", p, p);
+   fprintf(fd, SET "[IPsec-%s]:Local-ID=lid-%s force\n", p, src->name);
+   fprintf(fd, SET "[IPsec-%s]:Remote-ID=rid-%s force\n", p, dst->name);
+
+   if (tag)
+   fprintf(fd, SET "[IPsec-%s]:PF-Tag=%s force\n", p, tag);
+
+   free(p);
 }
 
 static int
-ike_section_p2(struct ipsec_addr_wrap *src, struct ipsec_addr_wrap *dst,
-u_int8_t satype, u_int8_t tmode, struct ipsec_transforms *qmxfs, FILE *fd,
-u_int8_t ike_exch)
-{
-   char *tag, *exchange_type, *sprefix;
+ike_section_p2(struct ipsec_addr_wrap *src, u_int16_t sport,
+struct ipsec_addr_wrap *dst, u_int16_t dport, u_int8_t satype,
+u_int8_t tmode, struct ipsec_transforms *qmxfs, FILE *fd, u_int8_t 
ike_exch)
+{
+   char*p, *tag, *exchange_type, *sprefix;
+
+   if (asprintf(&p, "%s:%d-%s:%d", src->name, ntohs(sport), dst->name,
+   ntohs(dport)) == -1)
+   err(1, "ike_section_p2");
 
switch (ike_exch) {
case IKE_QM:
@@ -213,10 +226,9 @@ ike_section_p2(struct ipsec_addr_wrap *s
return (-1);
}
 
-   fprintf(fd, SET "[%s-%s-%s]:EXCHANGE_TYPE=%s force\n",
-   tag, src->name, dst->name, exchange_type);
-   fprintf(fd, SET "[%s-%s-%s]:Suites=%s-", tag, src->name,
-   dst->name, sprefix);
+   fprintf(fd, SET "[%s-%s]:EXCHANGE_TYPE=%s force\n", tag, p,
+   exchange_type);
+   fprintf(fd, SET "[%s-%s]:Suites=%s-", tag, p, sprefix);
 
switch (satype) {
case IPSEC_ESP:
@@ -339,6 +354,8 @@ ike_sectio

Re: ipsecctl setting up multiple SAs

[Hans-Joerg Hoexer]

Hi,

On Fri, Nov 24, 2006 at 09:45:45AM +, Brian Candler wrote:
> I'm trying to set up multiple transport mode SAs between an OpenBSD 4.0 box
> and a Cisco 7301 running IOS [ultimate reason is to load test multiple L2TP
> over IPSEC tunnels].
> 
> Each SA is between the same two IP endpoints but specifies a different UDP
> port pair.
> 
> I was able to get a single SA up using ipsecctl, after making this small fix:
> 
> --- sbin/ipsecctl/ike.c.origThu Nov 23 22:48:23 2006
> +++ sbin/ipsecctl/ike.c Thu Nov 23 22:48:37 2006
> @@ -526,7 +526,7 @@
> fprintf(fd, SET "[lid-%s]:Port=%d force\n", src->name,
> ntohs(sport));
> if (dport)
> -   fprintf(fd, SET "[rid-%s]:Port=%d force\n", src->name,
> +   fprintf(fd, SET "[rid-%s]:Port=%d force\n", dst->name,
> ntohs(dport));
>  }

this has been already commited, thanks!

Could you please try the diff below?  It's just a quick hack but
might solve that problem.

HJ.

Index: ike.c
===
RCS file: /cvs/src/sbin/ipsecctl/ike.c,v
retrieving revision 1.54
diff -u -p -r1.54 ike.c
--- ike.c   24 Nov 2006 08:07:18 -  1.54
+++ ike.c   24 Nov 2006 10:28:33 -
@@ -38,12 +38,13 @@ static void ike_section_peer(struct ipse
 static voidike_section_ids(struct ipsec_addr_wrap *, struct ipsec_auth *,
FILE *, u_int8_t);
 static int ike_get_id_type(char *);
-static voidike_section_ipsec(struct ipsec_addr_wrap *, struct
-   ipsec_addr_wrap *, struct ipsec_addr_wrap *, FILE *);
+static voidike_section_ipsec(struct ipsec_addr_wrap *, u_int16_t, struct
+   ipsec_addr_wrap *, u_int16_t, struct ipsec_addr_wrap *,
+   char *, FILE *);
 static int ike_section_p1(struct ipsec_addr_wrap *, struct
ipsec_transforms *, FILE *, struct ike_auth *, u_int8_t);
-static int ike_section_p2(struct ipsec_addr_wrap *, struct
-   ipsec_addr_wrap *, u_int8_t, u_int8_t, struct
+static int ike_section_p2(struct ipsec_addr_wrap *, u_int16_t, struct
+   ipsec_addr_wrap *, u_int16_t, u_int8_t, u_int8_t, struct
ipsec_transforms *, FILE *, u_int8_t);
 static voidike_section_p2ids(u_int8_t, struct ipsec_addr_wrap *,
u_int16_t, struct ipsec_addr_wrap *, u_int16_t, FILE *);
@@ -174,33 +175,45 @@ ike_get_id_type(char *string)
 }
 
 static void
-ike_section_ipsec(struct ipsec_addr_wrap *src, struct ipsec_addr_wrap *dst,
-struct ipsec_addr_wrap *peer, FILE *fd)
+ike_section_ipsec(struct ipsec_addr_wrap *src, u_int16_t sport,
+struct ipsec_addr_wrap *dst, u_int16_t dport, struct ipsec_addr_wrap *peer,
+char *tag, FILE *fd)
 {
-   fprintf(fd, SET "[IPsec-%s-%s]:Phase=2 force\n", src->name, dst->name);
+   char*p;
+
+   if (asprintf(&p, "%s:%d-%s:%d", src->name, ntohs(sport), dst->name,
+   ntohs(dport)) == -1)
+   err(1, "ike_section_ipsec");
+
+   fprintf(fd, SET "[IPsec-%s]:Phase=2 force\n", p);
 
if (peer)
-   fprintf(fd, SET "[IPsec-%s-%s]:ISAKMP-peer=peer-%s force\n",
-   src->name, dst->name, peer->name);
+   fprintf(fd, SET "[IPsec-%s]:ISAKMP-peer=peer-%s force\n", p,
+   peer->name);
else
fprintf(fd, SET
-   "[IPsec-%s-%s]:ISAKMP-peer=peer-default force\n",
-   src->name, dst->name);
+   "[IPsec-%s]:ISAKMP-peer=peer-default force\n", p);
+
+   fprintf(fd, SET "[IPsec-%s]:Configuration=qm-%s force\n", p, p);
+   fprintf(fd, SET "[IPsec-%s]:Local-ID=lid-%s force\n", p, src->name);
+   fprintf(fd, SET "[IPsec-%s]:Remote-ID=rid-%s force\n", p, dst->name);
 
-   fprintf(fd, SET "[IPsec-%s-%s]:Configuration=qm-%s-%s force\n",
-   src->name, dst->name, src->name, dst->name);
-   fprintf(fd, SET "[IPsec-%s-%s]:Local-ID=lid-%s force\n", src->name,
-   dst->name, src->name);
-   fprintf(fd, SET "[IPsec-%s-%s]:Remote-ID=rid-%s force\n", src->name,
-   dst->name, dst->name);
+   if (tag)
+   fprintf(fd, SET "[IPsec-%s]:PF-Tag=%s force\n", p, tag);
+
+   free(p);
 }
 
 static int
-ike_section_p2(struct ipsec_addr_wrap *src, struct ipsec_addr_wrap *dst,
-u_int8_t satype, u_int8_t tmode, struct ipsec_transforms *qmxfs, FILE *fd,
-u_int8_t ike_exch)
+ike_section_p2(struct ipsec_addr_wrap *src, u_int16_t sport,
+struct ipsec_addr_wrap *dst, u_int16_t dport, u_int8_t satype,
+u_int8_t tmode, struct ipsec_transforms *qmxfs, FILE *fd, u_int8_t 
ike_exch)
 {
-   char *tag, *exchange_type, *sprefix;
+   char*p, *tag, *exchange_type, *sprefix;
+
+   if (asprintf(&p, "%s:%d-%s:%d", src->name, ntohs(sport), dst->name,
+   ntohs(dport)) == -1)
+   err(1, "ike_section_p2");
 

Re: Can't build VPN with ipsecctl

[Hans-Joerg Hoexer]

your tunnel is between 193.189.180.192/28 and 193.189.180.208/28

On Thu, Nov 23, 2006 at 01:10:13PM +0100, Mitja wrote:
> ...
> OpenBSD1
> # ipsecctl -s all
> FLOWS:
> flow esp in from 193.189.180.208/28 to 193.189.180.192/28 peer
> 172.16.16.6 type require
> flow esp out from 193.189.180.192/28 to 193.189.180.208/28 peer
> 172.16.16.6 type require
> 
> ...
>
> Let's debug this on OpenBSD2:
> # tcpdump -i bge0 icmp
> tcpdump: listening on bge0, link-type EN10MB
> 12:52:34.600017 172.16.16.6 > 193.189.180.193: icmp: echo request
> 12:52:34.600443 172.16.16.5 > 172.16.16.6: icmp: net 193.189.180.193
> unreachable
> 12:52:35.610009 172.16.16.6 > 193.189.180.193: icmp: echo request
> 12:52:35.610386 172.16.16.5 > 172.16.16.6: icmp: net 193.189.180.193
> unreachable
> 12:52:36.620010 172.16.16.6 > 193.189.180.193: icmp: echo request
> 12:52:36.620332 172.16.16.5 > 172.16.16.6: icmp: net 193.189.180.193
> unreachable

however, you're icmps source address is 172.16.16.6, thus it does
_not_ go through the tunnel.  Use ping -I to set the source address
to the interface into the 193.189.180.xxx network.

Re: Wild card greytrapping setup in spamdb

[Hans Kremers]

Daniel Ouellet wrote:



So, I would like to trapit everything that is not from these 5 emails.



Beware that people make mistakes. Someone could just make a
typing error in one of these 5 addresses and you end up blocking
a legitimate mail server..

H.

Re: VPN interoperability problem with Symantec Enterprise Firewall

[Hans-Joerg Hoexer]

Hi,

could you please provide a pcap of such an exchange?
Thanks,
HJ.

On Wed, Oct 18, 2006 at 11:57:53AM +0200, Mitja Mu?eni? wrote:
> 
> Just a quick question if anybody has had the same problem, or contrary, if
> anybody has a success story with SEF. I'm trying to establish an IPsec
> tunnel between OpenBSD 3.9 and Symantec Enterprise Firewall 7.0.4 (NT/2k)
> which is not under my control.
> 
> The negotiation goes through normally, but immediately afterwards the remote
> end sends a "DELETE" notification. The tunnel is still up on OpenBSD's end,
> but no traffic ever reaches the destination.
> 
> The remote end (Symantec) spits out (obfuscated to protect the innocent):
> 
> "VPN packet dropped (213.aaa.bbb.ccc->217.ddd.eee.fff: Protocol=IPSEC-ESP
> spi=0xa0723686): Received IPCOMP packet on a tunnel that was not configured
> for compression (tunnel [EMAIL PROTECTED] )"
> 
> 
> This error message is funny because as far as I know, OpenBSD does not
> support IPCOMP in automatic IKE through isakmpd. Any idea why Symantec would
> believe that we are sending it IPCOMP traffic?
> 
> 
> I even checked that net.inet.ipcomp.enable=0 - not that I know if it's
> applicable to IPsec at all. I suspect this is a bug in SEF, but can't find
> anything on google or mailing list archives. Nothing special in my
> isakmpd.conf, I have multiple tunnels working to other vendors' VPN peers.
> 
> 
> Regards,
> 
> Mitja

Re: ipsecctl parser behavior on OpenBSD 4.0 running generic kernel#1137

[Hans-Joerg Hoexer]

Hi,

On Wed, Oct 11, 2006 at 02:17:42PM -0700, Prabhu Gurumurthy wrote:
> 
> pgurumur-vm-openbsd (OpenBSD): [~/working/networking/docs]
> 10.200.0.46: [579]$ cat ipsec.conf
> remote_gw = "192.168.0.1"
> remote_net = "{ 10.0.100.0/22, 10.0.2/24 }"
> local_net = "{ 172.16.18.0/26 }
> 
> ike esp from $local_net to $remote_net peer $remote_gw psk "test123"
> pgurumur-vm-openbsd (OpenBSD): [~/working/networking/docs]
> 10.200.0.46: [580]$ ipsecctl -n -f ipsec.conf
> pgurumur-vm-openbsd (OpenBSD): [~/working/networking/docs]
> 10.200.0.46: [581]$ echo $?
> 0
> 
> *Is this expected? I am missing a ending quote on line three and the parser 
> thinks this is correct*

the problem here is, that local_net will turn out to be defined as:

local_net = "{ 172.16.18.0/26 }ike esp from $local_net to $remote_net peer 
$remote_gw psk  test123""

I'll fix this.

Thanks!
HJ.

Re: IPSec roadwarrior configuration?

[Hans-Joerg Hoexer]

On Thu, Oct 12, 2006 at 10:07:27AM +0200, viq wrote:
>...
> Now, there are two caveats to this I didn't yet figure out how to solve.
> 1) VPN-B must be able to resolve vpn-b.my.domain to the address of
> it's egress interface, otherwise the traffic won't get encapsulated.
> Right now I was doing that by editing /etc/hosts by hand, but there
> must be a better way... (hmm, by dhclient-script ? Or maybe is there a
> way to reference "self" in ipsec.conf ?)

use the "egress" interface group name:

ike dynamic esp from egress to any peer vpn-a.my.domain srcid ...

Re: Spamassassin install from ports fail.

[Hans Almqvist]

Woodchuck skrev:

On Wed, 27 Sep 2006, Hans Almqvist wrote:

  

Hi all!

I am trying to install Spamassaassin from the ports  tree on an OpenBSD 3.9
system.

I have removed /usr/ports an downloaded a fresh copy starting from scratch.
I did one prior run with make which of course gave the same result.

I get the fallowing:  *Error in package*:


# cd /usr/ports/mail/p5-Mail-SpamAssassin/
# make
===>  p5-Mail-SpamAssassin-3.1.0p0 depends on: p5-IO-Socket-SSL-* - not found
===>  Verifying install for p5-IO-Socket-SSL-* in security/p5-IO-Socket-SSL
===>  Checking files for p5-IO-Socket-SSL-0.97
`/usr/ports/distfiles/IO-Socket-SSL-0.97.tar.gz' is up to date.


Checksum OK for IO-Socket-SSL-0.97.tar.gz. (sha1)


===>  p5-IO-Socket-SSL-0.97 depends on: p5-Net-SSLeay->=1.21 - not found
===>  Verifying install for p5-Net-SSLeay->=1.21 in security/p5-Net_SSLeay
===>  Building package for p5-Net-SSLeay-1.25p0
*Error in package*:



  

does not exist
===>  Cleaning for p5-Net-SSLeay-1.25p0
rm -f /usr/ports/packages/i386/all/p5-Net-SSLeay-1.25p0.tgz
*** Error code 1



Hmmm.  Works for me.  Just rebuilt the p5-Net-SSLeay-1.25p0 package
from source.

My source:

MD5 (/usr/ports/distfiles/Net_SSLeay.pm-1.25.tar.gz) = 
	87de8a06802fbb63c7c85e89eedbe139


Try again.  Could you have run out of disk space or had some other
sort of transient error?

Dave


  

Ok. I fetched "p5-Net-SSLeay-1.25p0.tgz" and did a pkg_add.
After that the install proceeded.

Thanks Dave.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Spamassassin install from ports fail.

[Hans Almqvist]

Hi all!

I am trying to install Spamassaassin from the ports  tree on an OpenBSD 
3.9 system.


I have removed /usr/ports an downloaded a fresh copy starting from scratch.
I did one prior run with make which of course gave the same result.

I get the fallowing:  *Error in package*:


# cd /usr/ports/mail/p5-Mail-SpamAssassin/
# make
===>  p5-Mail-SpamAssassin-3.1.0p0 depends on: p5-IO-Socket-SSL-* - not 
found

===>  Verifying install for p5-IO-Socket-SSL-* in security/p5-IO-Socket-SSL
===>  Checking files for p5-IO-Socket-SSL-0.97
`/usr/ports/distfiles/IO-Socket-SSL-0.97.tar.gz' is up to date.
>> Checksum OK for IO-Socket-SSL-0.97.tar.gz. (sha1)
===>  p5-IO-Socket-SSL-0.97 depends on: p5-Net-SSLeay->=1.21 - not found
===>  Verifying install for p5-Net-SSLeay->=1.21 in security/p5-Net_SSLeay
===>  Building package for p5-Net-SSLeay-1.25p0
*Error in package*: 
"/usr/ports/security/p5-Net_SSLeay/w-p5-Net-SSLeay-1.25p0/fake-i386//usr/local/man/man3p/Net::SSLeay::Handle.3p" 
does not exist

===>  Cleaning for p5-Net-SSLeay-1.25p0
rm -f /usr/ports/packages/i386/all/p5-Net-SSLeay-1.25p0.tgz
*** Error code 1

Stop in /usr/ports/security/p5-Net_SSLeay (line 2075 of 
/usr/ports/infrastructure/mk/bsd.port.mk).*** Error code 1


Stop in /usr/ports/security/p5-Net_SSLeay (line 1308 of 
/usr/ports/infrastructure/mk/bsd.port.mk).*** Error code 1


Stop in /usr/ports/security/p5-IO-Socket-SSL (line 1422 of 
/usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1


Stop in /usr/ports/security/p5-IO-Socket-SSL (line 1750 of 
/usr/ports/infrastructure/mk/bsd.port.mk).*** Error code 1


Stop in /usr/ports/mail/p5-Mail-SpamAssassin (line 1422 of 
/usr/ports/infrastructure/mk/bsd.port.mk).




# ls 
/usr/ports/security/p5-Net_SSLeay/w-p5-Net-SSLeay-1.25p0/fake-i386//usr/local/man/man3p

Net::SSLeay.3p

There is no "Net::SSLeay::Handle.3p" in that directory as written by the 
error message. Just "Net::SSLeay.3p".


Any clue?

/Hasse


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Rotate many Apache logfiles

[Hans van Leeuwen]

On Friday 15 September 2006 14:57, you wrote:
> Hi!
>
> What is the preferred way of rotating Apache's logfiles?
>
> I have many virtual domains, each with its own access and error logfile.
> I'm using CustomLog, not TransferLog.  Apache is chrooted.
>
> Adding every logfile to /etc/newsyslog.conf is one way, but hard to
> maintain.  Is Apache's own rotatelogs program the way to go?

I prefer to use cronolog.
It's in ports.


Hans

Re: mbuf leak with rl

[Hans van Leeuwen]

On Thursday 14 September 2006 17:38, you wrote:
> Is anyone using a Realtek 8139 card with OpenBSD 3.9?  I noticed that mbufs
> will slowly leak when using it.  I noticed this after switching to 3.9.  I
> don't know if something happened to the card or not... maybe there is a
> hardware error now that is making it behave funky.
>
> If you're using a "rl*" can you take a look at your mbuf usage (netstat
> -m)? Me and another person both see something similar.

237 mbufs in use:
135 mbufs allocated to data
66 mbufs allocated to packet headers
36 mbufs allocated to socket names and addresses
125/380/6144 mbuf clusters in use (current/peak/max)
856 Kbytes allocated to network (36% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

I have no idea if this is good or not.


> dmesg:
> rl0 at pci0 dev 8 function 0 "Realtek 8139" rev 0x10: irq 11, address
> 00:48:54:65:39:5a
> rlphy0 at rl0 phy 0: RTL internal PHY

rl0 at pci1 dev 10 function 0 "Realtek 8139" rev 0x10: irq 11, address 
00:10:a7:0b:16:ed
rlphy0 at rl0 phy 0: RTL internal PHY


Greetings,


Hans

Re: IKE Phase-II fails -> GETSPI: Operation not supported

[Hans-Joerg Hoexer]

please provide all information.

On Tue, Sep 05, 2006 at 02:50:12PM -0400, John Ruff wrote:
> I'm trying implement a IPSec/VPN tunnel and phase-II of the IKE  
> negotiation is failing with the following errors seen from 'isakmpd - 
> dKL -D A=90':
> 
> 110340.763012 Default pf_key_v2_get_spi: GETSPI: Operation not supported
> 110340.763362 Default initiator_send_HASH_SA_NONCE: doi->get_spi failed
> 110340.763933 Default exchange_run: doi->initiator (0x86aa2380) failed
> 
> This occurs after Phase-II proposals have been accepted.  The other  
> peer is functioning fine, I have other tunnels to it from Cisco PIXs  
> and FreeBSD (raccon) boxes.  Should this be reported as a bug?
> 
> I'm running:
> 
> 4.0-current (GENERIC #1103) - x86
> 
> Thanks.

Re: IPsec Configuration Questions

[Hans-Joerg Hoexer]

what ipsec software is running on the clients?  What does your
ipsec.conf on the firewall look like?

On Sat, Sep 02, 2006 at 04:01:51PM -0400, Axton Grams wrote:
> Hoping someone can point me in the right direction to get isakmpd working.
> 
> The scenario:
> - the router drops all traffic directed to it from the dmz net
> - the router drops all traffic destined for the lan from the dmz
> - the router drops all traffic destined for the dmz from the lan
> - vlan1 (dmz) has linux hosts
> - vlan2 (lan) has windows and linux hosts, for the purpose of this
> exercise, I am using a windows host
> 
> The goals:
> - create a way by which hosts in the lan can connect to the dmz network
> using ipsec/isakmpd
> - starting off with simple auth, shared secret passphrase
> 
> The problem:
> - I am unable to establish a SA between the router and the lan hosts
>   isakmpd returns the following:
> 155359.461787 Default message_recv: cleartext phase 2 message
> 155359.462366 Default dropped message from 10.107.208.20 port 500 due to
> notification type INVALID_FLAGS
> 
> Some background Info:
> 
> My network is as follows:
> (trunking is next on my list, but for now, I have separate interfaces on
> the router for each vlan)
> 
> |
> Internet (dynamic ip)
> |1.1.1.2
>++
>|   router/fw/isakmpd|
>++
> 10.180.16.1 | |10.107.208.1
>dmz  | |  lan
>++ ++
>|   |
> +-+
> |   switch|
> |  vlan1   |  vlan2   |
> +-+
>||
>||
> +---+ +---+
> | www server| |   workstation 1   +
> | 10.180.16.250 | |   10.107.208.20   +
> +---+ +---+
> 
> - OpenBSD Router:
> - relavent ifconfig
> ** internet
> hme0:
> flags=8b63
> mtu 1500
> lladdr xxx
> groups: egress
> media: Ethernet 100baseTX full-duplex
> status: active
> inet6 xxx%hme0 prefixlen 64 scopeid 0x2
> inet 1.1.1.2 netmask 0xe000 broadcast 1.1.1.255
> ** lan
> hme1:
> flags=8363
> mtu 1500
> lladdr 08:00:20:ca:7d:c5
> media: Ethernet 100baseTX
> status: active
> inet 10.107.208.1 netmask 0xff00 broadcast 10.107.208.255
> inet6 fe80::a00:20ff:feca:7dc5%hme1 prefixlen 64 scopeid 0x3
> ** dmz
> hme2:
> flags=8b63
> mtu 1500
> lladdr 08:00:20:ca:7d:c6
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 10.180.16.1 netmask 0xff00 broadcast 10.180.16.255
> inet6 fe80::a00:20ff:feca:7dc6%hme2 prefixlen 64 scopeid 0x4
> 
> # cat isakmpd.policy
> KeyNote-Version: 2
> Authorizer: "POLICY"
> Licensees: "passphrase:foobar"
> Conditions: app_domain == "IPsec policy" &&
> esp_present == "yes" &&
> esp_enc_alg == "3des" &&
> esp_auth_alg == "hmac-md5" -> "true";
> 
> # isakmpd -d -4 -DA=10
> 155358.773509 Default log_debug_cmd: log level changed from 0 to 10 for
> class 0 [priv]
> 155358.775093 Default log_debug_cmd: log level changed from 0 to 10 for
> class 1 [priv]
> 155358.775757 Default log_debug_cmd: log level changed from 0 to 10 for
> class 2 [priv]
> 155358.776153 Default log_debug_cmd: log level changed from 0 to 10 for
> class 3 [priv]
> 155358.776672 Default log_debug_cmd: log level changed from 0 to 10 for
> class 4 [priv]
> 155358.777056 Default log_debug_cmd: log level changed from 0 to 10 for
> class 5 [priv]
> 155358.777524 Default log_debug_cmd: log level changed from 0 to 10 for
> class 6 [priv]
> 155358.777914 Default log_debug_cmd: log level changed from 0 to 10 for
> class 7 [priv]
> 155358.778416 Default log_debug_cmd: log level changed from 0 to 10 for
> class 8 [priv]
> 155358.778794 Default log_debug_cmd: log level changed from 0 to 10 for
> class 9 [priv]
> 155358.779267 Default log_debug_cmd: log level changed from 0 to 10 for
> class 10 [priv]
> 155358.788915 Misc 10 monitor_init: privileges dropped for child process
> 155359.444597 Timr 10 timer_add_event: event
> connection_checker(0x4fe41420) added last, expiration in 0s
> 155359.451947 Timr 10 timer_handle_expirations: event
> connection_checker(0x4fe41420)
> 155359.452947 Timr 10 timer_add_event: event
> connection_checker(0x4fe41420) added last, expiration in 60s
> 155359.453857 Timr 10 timer_add_event: event
> exchange_free_aux(0x44908c00) added last, expiration in 120s
> 155359.454632 Exch 10 exchange_establish_p1: 0x44908c00 ISAKMP-peer-west
> Default-phase-1-configuration policy initiator phase 1 doi 1 exchange 2
> step 0
> 155359.455323 Exch 10 exchange_establish_p1: icookie 4d18594e523695f1
> rcookie 
> 155359.455748 Exch 10 exchange_establish_p1: msgid 
> 155359.457524 Timr 10 ti

Re: How to mail attachments from the comand line?

[Hans Zimmerman]

On Wed, 30 Aug 2006 20:08:44 +0100
Gaby Vanhegan <[EMAIL PROTECTED]> wrote:

> On 30 Aug 2006, at 19:51, Torsten Geile wrote:
> 
> > mail -a file -s "test" recepient >.
> >
> > would do it, but actually in my case it doesn't.
> 
> I think you have to send it in base64 encoded form, with a few added  
> headers.  What's simpler would be to put it in some publicly  
> accessible place (like a website) and send the URL to the file rather  
> than the file itself.
> 
> Gaby
> 
> --
> Junkets for bunterish lickspittles since 1998!
> http://www.playr.co.uk/sudoku/
> http://weblog.vanhegan.net/
> 
> 

man uuencode
it's in the examples.


Kind regards,

Hans

Re: sasyncd and ISAKMP SA

[Hans-Joerg Hoexer]

On Tue, Aug 08, 2006 at 08:23:39PM +0200, Floroiu, John Williams wrote:
> 
> does sasyncd enable the IPsec failover gateways to also share the ISAKMP SA
> (so that DPD exchanges can proceed despite failures)? the ISAKMP SA is not
> explicitly mentioned in the help page (and is actually distinct from the IPsec
> SAs).

no, it doesn't.
HJ.

ccd harddisk error?

[Hans van Leeuwen]

Hello misc,


I run a server with two harddiscs running as a software RAID1 using ccd.
Yesterday I started to import a large database in PostgreSQL, and found allot 
of these errors in my logs:

error reading: Processor VRM
 error code: ae
 error code: ae
kcs_sendmsg: 18 22
bmc_io_wait fails : v=88 m=03 b=01 read_data
kcs_sendmsg: 10 27 b8
 error code: ae
 error code: ae
kcs_sendmsg: 18 22
bmc_io_wait fails : v=88 m=03 b=01 read_data
 error code: ae
 error code: ae
kcs_sendmsg: 18 22
bmc_io_wait fails : v=88 m=03 b=01 read_data
 error code: ae
 error code: ae
kcs_sendmsg: 18 22
bmc_io_wait fails : v=88 m=03 b=01 read_data


I'm guessing that one of the disks is broken, but how can I found out which 
one? And is the data still stored correctly, or does this mean the database 
will be corrupt?

Below you will (hopefully) find all relevant information.


Thanks,


Hans



[EMAIL PROTECTED]:~] cat /etc/fstab
/dev/wd0a / ffs rw 1 1
/dev/wd1a /altroot ffs xx 0 0
/dev/ccd0a /home ffs rw,nodev,nosuid 1 2
/dev/ccd0b /usr ffs rw,nodev 1 2
/dev/ccd0d /var ffs rw,nosuid 1 2


[EMAIL PROTECTED]:~] cat /etc/ccd.conf
#   $OpenBSD: ccd.conf,v 1.1 1996/08/24 20:52:22 deraadt Exp $
# Configuration file for concatenated disk devices
#
# ccd   ileave  flags   component devices
#ccd0   16  none/dev/sd2e /dev/sd3e
ccd016  CCDF_MIRROR /dev/wd0d   /dev/wd1d


[EMAIL PROTECTED]:~] cat /var/run/dmesg.boot
OpenBSD 3.9 (GENERIC) #617: Thu Mar  2 02:26:48 MST 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) III CPU family 1266MHz ("GenuineIntel" 686-class) 
1.27 GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem  = 536166400 (523600K)
avail mem = 48080 (470920K)
using 4278 buffers containing 26910720 bytes (26280K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 10/18/01, BIOS32 rev. 0 @ 0xfda54
pcibios0 at bios0: rev 2.1 @ 0xf/0x1
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf3bb0/240 (13 entries)
pcibios0: PCI Interrupt Router at 000:15:0 ("ServerWorks CSB5" rev 0x00)
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x8800 0xd0800/0x1800 0xd2000/0x1800
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca2/2 spacing 1 irq 0
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "ServerWorks CNB20HE Host" rev 0x23
pci1 at pchb0 bus 1
pchb1 at pci0 dev 0 function 1 "ServerWorks CNB20HE Host" rev 0x01
pchb2 at pci0 dev 0 function 2 "ServerWorks CNB20HE Host" rev 0x01
pchb3 at pci0 dev 0 function 3 "ServerWorks CNB20HE Host" rev 0x01
pci2 at pchb3 bus 2
pciide0 at pci0 dev 2 function 0 "Promise PDC20267" rev 0x02: DMA, channel 0 
configured to native-PCI, channel 1 configured to native-PCI
pciide0: using irq 11 for native-PCI interrupt
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA, 38166MB, 78165360 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5
wd1 at pciide0 channel 1 drive 1: 
wd1: 16-sector PIO, LBA, 38166MB, 78165360 sectors
wd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 5
fxp0 at pci0 dev 3 function 0 "Intel 8255x" rev 0x0d, i82550: irq 9, address 
00:03:47:bd:45:47
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
fxp1 at pci0 dev 4 function 0 "Intel 8255x" rev 0x0d, i82550: irq 5, address 
00:03:47:bd:45:48
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
vga1 at pci0 dev 12 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
piixpm0 at pci0 dev 15 function 0 "ServerWorks CSB5" rev 0x92
iic0 at piixpm0: disabled to avoid ipmi0 interactions
pciide1 at pci0 dev 15 function 1 "ServerWorks CSB5 IDE" rev 0x92: DMA
atapiscsi0 at pciide1 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  SCSI0 5/cdrom 
removable
cd0(pciide1:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2
ohci0 at pci0 dev 15 function 2 "ServerWorks OSB4/CSB5 USB" rev 0x05: irq 10, 
version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: ServerWorks OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 4 ports with 4 removable, self powered
pchb4 at pci0 dev 15 function 3 "ServerWorks CSB5 LPC" rev 0x00
isa0 at mainbus0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: 
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask fdc5 netmask ffe5 ttymask ffe7
pctr: 68

Re: ipsec.conf syntax error

[Hans-Joerg Hoexer]

Hi,

On Wed, Aug 16, 2006 at 09:46:18AM -0400, Stefan wrote:
> Hans-Joerg Hoexer wrote:
> > this is on -current?
> 
> Sorry, I should have mentioned it. It's 3.9 release.

setting the group was added post 3.9.

Re: ipsec.conf syntax error

[Hans-Joerg Hoexer]

this is on -current?

On Tue, Aug 15, 2006 at 10:46:37PM -0400, Stefan wrote:
> Can someone explain why this is giving a syntax error?
> 
> 
> ike esp from 10.0.0.0/24 to 10.1.0.0/24 peer (remote IP CIDR) \
>  main auth hmac-md5 enc 3des group modp1024 \   
>  quick auth hmac-md5 enc 3des group modp1024 \
>  psk (shared key)
>  
> ike esp from (local IP CIDR) to (remote IP CIDR) \
>  main auth hmac-md5 enc 3des group modp1024 \
>  quick auth hmac-md5 enc 3des group modp1024 \
>  psk (shared key)
> 
> 
> ipsecctl complains about line 2 and 7 starting with main auth. White space
> plays no part nor does splitting up the lines.
> 
> Seems a few others have had problems with ipsecctl and ipsec.conf syntax on
> misc@
> 
> -Stefan

Re: OPENBSD isakmpd VPN Problems

[Hans-Joerg Hoexer]

Hi,

On Thu, Aug 10, 2006 at 12:04:08AM -0400, Steve Glaus wrote:
> ...
> One glaring difference that I can see is that when I connect to the 
> DLINK I use a passive connection and isakpmd sits and listens for 
> incoming connections. Could this be a lifetime issue? Tech support at 
> the other end said this is possible. How do you set the lifetime using 
> ipsecctl (I've read that this is only possible with -current)

this only works in -current:

ike from 1.1.1.1 to 2.2.2.2 main life 3600 quick life 1200

However, this sets the life times for all connections, ie. it's not
possible yet to say "use life time x for this connection and life
time y fort that connection."

For 3.9 you could achive the same with this isakmpd.conf:

# cat /etc/isakmpd.isakmpd.conf
[General]
Default-phase-1-lifetime=   3600
Default-phase-2-lifetime=   1200

> Another item - IS PFS disabled or enabled by default when one uses 
> ipsecctl? Can this be set?

pfs is enabled by default.

> Looking at my logs I'm pretty sure that it's making it through phase1. 

yes, according to isakmpd_out phase 1 has succesfully finished.

> Our vendors phase1 and phase2 use identical encryption/authorization so 
> I don't quite understand why I would be getting NO_PROPOSALS for only 
> phase2. The lifetimes for both phases are also identical on the vendors 
> end.
> 
> 
> This is the relevant configuration info:
> 
> ike esp from 10.110.38.0/24 to 172.28.128/0/21 peer 204.244.106.134 main 
   ^
   typo?
(Looks right in isakmpd_out)

> auth hmac-sha1 enc 3des quick auth hmac-sha1 enc 3des psk "XX"
> 
> The debug outpout can be found here:
> 
> http://ww2.bartowpc.com:8080/isakmpd_out

Please provide the full isakmp configuration of that sonicwall.

Re: IKE DoS - factual?

[Hans-Joerg Hoexer]

On Fri, Jul 28, 2006 at 09:32:09AM -0700, Spruell, Darren-Perot wrote:
> Word is, there is a flaw in IKEv1 that allows for an attacker to create IKE
> sessions faster than previous attempts expire. The security research firm
> who found the flaw only lists Cisco VPN devices as being vulnerable while
> Cisco maintains that the flaw is in the IKE protocol itself.
> 
> Research Firm:
> http://www.nta-monitor.com/posts/2006/07/cisco-concentrator-dos.html
> 
> Cisco's Response:
> http://www.cisco.com/en/US/tech/tk583/tk372/tsd_technology_security_response
> 09186a00806f33d4.html
> 
> I hesitate to trust Cisco's response fully, as the behavior sounds like
> something that to me would be implementation dependent.
> 
> Is it legitimate to fear that this kind of attack could succeed against
> isakmpd(8) or other IKE implementations of other projects, for example? If
> so, what if any controls would be effective in defense?

This is indeed a flaw of the ike protocol and rather old news, see
the article mentioned in isamkpd.conf(8), section CAVEATS.

Regarding dos mitigation, see  http://www.openbsd.org/papers/ikepaper.ps.

Re: VPN help needed: OpenBSD in the corporate environment instead of Linux

[Hans-Joerg Hoexer]

On Fri, Jul 28, 2006 at 03:57:02PM -0400, Steven Surdock wrote:
> Stuart Henderson wrote:
> > On 2006/07/28 06:30, jeraklo wrote:
> >> sorry. got to go with the stable branch (3.9).
> > 
> > disadvantages:-
> > 
> > openvpn is more complicated to install on OpenBSD than ipsec
> > lots of security fixes
> 
> Not on the client side, I think you'll find OpenVPN much easier to
> configure as well.  OpenVPN is trivially easy to install using the
> packages on OBSD.

easier than this?

# cat /etc/ipsec.conf
ike dynamic from egress to my.gate.net
# ls /etc/isakmpd/pubkeys/fqdn/
my.gate.net
# cat /etc/rc.conf.local
...
ipsec=YES
isakmpd_flags="-K"

Re: tcpdump on enc0

[Hans-Joerg Hoexer]

On Wed, Jul 05, 2006 at 11:10:43AM -0600, Stephen Bosch wrote:
> Does tcpdump work on enc0?
> 
> -Stephen-
> 
yes:

<[EMAIL PROTECTED]:1>$ sudo tcpdump -n -i enc0
Password:
tcpdump: WARNING: enc0: no IPv4 address assigned
tcpdump: listening on enc0, link-type ENC
19:32:49.036465 (authentic,confidential): SPI 0x7483bd72: 192.168.3.14.738 >
192.168.3.28.2049: xid 0x93071cba 112 getattr [|nfs]
19:32:49.037284 (authentic,confidential): SPI 0x97ed55a0: 192.168.3.28.2049 >
192.168.3.14.738: xid 0x93071cba reply ok 96 getattr DIR 40755 ids 0/0 sz 512
19:32:49.086492 (authentic,confidential): SPI 0x3beb96bd: 192.168.3.14.671 >
192.168.3.27.2049: xid 0x93071ecc 112 getattr [|nfs]
19:32:49.087405 (authentic,confidential): SPI 0x358880c8: 192.168.3.27.2049 >
192.168.3.14.671: xid 0x93071ecc reply ok 96 getattr DIR 40755 ids 0/0 sz 512
19:32:54.199148 (authentic,confidential): SPI 0x3beb96bd: 192.168.3.14.788 >
192.168.3.27.2049: xid 0x7200 40 null
19:32:54.199847 (authentic,confidential): SPI 0x358880c8: 192.168.3.27.2049 >
192.168.3.14.788: xid 0x7200 reply ok 24 null
^C
6 packets received by filter
0 packets dropped by kernel
<[EMAIL PROTECTED]:2>$

Re: isakmpd is not writing to a specified capture file

[Hans-Joerg Hoexer]

isakmpd is only allowed to write to files in the /var/run directory.
I've updated the manpage accordingly.

On Wed, Jun 28, 2006 at 04:37:16PM -0600, Stephen Bosch wrote:
> Hi:
> 
> Running OpenBSD 3.8, I cannot get isakmpd to write to a capture file.
> 
> Here is my mount output:
> 
> /dev/wd0a on / type ffs (local, noatime)
> mfs:1824 on /tmp type mfs (asynchronous, local, nodev, nosuid, 
> size=24576 512-blocks)
> mfs:16738 on /var type mfs (asynchronous, local, nosuid, size=32768 
> 512-blocks)
> /dev/wd0d on /usr type ffs (local, noatime, nodev, read-only)
> 
> I am invoking isakmpd like so:
> 
> isakmpd -T -v -l /root/isakmp.cap
> 
> Nothing is written, even though IPsec connections are coming up.
> 
> Any ideas?
> 
> -Stephen-

Re: Throughput Problem OpenBSD3.9 soekris 4801 isakmpd

[Hans-Joerg Hoexer]

On Wed, Jun 28, 2006 at 06:38:42PM +0200, Thomas Bvrnert wrote:
> with the vpn1411 crypto card i get only
> 
> 700 - 720 KB/s
> CPU 30%
> 
> by the way the driver of the crypto card is buggy. i have
> a lot of cards here removed in the last year. i got several
> hangs. hans-joerg has no time to fix it.

and i have no clue what's going wrong.

Re: VIA C7 hardware AES support in IPSEC(ctl)

[Hans-Joerg Hoexer]

On Thu, Jun 22, 2006 at 10:22:08AM -0700, Joe wrote:
> Dries Schellekens wrote:
> >Bihlmaier Andreas wrote:
> >
> >>>As I say earlier, the hardware is working, but the performance 
> >>>bottleneck is elsewhere (presumably kernel crypto framework).
> 
> I'm interested in purchasing one of these boards for my vpns. The 
> numbers aren't too bad, but is anyone working on a fix? I don't want to 

we are.

Re: Help in Setting up "Open-ended" VPN connections

[Hans-Joerg Hoexer]

Hi,

On Tue, Jun 13, 2006 at 04:10:08PM -0700, Spruell, Darren-Perot wrote:
> 
> To follow that further, is it currently possible to do this kind of
> road-warrior setup using ipsecctl/ipsec.conf? Doesn't it require aggressive
> mode do to the unknown nature of the peer IP?

since c2k6 it almost is.  There are some minor glitches, so please
hang on a bit.

With public key authentication (or x509) there's no need for
aggressive mode.  Aggressive mode is only needed when PSKs are used.
ipsecctl(8) will not support aggressive mode.  Please see also
isakmpd.conf(5), section CAVEATS.

Promise SATA 300 TX4.

[Hans Almqvist]

Hi all!

Is there anyone out there using this controller successfully with
OpenBSD ?
In other word's : Is it supported by this OS ?

/Hans Almqvist

Re: IPsec / vpn configuration issues

[Hans-Joerg Hoexer]

On Thu, May 04, 2006 at 12:31:28PM -0500, Nathan Johnson wrote:
...
> The problem is when I try to ping any machine from network A to
> 192.168.51.0/24 (gateway B's internal network) besides the gateway
> itsself (192.168.51.1), ping doesn't work.

what does "doesn't" work mean?  Do you see the icmp-echo-request
on the target machine?  Like:  ping from 192.168.0.2 to 192.168.51.2,
does the ping show up at 192.168.51.2?  Does 192.168.51.2 send the
reply?  etc.

Re: Mounting remote filesystems from OpenBSD to OS X

[Hans-Joerg Hoexer]

On Thu, Apr 20, 2006 at 02:11:36PM +0100, Constantine A. Murenin wrote:
> Hi,
> 
> I have an OpenBSD (file-)server at a remote location on the internet
> that is around 137ms away from an OS X 10.4 laptop.
> 
> Is there a way to securely mount OpenBSD's filesystems from OS X in
> such a setting?

consider using ipsec.

Re: OpenBSD to Cisco VPN - help needed

[Hans-Joerg Hoexer]

On Wed, Apr 05, 2006 at 05:13:36PM +1000, Karl Kopp wrote:
> 
> Firstly, I thought I could just use /etc/ipsec.conf (right?) and a
> line like this:
> 
> ike esp from 10.1.1.0/24 to 202.1.1.0/24 peer 202.1.1.30 main auth
> hmac-md5 enc 3des psk shhhSecret

this looks correct.

Additionally to the debug hints damien already gave, please provide
me the pcap fiel generated with "-L" of such an exchange.

HJ.

Re: IPSEC via isakmpd with identical source networks

[Hans-Joerg Hoexer]

On Wed, Apr 05, 2006 at 11:27:03AM +0200, Ingbert Zan wrote:
> 
> Does anybody know how to distinguish between the two flows?

you can't.

> Of course it would be possible to NAT the two 10/8 networks
> on Box 1 and 2.

do that.

Re: security hole in sendmail

[Hans van Leeuwen]

Oliver Peter wrote:


On Thu, Mar 30, 2006 at 05:08:11PM -0700, Peter Valchev wrote:
 


A race condition exists in sendmail's handling of asynchronous signals.
A remote attacker may be able to execute arbitrary source code with the
privileges of the user running sendmail, typically root.
   



Excuse my question - I don't want to attack our loved project but does
that mean that we've got a second remote hole? Don't kick my ass.

 


By default sendmail only listens on the local interface.


Hans

Re: I need some help on frequently failing ipsec tunnel.

[Hans-Joerg Hoexer]

Hi,

On Fri, Mar 31, 2006 at 11:01:03AM +0200, Stefan Sczekalla-Waldschmidt wrote:
> 
> Some days ago one certain vpn-tunnel started failing for an
> unpredictable time of some minutes up to an hour.
> ( mostly just less than 5 minutes). All other site-link-tunnels stay up
> and running.
> 
> a long-term monitoring makes me thinking that there is in any way
> something happen every approx 1800 sec.
> 
> Reviewing the ipsec.conf manpage does not show any default values of
> 1800sec as far as i have noticed.

Lifetimes can not be set yet using ipsec.conf.  You can do this
with a rather simple isakmpd.conf:

<[EMAIL PROTECTED]:22># cat /etc/isakmpd.conf
[General]
Default-phase-1-lifetime=   3600,1800:7200
Default-phase-2-lifetime=   600,450:720

> Whaa Isakmpd-debug-level Options should I set to get a better glue what
> ist happening ?
> 
> All other Ideas/suggestions are welcome !

please show us your configuration.

Re: CRK_MOD_EXP on /dev/crypto

[Hans-Joerg Hoexer]

On Mon, Mar 27, 2006 at 03:37:42AM -0500, Christopher Thorpe wrote:
> dmesg says:
> hifn0 at pci0 dev 14 function 0 "Hifn 7955/7954" rev 0x00: LZS 3DES ARC4 
> MD5 SHA1 RNG AES PK, 32KB dram, irq 11
> 
>   The drivers support modular exponentiation, but I'm having trouble 
> finding documentation or figuring out how to perform it (it's a "key 
> operation") using the interface to /dev/crypto.

the card does, but the driver doesn't, see hifn(4)

Re: certpatch on obsd 3.8

[Hans-Joerg Hoexer]

On Wed, Mar 22, 2006 at 11:30:40PM +0100, Lukas Drbohlav wrote:
> 
> with this in x509v3.cnf
> # default settings
> CERTUFQDN   = "what i have to give there ??!!"

the UFQDN, eg. "[EMAIL PROTECTED]".  Please take a look at isakmpd(8),
where this is explained using FQDN.  UFQDN is similar.

> [x509v3_UFQDN]
> subjectAltName=email:$ENV::CERTUFQDN
> 
> thank you for help
> 
> regards
> 
> lukas 

Re: ipsec.conf manpage

[Hans-Joerg Hoexer]

Hi,

On Tue, Mar 21, 2006 at 07:27:45PM +1100, Rod Whitworth wrote:
> 
> Total mention in the manpage:
>  srcid 
>This optional parameter defines a FQDN that will be used by
>isakmpd(8) as the identity of the local peer.
> 
>  dstid 
>Similar to srcid, this optional parameter defines a FQDN to be used
>by the remote peer.
> 
> Now, how do I use that?

ike esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2 \
srcid my.fqdn.com dstid his.fqdn.com

Re: Spam (solutions) and some other practical issues

[Hans van Leeuwen]

Gabriel George POPA wrote:

  Thank you Joachim. Now, regarding spamd(8), I knew that I need help 
from pf. Regarding SpamAssassin: I did pkg_add, I followed
the instructions on modifying /etc/procmailrc I started spamd (spamc 
should have been called for every message). Nothing happened.

No mail message was scanned.


You have to tell sendmail to pass the message to procmail.
See the part about sendmail.cf in procmail's manpage.


Regarding that sysctl: shouldn't we add it?
 


Thats not how it works here.
Either you write a patch or stop complaining about the lack of features.

Regarding the upgrade: I will build the distribution using this machine 
(3GHz P4, 1GB RAM) - my server is not under heavy load in this

period of the week. I just hoped binpatch could be a better solution.
 

OpenBSD doesn't supply binary patches, and this isn't going to change. 
See the archives for more information.


Good luck,


Hans

Re: ipsecctl and invalid phase 2 IDs

[Hans-Joerg Hoexer]

Can you show me the output of "ipsecctl -nvf ..." on both machines.

HJ.

On Wed, Feb 22, 2006 at 01:08:39PM -0500, Adam wrote:
> I am trying to setup a simple vpn between two networks using ipsecctl.
> One side is running 3.8 release, the other 3.8 stable.  On both sides I
> have copied over /etc/isakmpd/private/local.pub to /etc/isakmpd/pubkeys/
> ipv4/remote.ip.add.ress and run isakmpd -K and then ipsecctl -f /etc/
> ipsec.conf.  The ipsec.conf files look like this:
> 
> ike esp from 172.23.140.0/24 to 172.23.160.0/21 peer 1.1.1.1
> and
> ike esp from 172.23.160.0/21 to 172.23.140.0/24 peer 2.2.2.2
> 
> 1.1.1.1 and 2.2.2.2 are obviously the real external IPs of the two
> gateways.
> 
> In /var/log/daemon I get
> 
> isakmpd[4906]: responder_recv_HASH_SA_NONCE: peer proposed invalid
> phase 2 IDs: initiator id ac17a000/f800:
> 172.23.160.0/255.255.248.0, responder id ac178c00/ff00:
> 172.23.140.0/255.255.255.0
> isakmpd[4906]: dropped message from 1.1.1.1 port 500 due to
> notification type NO_PROPOSAL_CHOSEN
> isakmpd [4906]: transport_send_messages: giving up on exchange
> IPsec-172.23.140.0/24-172.23.160.0/21, no response from peer
> 1.1.1.1:500
> 
> Adam

Re: fatal: evp_crypt: EVP_Cipher failed

[Hans-Joerg Hoexer]

yes, these cards have issues.  The only advice I can give is to set
kern.usercrypto=0.  I tried to debug this several times, but I did
not find a test case that produces this issue reliably.

On Mon, Jan 30, 2006 at 04:46:49PM -0600, Sean Cody wrote:
> I have been having issues lately with the HiFn based crypto cards  
> locking up in 3.7 and 3.8.
> They are usually fine but under some undefined load they lock up and  
> it seems rather random as to when it happens and how much load causes  
> it.
> 
> The cards are used to help out with a VPN between a few far flung  
> machines but they are all i386.
> I've encountered this on two Soekris NET4501's and on a single Athlon  
> machine.
> 
> The only real clue is in the authlog where sshd reports:
> sshd []: fatal: evp_crypt: EVP_Cipher failed
> 
> SSHD and isakmpd are both seeminly locked up but I can get into the  
> machine if I use the blowfish protocol which isn't supported on the  
> HiFn card thereby leading me to think there is a bug in the driver or  
> the card itself where it's not servicing an interrupt or is stuck  
> waiting for an interrupt which will never come.
> 
> The dmesg on the machines have the following line:
> hifn0 at pci0 dev 13 function 0 "Hifn 7955/7954" rev 0x00: LZS 3DES  
> ARC4 MD5 SHA1 RNG AES PK, 32KB dram, irq 9
> 
> As well the cards in question are the VPN1401 (PCI) and VPN1411  
> (MiniPCI).
> Since there is no kernel panic I'm sort of at a loss as to how to  
> track this down better.
> 
> As far as the kernels go, I am using 3.8_GENERIC on the Athlon and a  
> stripped (via flashdist) version of 3.8 on the NET4501's.
> 
> Again these lockups are always under some sort of load over the VPN  
> (VNC, file transfers ) and are for the most part random.
> 
> Does anyone have any suggestions on how to track this down?
> My current solution is just 'ssh somehost -c blowfish reboot' though  
> that is obviously far from optimal.
> 
> -- 
> Sean

Re: Need advice about VPN

[Hans-Joerg Hoexer]

On Wed, Jan 18, 2006 at 11:20:55AM +0100, Joachim Schipper wrote:
> 
> Each will work; OpenVPN is slightly easier to set up, but IPsec will
> likely offer better performance.

Forget about openvpn, there's no need to fiddle around with third
party stuff.

Just make sure to take a look at vpn(8).  If ipsec does not suit
your needs, take a look at tunneling using ssh(1) "-w".

Re: ipsecctl writev failed

[Hans-Joerg Hoexer]

Hi,

On Fri, Dec 23, 2005 at 11:58:14AM -0500, Will H. Backman wrote:
> 
> Reducing the enckey to 160 bits worked.  Interesting to note that if a 
> key is too short, you get a nice warning that the key is too short and 
> must be 160 bits long.  If a key is too long, you don't get a warning, 
> just the less specific errors about writev failed.

ja, ipsecctl just checks the minimum and maximum key sizes.  For
alogrithms with non-fixed keysizes (aes, aesctr, blf) it depends
on the algorithm what actual keysizes are acceptable.  Eg aes you
can have 128, 192 and 256 bits.  For aesctr it's 160 (128+32), 224
(192+32) and 288 (256+32).  I'll add a section to ipsec.conf(5)
about correct values soon and add proper checks to ipsecctl.

HJ.

Re: ipsecctl writev failed

[Hans-Joerg Hoexer]

the defaults are hmac-sha2-256 and aesctr which uses a 160 bit key.

On Wed, Dec 21, 2005 at 03:25:26PM -0500, Will H. Backman wrote:
> OpenBSD 3.8 release.
> I'm getting the same errors as this thread:
> http://archives.neohapsis.com/archives/openbsd/2005-11/1980.html
> I'm trying to use as many defaults as possible in this test setup, and 
> sha1 is not being chosen by the defaults.  Any ideas?
> 
> Here is my ipsec.conf (yes, key values are just for testing):
> flow esp from 192.168.71.129 to 192.168.71.128
> esp from 192.168.71.129 to 192.168.71.128 spi 0x1000:0x1001 authkey 
> 0x:0x0001
>  
> enckey 
> 0x:0x0001
> 
> Here is the output from ipsecctl -vv -f /etc/ipsec.conf:
> @0 flow esp out from 192.168.71.129 to 192.168.71.128 peer 192.168.71.128
>   type require
> @1 flow esp in from 192.168.71.128 to 192.168.71.129 peer 192.168.71.128
>   type use
> @2 esp from 192.168.71.129 to 192.168.71.128 spi 0x1000 auth 
> hmac-sha2-256 enc aesctr
>   authkey 
>   0x
>   enckey 
>   0x
> @3 esp from 192.168.71.128 to 192.168.71.129 spi 0x1001 auth 
> hmac-sha2-256 enc aesctr
>   authkey 
>   0x0001
>   enckey 
>   0x0001
> ipsecctl: writev failed: Invalid argument
> ipsecctl: failed to add rule 2
> ipsecctl: writev failed: Invalid argument
> ipsecctl: failed to add rule 3

Re: VPN in OpenBSD 3.8, how to use new tools?

[Hans-Joerg Hoexer]

On Sun, Dec 18, 2005 at 06:58:22PM +0100, Lukasz Sztachanski wrote:
> ipsecadm(8) isn't new ;) Probably ipsecctl isn't `mature' enough to
> handle such setup. Imho, you'll have to use isakmpd- actually web is
> full of tutorials and examples of isakmpd configurtion; plus, it's very
> flexible and configurable.

what's wrong with vpn(8)?

Re: x509 keys & isakmpd in OBSD 3.8

[Hans-Joerg Hoexer]

Hi,

On Fri, Dec 16, 2005 at 09:48:06AM +, Gordon Ross wrote:
> I'm trying to setup an isakmpd VPN using x509 keys between two OpenBSD
> 3.8 boxes.
> 
> To start with, I followed the instructions at
> http://www.openbsdsupport.org/vpn-ipsec.html to setup an initial VPN
> using pre-shared secrets. This works fine.

well, I'd say vpn(8) is a good starting point...

> Then I create CSR/KEYs for the peers & get the CSR signed by the CA to
> give me a cert. This, in theory, I understand. However:
> 
> 1) The man page for isakmpd says "The CSRs are signed with a
> pre-generated private key.  By default, the system startup script rc(8)
> generates a key-pair when starting..." Why ? Why are the peer CSRs
> signed with the pre-generated private key ? I would have thought that
> getting the CA to sign them would be OK. After all, if all the peers
> trust the CA, then any certificate signed by the CA should be trusted.
> What's wrong with my logic ?

mh, "signed" might a bit unclear.  The pre-generated private key
is "bound" to the CSR, ie. this is the private key to be used with
the resulting x509 certificate.

> 2) Just to confirm... (Assume I have peer1 & peer2) I create a cert for
> peer1 and put it in /etc/isakmpd/certs/ on peer1. There is no need to
> copy it to peer2 (because the cert is signed by the CA, and the CA is
> trusted by both peers) Correct ?

yes.

Re: Apache Log Rotation - FAQ 10.16

[Hans van Leeuwen]

Olivier Mehani wrote:


On Fri, 09 Dec 2005 13:12:14 +0100
Hans van Leeuwen <[EMAIL PROTECTED]> wrote:
 


CustomLog "|/usr/local/sbin/cronolog -l /var/www/logs/access-hanz.nl
/var/www/logs/old/access-hanz.nl.%Y%m%d" combined
   


But you are not using the default chrooted apache, are you ?
 


Yes, I am.
[EMAIL PROTECTED]:~] grep httpd /etc/rc.conf.local
httpd_flags="-DSSL"
   



Hum. I'm puzzled. Did you move some files and change permissions in the
chroot then ?

 


No.
Please tell me what puzzles you...


Hans

Re: Apache Log Rotation - FAQ 10.16

[Hans van Leeuwen]

Olivier Mehani wrote:


On Fri, 09 Dec 2005 11:11:23 +0100
Hans van Leeuwen <[EMAIL PROTECTED]> wrote:
 


Could you please share your preferred methods to rotate the
/var/www/logs/, ?
 


I had the same problem, and solved it by using cronolog.

From my httpd.conf:

CustomLog "|/usr/local/sbin/cronolog -l /var/www/logs/access-hanz.nl
/var/www/logs/old/access-hanz.nl.%Y%m%d" combined
   



But you are not using the default chrooted apache, are you ?

 


Yes, I am.

[EMAIL PROTECTED]:~] grep httpd /etc/rc.conf.local
httpd_flags="-DSSL"


Hans

Re: Apache Log Rotation - FAQ 10.16

[Hans van Leeuwen]

Uwe Dippel wrote:


Could you please share your preferred methods to rotate the
/var/www/logs/, ?
 


I had the same problem, and solved it by using cronolog.
This way you don't have to restart apache.

From my httpd.conf:

CustomLog "|/usr/local/sbin/cronolog -l /var/www/logs/access-hanz.nl
/var/www/logs/old/access-hanz.nl.%Y%m%d" combined


Hans

Re: ipsec question

[Hans-Joerg Hoexer]

yes, you can.  You need to encrypt traffic from/to your laptop to
0.0.0.0/0.  So instead of using your gw address, use 0.0.0.0/0.

HJ.

On Thu, Dec 01, 2005 at 08:00:38AM +0100, raff wrote:
> Hi,
> I have wireless connection between my machine and router/gateway.
> I can set up ipsec connection betwen them if i'm connecting directly to
> gw machine, but is it possible to encrypt traffic between those when i'm
> connecting to internet via gw ?
> 
> host-->gw-->internet
> |   |
> '---|---'
>   ipsec
> 
> thanks in advance.

Re: isakmpd fills my log

[Hans-Joerg Hoexer]

On Wed, Nov 30, 2005 at 03:58:07PM +0100, martin wrote:
...
> [Phase 1]
> 10.10.10.9= ISAKMP-peer-ignition
> 
> [Phase 2]
> Connections=IPsec-ignition-soekris

this should be a passive connection.  Otherwise isakmpd will try
to keep this connection up and when this fails it gets logged.  This
should also happen on 3.7, btw.

> 
> [ISAKMP-peer-ignition]
> Phase=  1
> Transport=  udp
> Local-Address=  10.10.10.10
> Address=10.10.10.9
> Configuration=  Default-main-mode
> Authentication= 2secret2btrue
> 
> [IPsec-ignition-soekris]
> Phase=  2
> ISAKMP-peer=ISAKMP-peer-ignition
> Configuration=  Default-quick-mode
> Local-ID=   Addr-fjuttsi
> Remote-ID=  Addr-laptop
> 
> [Addr-laptop]
> ID-type=IPV4_ADDR
> Address=10.10.10.9
> 
> [Addr-fjuttsi]
> ID-type=IPV4_ADDR
> Address=10.10.10.10
> 
> [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
> 
> 
> ...isakmpd.policy...
> 
> KeyNote-Version: 2
> Comment: This policy accepts ESP SAs from a remote that uses the right 
> password
> Authorizer: "POLICY"
> Licensees: "passphrase:2secret2btrue"
> Conditions: app_domain == "IPsec policy" &&
>esp_present == "yes" &&
>esp_enc_alg == "3des" &&
>esp_auth_alg == "hmac-sha" -> "true";