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

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: 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: 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.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)
> 18:24:12.441476 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp
> v1.0 exchange ID_PROT
> cookie: 7c923ecb8d9a90f0->

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-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.

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: 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: 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: 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: 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: 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.

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.

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: 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: 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: 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";

Re: isakmpd fills my log

[Hans-Joerg Hoexer]

please show us your config files.

On Wed, Nov 30, 2005 at 03:31:27PM +0100, martin wrote:
> hi all, i use ipsec to replace wep for my wlan so the setup is pretty 
> simple and all and everything works. I used this page 
> http://www.dietlein.com/requisites/ipsec/ to get it to work and my 
> configs are the same as in the guide. The problem is since i switched 
> from 3.7 to 3.8 isakmpd fills my /var/log/messages with info that it 
> cant connect when my laptop if off.
> Like below all around the clock.
> How can i stop this the best way ? i start isakmpd in rc.conf with just ""
> 
> best regards martin
> 
> Nov 30 15:15:46 fjuttsi isakmpd[3201]: sendmsg (7, 0xcfbcab20, 0): Host 
> is down
> Nov 30 15:15:55 fjuttsi isakmpd[3201]: sendmsg (7, 0xcfbcab20, 0): Host 
> is down
> Nov 30 15:16:19 fjuttsi isakmpd[3201]: transport_send_messages: giving 
> up on exchange IPsec-ignition-soekris, no response from peer 10.10.10.9:500
> Nov 30 15:18:19 fjuttsi isakmpd[3201]: transport_send_messages: giving 
> up on exchange IPsec-ignition-soekris, no response from peer 10.10.10.9:500
> Nov 30 15:19:46 fjuttsi isakmpd[3201]: sendmsg (7, 0xcfbcab20, 0): Host 
> is down
> Nov 30 15:19:55 fjuttsi isakmpd[3201]: sendmsg (7, 0xcfbcab20, 0): Host 
> is down
> Nov 30 15:20:19 fjuttsi isakmpd[3201]: transport_send_messages: giving 
> up on exchange IPsec-ignition-soekris, no response from peer 10.10.10.9:500

Re: ISAKMPD problem 3.7 <--> 3.8

[Hans-Joerg Hoexer]

make sure to apply all patches for 3.7, see errata37.html.  I've added fix a
few days ago.  Moreover, I need the full out put of -DA=80 to see what's
actually going on.

HJ.

On Tue, Nov 29, 2005 at 01:20:25PM +0100, [EMAIL PROTECTED] wrote:
> Hello!
> 
>I have a problem with ISAKMPD on a new machine running 3.8-RELEASE.
> 
>The machines on the other sides of the tunnels are running
> 3.6-RELEASE and 3.7-RELEASE; they talk to each other just fine.
> 
>But the machine with 3.8 cannot talk to any of the other two
> boxes. 
> 
>Reading in the lists, I saw messages dating a few days ago
> suggesting to run isakmpd with the -T option. Unfortunately, it 
> doesn't seem to work for me. Already cheched and re-wrote the
> config files, just in case.
> 
>I keep getting messages such as 
> Default pf_key_v2_get_spi: GETSPI: Operation not supported
> Default initiator_send_HASH_SA_NONCE: doi->get_spi failed
> 
>Is the -T option supposed to work for 3.6 and 3.7 (both RELEASE)
> or is it only going to work with a 3.7-STABLE?
> 
>I can upgrade the 3.7 machine, but not the 3.6. Anything else
> I can try or shall I just ditch the 3.8 and reinstall 3.7 on my
> new machine as well?
> 
> Many thanks in advance!
> 
> --Rob 

Re: ipsec.conf / What am I dooing wrong?

[Hans-Joerg Hoexer]

A bit more explanation:  Nowadays, HMAC-SHA1/MD5 is used with ESP/AH.
Simple keyed SHA1/MD5 is only used with "old" ESP/AH, which is not
supported by ipsecctl(8).  Thus I'll remove "sha1" from ipsecctl,
sorry for the inconvenience.

HJ.

On Thu, Nov 24, 2005 at 12:01:36PM +0100, Hans-Joerg Hoexer wrote:
> Hi,
> 
> ok, please use "hmac-sha1" instead of "sha1"
> HJ.
> 
> On Thu, Nov 24, 2005 at 11:04:45AM +0100, raff wrote:
> > following ipsec.conf(5) i was trying to set up connection between to
> > hosts 192.168.1.115 and 192.168.1.125
> > I can set it using ipsecadm, and everything works fiine, but using
> > ipsecctl i'm getting some errors like below:
> > 
> > 
> > # ipsecctl -vvf ipsec.conf
> > @0 flow esp out from 192.168.1.115 to 192.168.1.125 peer 192.168.1.125
> > type require
> > @1 flow esp in from 192.168.1.125 to 192.168.1.115 peer 192.168.1.125
> > type use
> > @2 esp from 192.168.1.115 to 192.168.1.125 spi 0x0115 auth sha1 enc
> > 3des-cbc
> > authkey 0x507a89ddbbca07ea595b338f78c9cf44162ef92e
> > enckey 0x9f2d7686ee16363909e94c8334cc8492b53cb8d7d0734e29
> > @3 esp from 192.168.1.125 to 192.168.1.115 spi 0x0125 auth sha1 enc
> > 3des-cbc
> > authkey 0x513dc7a1b41d9a5ad9fca0eedc78180be2a82ba5
> > enckey 0x44c4006f164234375e892d64e8fbc42c6093064fb1aa3bb9
> > ipsecctl: writev failed: Invalid argument
> > ipsecctl: failed to add rule 2
> > ipsecctl: writev failed: Invalid argument
> > ipsecctl: failed to add rule 3
> > 
> > thanks in advance

Re: ipsec.conf / What am I dooing wrong?

[Hans-Joerg Hoexer]

Hi,

ok, please use "hmac-sha1" instead of "sha1"
HJ.

On Thu, Nov 24, 2005 at 11:04:45AM +0100, raff wrote:
> following ipsec.conf(5) i was trying to set up connection between to
> hosts 192.168.1.115 and 192.168.1.125
> I can set it using ipsecadm, and everything works fiine, but using
> ipsecctl i'm getting some errors like below:
> 
> 
> # ipsecctl -vvf ipsec.conf
> @0 flow esp out from 192.168.1.115 to 192.168.1.125 peer 192.168.1.125
> type require
> @1 flow esp in from 192.168.1.125 to 192.168.1.115 peer 192.168.1.125
> type use
> @2 esp from 192.168.1.115 to 192.168.1.125 spi 0x0115 auth sha1 enc
> 3des-cbc
> authkey 0x507a89ddbbca07ea595b338f78c9cf44162ef92e
> enckey 0x9f2d7686ee16363909e94c8334cc8492b53cb8d7d0734e29
> @3 esp from 192.168.1.125 to 192.168.1.115 spi 0x0125 auth sha1 enc
> 3des-cbc
> authkey 0x513dc7a1b41d9a5ad9fca0eedc78180be2a82ba5
> enckey 0x44c4006f164234375e892d64e8fbc42c6093064fb1aa3bb9
> ipsecctl: writev failed: Invalid argument
> ipsecctl: failed to add rule 2
> ipsecctl: writev failed: Invalid argument
> ipsecctl: failed to add rule 3
> 
> thanks in advance

Re: isakmpd fails on sun v100 ( dc nics )

[Hans-Joerg Hoexer]

please apply all patches for 3.7.  I've lately added a patch for
this issue to the 3.7 errata page.

HJ.

On Mon, Nov 21, 2005 at 05:01:28PM -0800, Dag Richards wrote:
> Using the sample config straight from the vpn man page, my tunnel fails 
> to come up between GENERIC 3.8 or 3.7 on a sunfire v100 ( dmesg below ) 
> and GENERIC on an x86 machine. If I run the same config on another  x86 
> machine it works.
> 
> When running `isakmpd  -L` I see checksum errors on the sunfire ( see 
> dump below).
> 
> 
> Is this a problem with the dc driver? I have tried both of the 
> interfaces but to no avail, there are no pci slots for add on cards
> 
> debug output and config files below.
> 
> = tcpdump -nvr  /var/run/isakmpd.pcap==
> 16:37:33.685897 192.168.1.13.500 > 192.168.1.15.500:  [bad udp cksum 
> 1c8e!] isakmp v1.0 exchange ID_PROT
> cookie: 30e6fc2ae5d3ef74-> msgid:  len: 196
> payload: SA len: 88 DOI: 1(IPSEC) situation: IDENTITY_ONLY
> payload: PROPOSAL len: 76 proposal: 1 proto: ISAKMP spisz: 
> 0 xforms: 2
> payload: TRANSFORM len: 32
> transform: 0 ID: ISAKMP
> attribute ENCRYPTION_ALGORITHM = 3DES_CBC
> attribute HASH_ALGORITHM = SHA
> attribute AUTHENTICATION_METHOD = PRE_SHARED
> attribute NONE =
> attribute NONE =
> attribute NONE =
> payload: TRANSFORM len: 0 [|isakmp]
> payload: VENDOR len: 0 [|isakmp] [ttl 0] (id 1, len 224)
> 16:37:40.693965 192.168.1.15.500 > 192.168.1.13.500:  [bad udp cksum 
> 8c9d!] isakmp v1.0 exchange ID_PROT
> cookie: 30e6fc2ae5d3ef74->8cb97ec972120f6e 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 NONE =
> attribute NONE =
> attribute NONE =
> payload: VENDOR len: 0 [|isakmp] [ttl 0] (id 1, len 188)
> 16:37:40.772058 192.168.1.13.500 > 192.168.1.15.500:  [bad udp cksum 
> c4e6!] isakmp v1.0 exchange ID_PROT
> cookie: 30e6fc2ae5d3ef74->8cb97ec972120f6e msgid:  len: 228
> payload: KEY_EXCH len: 132
> payload: NONCE len: 0 [|isakmp] [ttl 0] (id 1, len 256)
> 16:37:40.784674 192.168.1.15.500 > 192.168.1.13.500:  [bad udp cksum 
> bb54!] isakmp v1.0 exchange ID_PROT
> cookie: 30e6fc2ae5d3ef74->8cb97ec972120f6e msgid:  len: 228
> payload: KEY_EXCH len: 132
> payload: NONCE len: 0 [|isakmp] [ttl 0] (id 1, len 256)
> 16:37:40.786483 192.168.1.13.500 > 192.168.1.15.500:  [udp sum ok] 
> isakmp v1.0 exchange INFO
> cookie: d5feed659a4246cc-> msgid:  len: 40
> payload: NOTIFICATION len: 12
> notification: INVALID PAYLOAD TYPE [ttl 0] (id 1, len 68)
> 
> 
> = tcpdump -nvr  /var/run/isakmpd.pcap==
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> isakmpd -DA=50 
> 163740.784428 Timr 10 timer_remove_event: removing event 
> message_send_expire(0x88cc00)
> 163740.784712 Default message_parse_payloads: invalid next payload type 
> RESERVED_MIN in payload of type 10
> 163740.785137 Default dropped message from 192.168.1.15 port 500 due to 
> notification type INVALID_PAYLOAD_TYPE
> 163740.785434 Timr 10 timer_add_event: event exchange_free_aux(0x892e00) 
> added last, expiration in 120s
> 163740.785729 Exch 10 exchange_establish_p1: 0x892e00   policy> policy initiator phase 1 doi 1 exchange 5 step 0
> 163740.785990 Exch 10 exchange_establish_p1: icookie d5feed659a4246cc 
> rcookie 
> 163740.786237 Exch 10 exchange_establish_p1: msgid 
> 163740.786599 Exch 40 exchange_run: exchange 0x892e00 finished step 0, 
> advancing...
> 163740.786834 Mesg 20 message_free: freeing 0x88d000
> 163740.787149 Exch 10 exchange_finalize: 0x892e00   
> policy initiator phase 1 doi 1 exchange 5 step 1
> 163740.787413 Exch 10 exchange_finalize: icookie d5feed659a4246cc 
> rcookie 
> 163740.787647 Exch 10 exchange_finalize: msgid 
> 163740.787879 Timr 10 timer_remove_event: removing event 
> exchange_free_aux(0x892e00)
> isakmpd -DA=50 
> 
> 
> dmesg===
> console is /[EMAIL PROTECTED],0/[EMAIL PROTECTED]/[EMAIL PROTECTED],3f8
> Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
> Copyright (c) 1

Re: ISAKMPD errors n. 8 and n. 118

[Hans-Joerg Hoexer]

man 3 errno

On Thu, Nov 10, 2005 at 01:53:27PM +0100, [EMAIL PROTECTED] wrote:
> Hello!
> 
>Thanks for your reply, first of all.
> 
> 
> > Hi,
> > 
> > the errno shown be ipsecadm can be ignored, nothing to worry about
> > (and this was fixed post 3.7-stable).  Besides this message the vpn
> > is working as expected?
> 
> 
>Yes, as I said the VPN appears to be working just fine. 
> So, *both* errors can be ignored, right (errno 8 and 118)?
> 
> Have you got any link to this kind of documentation, by the way?
> 
> Thanks again!
> 
>   --Rob

Re: ISAKMPD errors n. 8 and n. 118

[Hans-Joerg Hoexer]

Hi,

the errno shown be ipsecadm can be ignored, nothing to worry about
(and this was fixed post 3.7-stable).  Besides this message the vpn
is working as expected?

HJ.

On Thu, Nov 10, 2005 at 11:30:58AM +0100, [EMAIL PROTECTED] wrote:
> Hello!
> 
>I set up a tunnel between two machines (connected through the
> Internet) running OpenBSD 3.6 and everything was fine.
> 
>Then I had to upgrade one of the two machines to 3.7 (disk
> crash!). Rewrote the config file and restarted the tunnel. The
> tunnel is fine and the traffic gets encrypted all right. But if I
> run an "ipsecadm show", now I also see a "errno 8: Exec format
> error" on the 3.7 machine, and again no error on the 3.6 machine.
> 
>I was suggested to try 3.7 -stable. So I set up two new
> machines (both with 3.7 -stable) to test on my LAN:
> 
> 10.0.0.6 -- [ BOX A ] -- 192.168.3.254 /24
>
> 
> 192.168.99.254 /24 -- [ BOX B ] -- 192.168.3.17
> 
>I have a client PC on the .99 network which can ping the
> 10.0.0.6 interface (and the traffic is encrypted in the
> 192.168.3.0/24 network), so apparently all is well. 
> 
> 
>But now on BOX A I get a "errno 8: Exec format error", and on
> BOX B I get an "errno 118: Unknown error: 118" (see below).
> 
> Any ideas on what is going on?
> 
> Also, does anybody know where I can find some documentation
> concerning these error codes?
> 
> Many thanks in advance for your help.
> 
>---Rob
> 
> 
> ==   BOX A   "ipsecadm show"  192.168.3.254 ===
> -bash-3.00# ipsecadm show
> sadb_dump: satype esp vers 2 len 38 seq 0 pid 0
> errno 8: Exec format error
> sa: spi 0x1c5551f1 auth hmac-sha1 enc aes
> state larval replay 0 flags 4
> lifetime_cur: alloc 0 bytes 0 add 1131616603 first 0
> lifetime_soft: alloc 0 bytes 0 add 1080 first 0
> lifetime_hard: alloc 0 bytes 0 add 1200 first 0
> address_src: 192.168.3.17
> address_dst: 192.168.3.254
> identity_src: type prefix id 0: 192.168.3.17/32
> identity_dst: type prefix id 0: 192.168.3.254/32
> key_auth: bits 160: d5ca6d9959ad17801cf762264d35bc0417063ff8
> key_encrypt: bits 128: bf288d4fc105b7091c0d1582df44c738
> sadb_dump: satype esp vers 2 len 38 seq 0 pid 0
> errno 8: Exec format error
> sa: spi 0xbbdef5c1 auth hmac-sha1 enc aes
> state larval replay 0 flags 4
> lifetime_cur: alloc 0 bytes 0 add 1131616603 first 0
> lifetime_soft: alloc 0 bytes 0 add 1080 first 0
> lifetime_hard: alloc 0 bytes 0 add 1200 first 0
> address_src: 192.168.3.254
> address_dst: 192.168.3.17
> identity_src: type prefix id 0: 192.168.3.254/32
> identity_dst: type prefix id 0: 192.168.3.17/32
> key_auth: bits 160: 8ad139ce2bf0af8cd5188ea1551a4cf443e1bb7e
> key_encrypt: bits 128: 93511e6c7f7226600919a68cf1195893
> 
> 
> 
> ==   BOX B   "ipsecadm show"  192.168.3.17 
> -bash-3.00# ipsecadm show
> sadb_dump: satype esp vers 2 len 38 seq 0 pid 0
> errno 118: Unknown error: 118
> sa: spi 0xbbdef5c1 auth hmac-sha1 enc aes
> state larval replay 16 flags 4
> lifetime_cur: alloc 0 bytes 0 add 1131616563 first 0
> lifetime_soft: alloc 0 bytes 0 add 1080 first 0
> lifetime_hard: alloc 0 bytes 0 add 1200 first 0
> address_src: 192.168.3.254
> address_dst: 192.168.3.17
> identity_src: type prefix id 0: 192.168.3.254/32
> identity_dst: type prefix id 0: 192.168.3.17/32
> key_auth: bits 160: 8ad139ce2bf0af8cd5188ea1551a4cf443e1bb7e
> key_encrypt: bits 128: 93511e6c7f7226600919a68cf1195893
> sadb_dump: satype esp vers 2 len 38 seq 0 pid 0
> errno 118: Unknown error: 118
> sa: spi 0x1c5551f1 auth hmac-sha1 enc aes
> state larval replay 16 flags 4
> lifetime_cur: alloc 0 bytes 0 add 1131616563 first 0
> lifetime_soft: alloc 0 bytes 0 add 1080 first 0
> lifetime_hard: alloc 0 bytes 0 add 1200 first 0
> address_src: 192.168.3.17
> address_dst: 192.168.3.254
> identity_src: type prefix id 0: 192.168.3.17/32
> identity_dst: type prefix id 0: 192.168.3.254/32
> key_auth: bits 160: d5ca6d9959ad17801cf762264d35bc0417063ff8
> key_encrypt: bits 128: bf288d4fc105b7091c0d1582df44c738
> 
> 
> 
> ==   BOX A   isakmpd.conf 
> -bash-3.00# cat /etc/isakmpd/isakmpd.conf
> #   $OpenBSD: VPN-west.conf,v 1.14 2003/03/16 08:13:02 matthieu Exp $
> #   $EOM: VPN-west.conf,v 1.13 2000/10/09 22:08:30 angelos Exp $
> 
> # A configuration sample for the isakmpd ISAKMP/Oakley (aka IKE) daemon.
> #
> # The network topology of the example net is like this:
> #
> # 192.168.11.0/24 - west [.11] - 10.1.0.0/24 - [.12] east - 192.168.12.0/24
> #
> # "west" and "east" are the respective security gateways (aka VPN-nodes).
> 
> [Gene

Re: Mplayer & DVD problem

[Hans-Joerg Hoexer]

On Wed, Nov 09, 2005 at 07:44:29PM -0500, Roy Morris wrote:
> >libdvdread: Could not open /dev/rcd0c with libdvd.
> >libdvdread: Can't open /dev/rcd0c for reading
> >ERROR[ogle_nav]: faild to open/read the DVD
> >callbacks.on_opendvd_activate(): DVDSetDVDRoot: Root not set
> >
> >WHat am I supposed to enter here? Enter challenge, e.g. the name of your 
> >OS: Is this some
> >game? ;-)
> >
> > 
> >
> Aww, according to the ogle site, if you want to use encrypted dvds you
> need to install libdvdcss. Ummm is it just me or does that error say it
> can't read /dev/rcd0c ??
> 
> permissions right?

no, the wrong answer was provided (ie. name of your OS).  If I find
some more time, we'll get rid of this limitation.

Q: Why should one use libdvd instead of libdvdcss at all?
A: man 3 acss

Re: Mplayer & DVD problem

[Hans-Joerg Hoexer]

On Wed, Nov 09, 2005 at 05:03:25PM -0500, Roy Morris wrote:
> I think you need libdvdcss from ports. Both mplayer and ogle
> work fine for me.

or libdvd instead of libdvdcss.

Re: isakmpd: invalid next payload type RESERVED_MIN in payload of type 10

[Hans-Joerg Hoexer]

Hi,

On Fri, Nov 04, 2005 at 10:47:59PM +0100, Tobias Walkowiak wrote:
> hm, i think i better update the other peer to 3.8, as well - although it's
> 550 km from here ...
> 
> > Other workaround, disable nat-t with the -T option.
> 
> but that only works for 3.8 isakmpd, doesn't it? what about the
> net.inet.esp.udpencap sysctl setting? should it be set to zero?

the sysctl only affects the kernel, not isakmpd.  Using -T on the
3.8 side disables nat-t and the 3.7 isakmpd should be fine again.

HJ.

Re: isakmpd: invalid next payload type RESERVED_MIN in payload of type 10

[Hans-Joerg Hoexer]

Hi,

sorry, I was unclear.  Rebuild isakmpd after updating src/sbin/isakmpd
from CVS using the 3.7 patch branch (ie. cvs up -P -rOPENBSD_3_7).

Other workaround, disable nat-t with the -T option.

HJ.

On Fri, Nov 04, 2005 at 09:59:12PM +0100, Tobias Walkowiak wrote:
> On Fri, Nov 04, 2005 at 08:45:21PM +0100, Hans-Joerg Hoexer wrote:
> > If your other peer is 3.7, please apply all patches.
> 
> of course i applied all 5 patches from 3.7. or do you have sth different in
> mind?
> 
> -- 
> tobias

Re: isakmpd: invalid next payload type RESERVED_MIN in payload of type 10

[Hans-Joerg Hoexer]

If your other peer is 3.7, please apply all patches.
HJ.

On Fri, Nov 04, 2005 at 07:29:50PM +0100, Tobias Walkowiak wrote:
> On Fri, Nov 04, 2005 at 06:42:11PM +0100, Michiel van der Kraats wrote:
> > Today I upgraded a VPN gateway to 3.8-RELEASE. Anyway, when I put
> > isakmpd.conf back and tried to start it, only one VPN connection
> > (connected to a Linksys VPN gateway) came back up, the connection to
> > another OpenBSD gateway (running 3.7) could not be established. On the
> > other gateway, isakmpd logs:
> 
> how funny, today i experienced exactly the same: updated to 3.8 on the one
> side and with the same configuration no connection was established,
> reporting INVALID PAYLOAD TYPE (tcpdump -nvs1400)
> 
> does it maybe have sth. to do with nat-t?
> 
> -- 
> tobias

Re: isakmpd - Single Phase 1 - Multiple Phase 2 Address

[Hans-Joerg Hoexer]

Hi,

On Wed, Oct 26, 2005 at 02:40:52PM -0400, Roy Morris wrote:
> I have been reading through the archives but have not found a reliable answer
> yet. I have recently been converting vpns from manual to isakmpd, with one
> of the other endpoints being a Cisco box. I can bring up a single subnet/IP 
> no problem but if I try to add another phase2 connection it fails. 
...

ok, maybe I'm missing the point here or am not fully understanding
your problem, but something like below works for me.  A single phase
1 SA is used to negotiate different phase 2 SAs.  Note, both sides
are openbsd boxes.

...
[IPsec-vpn7-vpn8]
Phase=  2
ISAKMP-peer=ISAKMP-peer-theothers
Configuration=  Default-quick-mode
Local-ID=   Net-vpn7
Remote-ID=  Net-vpn8

[IPsec-vpn9-vpn10]
Phase=  2
ISAKMP-peer=ISAKMP-peer-theothers
Configuration=  Default-quick-mode
Local-ID=   Net-vpn9
Remote-ID=  Net-vpn10

[Net-vpn7]
ID-type=IPV4_ADDR_SUBNET
Network=192.168.7.0
Netmask=255.255.255.0

[Net-vpn8]
ID-type=IPV4_ADDR_SUBNET
Network=192.168.8.0
Netmask=255.255.255.0

[Net-vpn9]
ID-type=IPV4_ADDR_SUBNET
Network=192.168.9.0
Netmask=255.255.255.0

[Net-vpn10]
ID-type=IPV4_ADDR_SUBNET
Network=192.168.10.0
Netmask=255.255.255.0
...

Re: Question about isakmpd on obsd 3.7

[Hans-Joerg Hoexer]

On Wed, Oct 26, 2005 at 10:24:25AM +0200, [EMAIL PROTECTED] wrote:
> Hi all,
> 
>  Is ike over tcp supported under isakmpd on obsd 3.7?? where I can 

no

Re: isakmpd, greenbow vpn client and NO PROPOSAL CHOSEN

[Hans-Joerg Hoexer]

Hi,

On Wed, Oct 19, 2005 at 01:34:45PM +0200, Kim Nielsen wrote:
> [greenbow-main-mode]
> DOI=IPSEC
> EXCHANGE_TYPE=  ID_PROT
> Transforms= AES-SHA-GRP2
> 
> [greenbow-quick-mode]
> DOI=IPSEC
> EXCHANGE_TYPE=  QUICK_MODE
> Suites= QM-ESP-AES-SHA-PFS-GR2-SUITE
> 
> [AES-SHA-GRP2]
> ENCRYPTION_ALGORITHM=   AES_CBC
> HASH_ALGORITHM= SHA
> AUTHENTICATION_METHOD=  PRE_SHARED
> GROUP_DESCRIPTION=  MODP_1024
> Life=   LIFE_1_DAY

LIFE_1_DAY is not defined

Re: isakmpd, greenbow vpn client and NO PROPOSAL CHOSEN

[Hans-Joerg Hoexer]

On Wed, Oct 19, 2005 at 01:34:45PM +0200, Kim Nielsen wrote:
> [greenbow-quick-mode]
> DOI=IPSEC
> EXCHANGE_TYPE=  QUICK_MODE
> Suites= QM-ESP-AES-SHA-PFS-GR2-SUITE

it's GRP2, not GR2

> 
> [AES-SHA-GRP2]
> ENCRYPTION_ALGORITHM=   AES_CBC
> HASH_ALGORITHM= SHA
> AUTHENTICATION_METHOD=  PRE_SHARED
> GROUP_DESCRIPTION=  MODP_1024
> Life=   LIFE_1_DAY
> 
> 
> Basiclly its taken from http://www.allard.nu/openbsd/greenbow/ since I 
> googled for an answer but even though I take a copy of the isakmpd.conf 
> on that page I still don't get though phase1
> 
> Hope someone has an answer
> 
> Best regards
> Kim
> 
> Ps. I'm using OpenBSD 3.7

Re: OpenBSD VPN SonicWall Problems

[Hans-Joerg Hoexer]

Hi,

On Fri, Sep 30, 2005 at 05:57:14PM -0700, Trepliev wrote:
> [Net-SonicWall]
> ID-type= IPV4_ADDR_SUBNET
> Network= 172.16.0.0 
> Netmask= 255.255.0.0 
^
> 
> [Net-Corp]
> ID-type= IPV4_ADDR_SUBNET
> Network= 10.1.105.0 
> Netmask= 255.255.255.0 
^^

This is not supposed to work.  Please read isakmpd.conf(5).

Re: 3.7: "INVALID PAYLOAD TYPE"

[Hans-Joerg Hoexer]

 payload:  len: 24
> payload:  len: 24 (ttl 126, id 1733, len 344)
> 12:16:05.217956 0:e0:81:63:16:d2 0:0:c:3e:48:dc 0800 82: 5.6.7.8.500 > 
> 1.2.3.4.500:  [udp sum ok] isakmp v1.0 exchange INFO
> cookie: 6af35ef1d456e460-> msgid:  len: 40
> payload: NOTIFICATION len: 12
> notification: INVALID PAYLOAD TYPE (ttl 64, id 15575, len 68)
> 12:16:09.220412 0:0:c:3e:48:dc 0:e0:81:63:16:d2 0800 358: 1.2.3.4.500 > 
> 5.6.7.8.500:  [udp sum ok] isakmp v1.0 exchange ID_PROT
> cookie: 0c052e9abace2953->6297719b10aab610 msgid:  len: 316
> payload: KEY_EXCH len: 196
> payload: NONCE len: 44
> payload:  len: 24
> payload:  len: 24 (ttl 126, id 1734, len 344)
> 12:16:09.222948 0:e0:81:63:16:d2 0:0:c:3e:48:dc 0800 82: 5.6.7.8.500 > 
> 1.2.3.4.500:  [udp sum ok] isakmp v1.0 exchange INFO
> cookie: 8e945543b69f3d8e-> msgid:  len: 40
> payload: NOTIFICATION len: 12
> notification: INVALID PAYLOAD TYPE (ttl 64, id 25815, len 68)
> 12:16:14.226697 0:0:c:3e:48:dc 0:e0:81:63:16:d2 0800 358: 1.2.3.4.500 > 
> 5.6.7.8.500:  [udp sum ok] isakmp v1.0 exchange ID_PROT
> cookie: 0c052e9abace2953->6297719b10aab610 msgid:  len: 316
> payload: KEY_EXCH len: 196
> payload: NONCE len: 44
> payload:  len: 24
> payload:  len: 24 (ttl 126, id 1735, len 344)
> 12:16:14.229247 0:e0:81:63:16:d2 0:0:c:3e:48:dc 0800 82: 5.6.7.8.500 > 
> 1.2.3.4.500:  [udp sum ok] isakmp v1.0 exchange INFO
> cookie: d7059971fb358e93-> msgid:  len: 40
> payload: NOTIFICATION len: 12
> notification: INVALID PAYLOAD TYPE (ttl 64, id 15834, len 68)
> 
> 
> Btw, on the 3.6 box, when I configure the client to talk on the
> aliased address, it doesn't work either, but with a very different
> error message. I'm willing to ignore this problem if I can get
> the 3.7 (3.8?) problem solved.
> 
> 
> Any help is very much appreciated!
> 
> 
> 
> Best,
> --Toni++
> 
> 

-- 
Dipl.-Inf. Hans-Joerg Hoexerroom: 07.137phone:+49 9131 852 7915
Dept. of Computer Science 3 University of Erlangen-Nuremberg
Martensstr. 3, 91058 Erlangen, Germany

Re: Jose Nazario's dmesg explained for OpenBSD

[Hans-Joerg Hoexer]

On Tue, Sep 06, 2005 at 12:25:23AM -0500, Andrew Daugherity wrote:
> ===
> a) biomask e74d netmask ff4d ttymask ffef
...

this are the interrupt masks (on i386) for the levels IPL_BIO,
IPL_NET and IPL_TTY after autoconfiguration has finished.  They
will be modified again when clock and rtc are initialized, i.e.
interrupts 0 and 8 will be unblocked on all three levels.

Re: isakmpd can't tear down phase 1 SA (3.8-beta/i386)

[Hans-Joerg Hoexer]

Hi,

that's a limitation of isakmpd.  I have a patch for this, but as
adding support for phase 1 SA deletion using the fifo is not that
straight forward it will not make the 3.8 release.  I'm sorry.

HJ.

On Thu, Sep 01, 2005 at 10:21:51AM -0400, Kurt Miller wrote:
> I'm not sure if my problem is user/configuration related or if there
> is a problem with isakmpd... I'd like to only initiate connections using
> the isakmpd.fifo as needed. When finished with the connection I was
> planning on tearing it down using the fifo too.
> 
> When I tear down the phase 2 connection, phase 1 remains. Nothing
> I do seems to be able to tear down the phase 1 connection. The
> remote side tears down its phase 1 connection when the phase
> 2 one is gone (remote is a SonicWall in this case). When I attempt
> to reconnect to the remote site, isakmpd uses the old phase 1 and
> can't connect.
> 
> I think this is a problem with isakmpd. Below are the commands I'm
> issuing and the isakmpd.result info after each step. Also the -DA=90
> output for this sequence is available here:
> 
> http://intricatesoftware.com:81/OpenBSD/misc/isakmpd.log
> 
> $ sudo ksh -c "echo c IPsec-Site1 >> /var/run/isakmpd.fifo"
> $ sudo ksh -c "echo S >> /var/run/isakmpd.fifo"
> $ more /var/run/isakmpd.result
> SA name: ISAKMP-Site1 (Phase 1/Initiator)
> src: 172.16.1.24 dst: x.x.x.x
> Lifetime: 28800 seconds
> Soft timeout in 26429 seconds
> Hard timeout in 28791 seconds
> icookie af2b308c6583a724 rcookie 32ea88cc20420661
> 
> SA name: IPsec-Site1 (Phase 2)
> src: 172.16.1.24 dst: x.x.x.x
> Lifetime: 1200 seconds
> Soft timeout in 1056 seconds
> Hard timeout in 1191 seconds
> SPI 0: f3d26409
> SPI 1: bda5bb6e
> Transform: IPsec ESP
> Encryption key length: 8
> Authentication key length: 16
> Encryption algorithm: DES
> Authentication algorithm: HMAC-MD5
> 
> Everything is working ok at this point. Now tear down IPsec-Site1
> and check if phase 1 is still there.
> 
> $ sudo ksh -c "echo t IPsec-Site1 >> /var/run/isakmpd.fifo"
> $ sudo ksh -c "echo S >> /var/run/isakmpd.fifo"
> $ more /var/run/isakmpd.result
> SA name: ISAKMP-Site1 (Phase 1/Initiator)
> src: 172.16.1.24 dst: x.x.x.x
> Lifetime: 28800 seconds
> Soft timeout in 26385 seconds
> Hard timeout in 28747 seconds
> icookie af2b308c6583a724 rcookie 32ea88cc20420661
> 
> I can't get rid of this entry using 't ISAKMP-Site1' or
> 'd af2b308c6583a724  -' or 'd 32ea88cc20420661 -' or
> even 'T'. Attempting to reconnect fails and looks like this:
> 
> $ sudo ksh -c "echo c IPsec-Site1 >> /var/run/isakmpd.fifo"
> $ sudo ksh -c "echo S >> /var/run/isakmpd.fifo"
> $ more /var/run/isakmpd.result
> SA name: ISAKMP-Site1 (Phase 1/Initiator)
> src: 172.16.1.24 dst: x.x.x.x
> Lifetime: 28800 seconds
> Soft timeout in 26282 seconds
> Hard timeout in 28644 seconds
> icookie af2b308c6583a724 rcookie 32ea88cc20420661
> 
> SA name:  (Phase 2)
> src: 172.16.1.24 dst: x.x.x.x
> SPI 0 not defined.
> SPI 1: bd55249b
> Transform: IPsec ESP
> Encryption key length: 0
> Authentication key length: 0
> Encryption algorithm: unknown (0)
> Authentication algorithm: none
> 
> Note the Phase 2 garbage. I have to shutdown isakmpd to clean this up.
> 
> Here's my isakmpd.conf:
> 
> [General]
> Default-phase-1-lifetime= 28800,60:86400
> 
> [Phase 1]
> x.x.x.x=  ISAKMP-Site1
> 
> [Phase 2]
> Passive-connections=  IPsec-Site1
> 
> # Phase 1 
> ###
> 
> [ISAKMP-Site1]
> Phase=1
> Address=  x.x.x.x
> Configuration=SonicWall-main-mode
> Default=  IPsec-Site1
> Authentication=   not
> ID=   SonicWall-Phase1-ID
> 
> # Phase 2 sections
> ##
> 
> [IPsec-Site1]
> Phase=2
> ISAKMP-peer=  ISAKMP-Site1
> Configuration=SonicWall-quick-mode
> Local-ID= Default-Phase2-Local-ID
> Remote-ID=Site1-Phase2-Remote-ID
> 
> # Client ID sections
> 
> 
> [SonicWall-Phase1-ID]
> ID-type=  USER_FQDN
> Name= GroupVPN
> 
> [Default-Phase2-Local-ID]
> ID-type=  IPV4_ADDR
> Address=  default
> 
> [Site1-Phase2-Remote-ID]
> ID-type=  IPV4_ADDR_SUBNET
> Network=  172.31.5.0
> Netmask=  255.255.255.0
> 
> # Transform descriptions
> 
> 
> [SonicWall-main-mode]
> DOI=  IPSEC
> EXCHANGE_TYPE=ID_PROT
> Transforms=   3DES-MD5
> 
> [SonicWall-quick-mode]
> DOI=  IPSEC
> EXCHANGE_TYPE=QUICK_MODE
> Suites=   QM-ESP-DES-MD5-SUITE
> 

-- 
pub  1024D/513AEFD9 1999-12-18 Hans-Joerg Hoexer 
 <[EMAIL PROTECTED]>
Key fingerprint = 83D2 436A 0D3C 34A9 E0FF  4C33 35F6 617C 513A EFD9

Re: IPSEC between OpenBSD (isakmpd) and Linux (FreeS/Wan)

[Hans-Joerg Hoexer]

Hi,

yes, this howto is basically unmaintained since, uhm, several years
and I actually should remove it.

However, I have configs for interop with Openswan (don't know what's
different to Freeswan) somewhere, will dig them out tonight...

On Thu, Aug 04, 2005 at 04:09:56PM +0200, Guido Tschakert wrote:
...
> I found the following page but the configfile for isakmpd is full of 
> bugs (looks like a lot of copy and paste without re-editing :-)  )
> http://www.rommel.stw.uni-erlangen.de/~hshoexer/ipsec-howto/HOWTO.html
...

-- 
pub  1024D/513AEFD9 1999-12-18 Hans-Joerg Hoexer 
 <[EMAIL PROTECTED]>
Key fingerprint = 83D2 436A 0D3C 34A9 E0FF  4C33 35F6 617C 513A EFD9

Re: Phase 2 problem between isakmpd and Netscreen

[Hans-Joerg Hoexer]

Hi,

this worked with an older isakmpd version?  Is this netscreen box
some kind of appliance or just some windows software?

The general problem is, I can only test interoperatibility with
open source vpn solutions on standard hareware.  If people need to
rely on interoperability with appliance X and Windows client Y and
MacOS client Z, I need this kind of hardware/software.

People interrested in providing those, are welcome to contact me :-)

HJ.

On Wed, Jul 27, 2005 at 01:35:34AM -0700, Sean Knox wrote:
> (posted a similar message originally on the IPSec list; thought I'd post 
> here too)
> 
> Hey all-
> 
> I almost have a working VPN between isakmpd and a Netscreen box-- things
> fail at phase 2 as the peers enter quick mode.
> 
> 64.81.74.226 = isakmpd
> 206.14.210.146 = netscreen
> 
> 00:28:11.947907 64.81.74.226.500 > 206.14.210.146.500:  [udp sum ok]
> isakmp v1.0 exchange QUICK_MODE
>   cookie: eb114e8223bc0965->3aac9200ac79d919 msgid: 9e7ccdd5 len: 284
>   payload: HASH len: 24
>   payload: SA len: 56 DOI: 1(IPSEC) situation: IDENTITY_ONLY
>   payload: PROPOSAL len: 44 proposal: 1 proto: IPSEC_ESP spisz: 4
> xforms: 1 SPI: 0xadfa06f3
>   payload: TRANSFORM len: 32
>   transform: 1 ID: AES
>   attribute LIFE_TYPE = SECONDS
>   attribute LIFE_DURATION = 1200
>   attribute ENCAPSULATION_MODE = TUNNEL
>   attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
>   attribute GROUP_DESCRIPTION = 2
>   attribute KEY_LENGTH = 128
>   payload: NONCE len: 20
>   payload: KEY_EXCH len: 132
>   payload: ID len: 12 type: IPV4_ADDR = 64.81.74.226
>   payload: ID len: 12 type: IPV4_ADDR = 130.94.4.65 [ttl 0] (id 1, len 
>   312)
> 00:28:12.138720 206.14.210.146.500 > 64.81.74.226.500:  [udp sum ok]
> isakmp v1.0 exchange QUICK_MODE
>   cookie: eb114e8223bc0965->3aac9200ac79d919 msgid: 9e7ccdd5 len: 300
>   payload: HASH len: 24
>   payload: SA len: 60 DOI: 1(IPSEC) situation: IDENTITY_ONLY
>   payload: PROPOSAL len: 48 proposal: 1 proto: IPSEC_ESP spisz: 4
> xforms: 1 SPI: 0x0502a8eb
>   payload: TRANSFORM len: 36
>   transform: 1 ID: AES
>   attribute LIFE_TYPE = SECONDS
>   attribute LIFE_DURATION = 04b0
>   attribute ENCAPSULATION_MODE = TUNNEL
>   attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
>   attribute GROUP_DESCRIPTION = 2
>   attribute KEY_LENGTH = 128
>   payload: NONCE len: 24
>   payload: KEY_EXCH len: 132
>   payload: ID len: 12 type: IPV4_ADDR = 64.81.74.226
>   payload: ID len: 12 type: IPV4_ADDR = 130.94.4.65 [ttl 0] (id 1, len 
>   328)
> 00:28:15.838995 206.14.210.146.500 > 64.81.74.226.500:  [udp sum ok]
> isakmp v1.0 exchange QUICK_MODE
>   cookie: eb114e8223bc0965->3aac9200ac79d919 msgid: 9e7ccdd5 len: 300
>   payload: HASH len: 24
>   payload: SA len: 60 DOI: 1(IPSEC) situation: IDENTITY_ONLY
>   payload: PROPOSAL len: 48 proposal: 1 proto: IPSEC_ESP spisz: 4
> xforms: 1 SPI: 0x0502a8eb
>   payload: TRANSFORM len: 36
>   transform: 1 ID: AES
>   attribute LIFE_TYPE = SECONDS
>   attribute LIFE_DURATION = 04b0
>   attribute ENCAPSULATION_MODE = TUNNEL
>   attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
>   attribute GROUP_DESCRIPTION = 2
>   attribute KEY_LENGTH = 128
>   payload: NONCE len: 24
>   payload: KEY_EXCH len: 132
>   payload: ID len: 12 type: IPV4_ADDR = 64.81.74.226
>   payload: ID len: 12 type: IPV4_ADDR = 130.94.4.65 [ttl 0] (id 1, len 
>   328)
> 
> --snip--
> 
> Note the wacky LIFE_DURATION sent by the netscreen. As shown in the 
> packet capture the netscreen continues to send quick mode packets but 
> isakmpd never responds. I've logs at http://obstacle9.com/isakmpd/ . 
> I've tried different transforms and proposal settings but the result is 
> the same. This happens on a snapshot from a few days ago.
> 
> 
> thanks,
> sk
> 

-- 
pub  1024D/513AEFD9 1999-12-18 Hans-Joerg Hoexer 
 <[EMAIL PROTECTED]>
Key fingerprint = 83D2 436A 0D3C 34A9 E0FF  4C33 35F6 617C 513A EFD9

Re: route flush -encap // Flushing all ipsec flows

[Hans-Joerg Hoexer]

man ipsecadm(8): ipsecadm flow -delete <...>

On Thu, Jun 30, 2005 at 03:00:16PM +0200, Manon Goo wrote:
> The ipsecadm flush -esp does not work, the esp SA are removed but the SPD
> (Flows) are kept.
> 
> ipsecadm flush removes everything but this is not good because it removes
> tcpmd5 sigs
> as well and breaks bgpd.
> 
> I cann not find anything to spcificly remove the SPD (Flows ) or the ESP SA
> and the flows.
> 
> Any help would be great.
> 
> Manon
> 
> 
> --On 30. Juni 2005 14:36:43 +0200 Manon Goo <[EMAIL PROTECTED]> wrote:
> 
> > What is the equivalent for route flush -encap under openbsd 3.7  ?
> >
> > Manon
> >
> > [demime 1.01d removed an attachment of type application/pgp-signature]
> 
> [demime 1.01d removed an attachment of type application/pgp-signature]
> 

-- 
pub  1024D/513AEFD9 1999-12-18 Hans-Joerg Hoexer 
 <[EMAIL PROTECTED]>
Key fingerprint = 83D2 436A 0D3C 34A9 E0FF  4C33 35F6 617C 513A EFD9

Re: Upgrade to 3.7 and VPN no longer works

[Hans-Joerg Hoexer]

apply all patches listed on the errata pages for your 3.4 and 3.6
machines.  There are patches for this issue.

On Sun, Jun 19, 2005 at 01:34:06PM +1000, Dave Harrison wrote:
> I just upgraded my firewall to 3.7, but I've found my VPN is now not
> working.  I keep seeing "NAT detected" messages, but both machines have
> real IPs so it doesn't make sense.  The client machine is a 3.6 install,
> and the server machine was a 3.4 machine which I used the media CD to
...

Re: ipsecadm problem in 3.7?

[Hans-Joerg Hoexer]

Hi,

tried to reproduce this with /usr/share/ipsec/rc.vpn between
3.6-stable and 3.7-current, but could not.  The static vpn is working
as expected.

HJ.

On Sun, Jun 12, 2005 at 11:30:11AM -0700, Jeff Simmons wrote:
> I have a large VPN network using several OpenBSD 3.5 and 3.6 boxes, I'm
> using shared keys, and the rc.vpn script to initialize it. Yesterday I
> tried to add a 3.7 box to the mix, and it wouldn't work. The symptoms were
> the tunnels never came up, and the respective gateways lost communication
> with each other (no ssh, ping, etc.).
> 
> Some manual command entry on the 3.7 box showed the following:
> 
> gorgon:~# ipsecadm flush
> gorgon:~# ipsecadm new esp -enc aes -auth sha1 -spi 1030 -dst y.y.y.y -src
> x.x.x.x -keyfile /etc/vpn/enc.key -authkeyfile /etc/vpn/auth.key
> gorgon:~# ipsecadm show
> sadb_dump: satype esp vers 2 len 21 seq 0 pid 0
> errno 150: Unknown error: 150
> sa: spi 0x1030 auth hmac-sha1 enc aes
> state larval replay 0 flags 0
> lifetime_cur: alloc 0 bytes 0 add 1118600322 first 0
> address_src: x.x.x.x
> address_dst: y.y.y.y
> key_auth: bits 160: 
> key_encrypt: bits 128: 
> 
> Other than the error message, the only major change from 3.6 to 3.7 is
> that the satype went from unspec (3.6) to enc (3.7).
> 
> I've duplicated this on three separate computers running 3.7, one of which
> was successfully running exactly the same command until it was upgraded
> (this one is giving an errno 160). Anyone have any idea what the problem
> is?
> 
> --
> [EMAIL PROTECTED]

Re: VPN client connectivity issues with OBSD firewall

[Hans-Joerg Hoexer]

Your vpn software must support nat-traversal (NAT-T) to work behind nat.
HJ.

On Mon, May 30, 2005 at 12:16:02PM +0530, Suresh Myneni wrote:
> Hopefully someone will be able to help me with a vpn client
> connectivity problem . Using Contivity VPN client on windows 2k going
> through OpenBSD 3.7 PF/NAT
> 
> I have three workstations behind the firewall using private IPs. The
> internet usage is fine on all the machines. But when I use Contivity
> VPN client through NAT on a single machine to connect to the remote
> site, I am able to connect fine. When I use the second machine to
> connect to the remote site using the VPN client, the VPN client fails
> in the last stage of establishing the connection. It gives me a
> message "Checking for banner text from x.x.x.x" and then disconnects.
> 
> The first machine I use to connect to the client's VPN server is
> working fine. When the first VPN connection is active, and when I try
> to connect the second machine, it is not able to connect to the
> VPN server.
> Is it something to do with the traffic routing in the private network
> between the client machines and the router?? Please advise.
> 
> Here is my ruleset.
> # Define useful variables
> ExtIF="fxp0" # External Interface
> NoRouteIPs="{ 127.0.0.1/8, 192.168.0.0/16, 172.16.0.0/12 }"
> 
> # Clean up fragmented and abnormal packets
> scrub in all
> 
> #nat goes here now
> nat on $ExtIF from 192.168.1.1/24 to any -> $ExtIF
> 
> # don't allow anyone to spoof non-routeable addresses
> block in quick on $ExtIF from $NoRouteIPs to any
> block out quick on $ExtIF from any to $NoRouteIPs
> 
> # block various nmap shyte
> block in quick on $ExtIF inet proto tcp from any to any flags FUP/FUP
> block in quick on $ExtIF inet proto tcp from any to any flags SF/SFRA
> block in quick on $ExtIF inet proto tcp from any to any flags /SFRA
> block in quick on $ExtIF inet proto tcp from any to any flags F/SFRA
> block in quick on $ExtIF inet proto tcp from any to any flags U/SFRAU
> block in quick on $ExtIF inet proto tcp from any to any flags P
> 
> # by default, block all incoming packets, except those explicitly
> # allowed by further rules
> block in on $ExtIF all
> 
> # Allow isakmp
> pass in quick on $ExtIF inet proto udp from any to any port = 500
> pass in quick on $ExtIF inet proto esp from any to any
> 
> # and let out-going traffic out and maintain state on established connections
> # pass out all protocols, including TCP, UDP and ICMP, and create state,
> # so that external DNS servers can reply to our own DNS requests (UDP).
> # ALSO ALLOW isakmp outgoing
> block out on $ExtIF all
> pass out on $ExtIF inet proto tcp all flags S/SA keep state
> pass out on $ExtIF inet proto udp from any to any port = 500
> pass out on $ExtIF inet proto esp from any to any
> pass out on $ExtIF inet proto udp all keep state
> pass out on $ExtIF inet proto icmp all keep state
> 
> Am I missing something? I am new to OpenBSD. I was very hopeful of
> building a firewall that I could use with my small office setup that
> connects to a client site via VPN.I picked up the above ruleset from
> internet. If someone can suggest better ruleset, that would be great
> also.
> Please help.
> Thanks
> Suresh
> 

-- 
pub  1024D/513AEFD9 1999-12-18 Hans-Joerg Hoexer 
 <[EMAIL PROTECTED]>
Key fingerprint = 83D2 436A 0D3C 34A9 E0FF  4C33 35F6 617C 513A EFD9

Re: General IPsec configuration vunerabilities (links)

[Hans-Joerg Hoexer]

Use esp with enc+auth, as written in isampd.conf(5).


On Fri, May 13, 2005 at 01:28:29PM +0200, Johan P. Lindstrvm wrote:
> I am trying to set up ESP tunnels with ISAKMPD myself, but I am far
> from an IPSec pro, does anyone know what would be "best practice" in
> the light of this event?
> 
> / Johan P
> 
> On 5/13/05, Peter Galbavy <[EMAIL PROTECTED]> wrote:
> > FYI; This is not specific, but should be interesting to misc@ readers.
> > 
> > http://www.theregister.co.uk/2005/05/12/ipsec_crypto_alert/
> > 
> > which point to:
> > 
> > http://www.niscc.gov.uk/niscc/docs/al-20050509-00386.html?lang=en
> > 
> > "Three attacks that apply to certain configurations of IPsec have been
> > identified. These configurations use Encapsulating Security Payload
> > (ESP) in tunnel mode with confidentiality only, or with integrity
> > protection being provided by a higher layer protocol. Some
> > configurations using AH to provide integrity protection are also
> > vulnerable."
> > 
> > Peter
> 

-- 
pub  1024D/513AEFD9 1999-12-18 Hans-Joerg Hoexer 
 <[EMAIL PROTECTED]>
Key fingerprint = 83D2 436A 0D3C 34A9 E0FF  4C33 35F6 617C 513A EFD9

Re: isakmpd, tunnel mode or transport mode?

[Hans-Joerg Hoexer]

both, see isakmpd(8) and isakmpd.conf(5)

On Wed, May 04, 2005 at 04:19:37PM +0200, Abel Talaveron wrote:
> Hi all,
> 
> can isakmpd work in both modes? Or only in tunnel mode?
> 
> Thanks