headers
Eichert, Diana | 1 Mar 00:13
Picon
Favicon

Greenbow road warrior setup to OpenBSD 4.0 recent snapshot ?

Knock, Knock

Not sure anyone is out there, but I thought I'd try.

I've been trying to setup a WinXP road warrior client 
using the Greenbow client.  First, it appears things 
have changed a little in the client since the web page 
tutorial was created, things look a little different.
Second, OpenBSD recommended configuration file and 
utility is ipsecctl and ipsec.conf.  I managed to get 
one side of the VPN working between the WinXP client 
and OpenBSD gateway.  The packets go out the encap 
tunnel but are returning in the clear.

here's some quick ASCI art.

WinXP roamer	     OpenBSD GW
dhcp acquired <-----> fixed address <-------> internal network
address 
		      11.12.13.44	192.168.1.29	192.168.1.0/24

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 group none \
        psk "secretkey"

ike passive esp tunnel \
        from 192.168.1.0/24 to any \
        main auth hmac-sha1 enc 3des group modp1024 \
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tom Doherty | 16 Oct 11:37

Re: ipsecctl(8) + setkey(8)

Tobias Wigand wrote:
> hi,
>
>>>
>>>   
>> Thanks for the reply. pf is disabled, like I said, I can see esp 
>> traffic on both hosts.
>
> never tried linux vs openbsd, but as i got stuck there once and could 
> see traffic but no answers from the openbsd hosts:
>
> do you have
>
> net.inet.esp.enable=1
> net.inet.esp.udpencap=1
>
> uncommented in /etc/sysctl.conf?
> and the equivalent in linux if it needs it..
>
> cheers
> tobias

Thanks for the advice. It appears both sysctl's are enabled by default 
in OpenBSD 4.0. I cannot find any similar keys in Linux, although I have 
compiled all IPSec options into the kernel.
Thanks again
Tom
Permalink | Reply | 0 comments |
headers
Tom Doherty | 15 Oct 08:55

Re: ipsecctl(8) + setkey(8)

Mathieu Sauve-Frankel wrote:
>> I see ESP packets both sides using tcpdump but the machines don't talk 
>> (I cannot ssh/nc etc).
>> I'd really appreciate any help you can offer.
>> Thanks for reading
>> Tom
>>     
>
> are you running pf on the openbsd machine ? if so.. add this to your ruleset
>
> set skip on enc0
>
>   
Thanks for the reply. pf is disabled, like I said, I can see esp traffic 
on both hosts.
Thanks again
Tom
Permalink | Reply | 0 comments |
headers
Tom Doherty | 14 Oct 23:42

ipsecctl(8) + setkey(8)

Hi guys
I'm having a complete nightmare making OpenBSD (ipsecctl) and Linux 
(setkey) IPSec play nice. All I'd like to do is setup IPSec using ESP, 
transport mode, and manual keying. It was incredibly easy to get two 
OpenBSD boxes talking via IPSec using ipsecctl.
My OpenBSD ipsec.conf is as follows:
flow esp from 172.16.250.128 to 172.16.250.131
esp from 172.16.250.128 to 172.16.250.131 spi 0xc9dbb83d:0xabd9da39 \
        authkey

0x7f48ee352c626cdc2a731b9d90bd63e29db2a9c683044b70b2f4441521b622d6:0x54f79f479a32814347bb768d3e01b2b58e49ce674ec6e2d327b63408c56ef4e8 
\
        enckey 
0xf7795f6bdd697a43a4d28dcf1b79062d:0xb341aa065c3850edd6a61e150d6a5fd3

and the Linux/setkey ipsec.conf like:
flush;
spdflush;

add 172.16.250.131 172.16.250.128 esp 0xabd9da39 -E aes-cbc 
0xb341aa065c3850edd6a61e150d6a5fd3 -A hmac-sha256 
0x54f79f479a32814347bb768d3e01b2b58e49ce674ec6e2d327b63408c56ef4e8;
add 172.16.250.128 172.16.250.131 esp 0xc9dbb83d -E aes-cbc 
0xf7795f6bdd697a43a4d28dcf1b79062d -A hmac-sha256 
0x7f48ee352c626cdc2a731b9d90bd63e29db2a9c683044b70b2f4441521b622d6;
spdadd 172.16.250.131 172.16.250.128 any -P out ipsec esp/transport//use;
spdadd 172.16.250.128 172.16.250.131 any -P in ipsec esp/transport//use;

I see ESP packets both sides using tcpdump but the machines don't talk 
(I cannot ssh/nc etc).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rodolphe A. | 11 Aug 09:48
Picon

Re: OpenBSD 3.9 ISAKMPD VPN Tunnel AutoStart

Hello,

I didn't like the new files /etc/ipsec.conf
It's too simple for many tunnels with differents concentrator vpn.
(cisco, checkpoint, ...)
And in file /etc/isakmpd/isakmpd.conf, the option Passive-connections
and connections isn't the solution for create on demand for vpn peer
to peer.

Rodolphe.

2006/8/11, Håkan Olsson <ho <at> rfc.se>:
> Sure you can.
>
> See ipsecctl(8) and ipsec.conf(5). What you want is to set up
> "acquire" (or "require") type flows. Then the SAs are negotiated on
> demand.  It's slightly more complex to do if you use isakmpd.conf/
> ipsecadm (use 'Passive-connections' instead of 'Connections' in
> isakmpd.conf, and set up your flows acquire/require).
>
> (The ipsec.conf(5) manpage does not say, but the difference between
> acquire and require is that while both will want SAs to send traffic
> through (and call isakmpd to negotiate SAs if no such exist), acquire
> will permit the cleartext traffic through while require will not. For
> a more thorough explanation see ipsecadm(8). (ipsecadm is obsolete
> from OpenBSD 4.0 and later.))
>
> There should be examples available of such setups if you search for
> them.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rodolphe | 10 Aug 17:07
Picon

OpenBSD 3.9 ISAKMPD VPN Tunnel AutoStart

Hello,

I use an concentrator VPN with OpenBSD 3.9 and ISAKMPD.

I don't want isakmpd to automatically activate a connection when it starts,
I want it to activate a connection "on-demand" with that "demand" generated
from the isakmpd side.

Alls tunnels is PEER to PEER.

for first test, i use a similar Peer. A second OpenBSD.

Alls tunnels start when the deamon ISAKMPD start.

Thanks.
Rodolphe
Permalink | Reply | 6 comments |
headers
Savage, Elijah | 7 Jul 16:59
Favicon

Road Warrior setup not working

I have have a Sun Ultra 60 as a firewall for a small company running
openbsd for a few years now. Now they want vpn acess I have installed
greenbow trial on my laptop for testing. I have everything going the
clients can connect, I get no errors in the log files but the clients
can't talk to the subnet behind the firewall as if routing is not taking
place. Can anyone point me in the right direction for troubleshooting
this issue?

Thank you

[General]
Retransmits=    3

[Phase 1]
default  =              road

[Phase 2]
Passives-connections=           road-warrior

[road]
Phase=                  1
Transport=              udp
Configuration=          Default-main-mode
Authentication=         topsecret

[road-warrior]
Phase=                  2
ISAKMP-peer=            road
Configuration=          Default-quick-mode
Local-ID=               network_corporate
(Continue reading)

Permalink | Reply | 1 comment |
headers
Doug Frippon | 14 Mar 20:29
Picon

Re: Re: Windows <-> OpenBSD (Isakmpd)

OMFG
It's working as expect. Thank you very much Mathieu. It is you that
help me the most debuging this ****.
I don't understand why it should have the full dn of the CA in the
policy to work ???
Can you tell me why???

AND thx again. Now I really ffeel like a kid in front of a toy store!!! =-)

Doug2die4

BTW I will do a step by step how-to for this because I need it for the
job's document and I'd like to make it availible for everyone so where
can I leave it????
Permalink | Reply | 0 comments |
headers
Doug Frippon | 14 Mar 17:34
Picon

Re: Re: Windows <-> OpenBSD (Isakmpd)

here it is:

KeyNote-Version:        2
Authorizer:             "POLICY"
Licensees:              "DN:/CN=RootCA"
Condition:              app_domain == "IPsec policy" && esp_present ==
"yes" -> "true";


# isakmpd -d -DA=90

112833.305154 Default log_debug_cmd: log level changed from 0 to 90
for class 0 [priv]
112833.305976 Default log_debug_cmd: log level changed from 0 to 90
for class 1 [priv]
112833.306407 Default log_debug_cmd: log level changed from 0 to 90
for class 2 [priv]
112833.306771 Default log_debug_cmd: log level changed from 0 to 90
for class 3 [priv]
112833.307172 Default log_debug_cmd: log level changed from 0 to 90
for class 4 [priv]
112833.307530 Default log_debug_cmd: log level changed from 0 to 90
for class 5 [priv]
112833.307931 Default log_debug_cmd: log level changed from 0 to 90
for class 6 [priv]
112833.308298 Default log_debug_cmd: log level changed from 0 to 90
for class 7 [priv]
112833.308656 Default log_debug_cmd: log level changed from 0 to 90
for class 8 [priv]
112833.309015 Default log_debug_cmd: log level changed from 0 to 90
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Frippon | 10 Mar 19:54
Picon

Re: Windows <-> OpenBSD (Isakmpd)

I've made change in isakmpd.conf (adding ISAKMP-peer=win2k and
Configuration=Default-quick-mode) but doesn't seems to have change
something. To be honest, that doesn't surprise me cause the default
value must be taken if not present.
Doug2die4
Permalink | Reply | 1 comment |
headers
Doug Frippon | 10 Mar 18:09
Picon

Re: Windows <-> OpenBSD (Isakmpd)

I've done some change and now here what I've got

120535.368318 Mesg 70 message_recv: e2101ad1 387e269f 9e9f364c
3b2c8f68 4d45c3fa 72df9df1 a8df8a69 ee07da0e
120535.368774 Mesg 70 message_recv: 06b001af 88768b09 a47100fd
9b318e3e db12f4c0 571c3568 7d68b7bb 9c4219a9
120535.369223 Mesg 70 message_recv: 9bc9c5d2 6a0c8963 34be646f
fcbdfeba a52c3370 41768e55 d174d0ba 51a46f9e
120535.369678 Mesg 70 message_recv: 101afb01 800369dc 42d44761
a798e559 9d7ad393 966c49bc 879e2977 a5f69391
120535.370608 Mesg 70 message_recv: 3e2a5dc3 fd3d3a1e 31afa870
362541f3 9bf43463 c436f6fd cdf279f1 32ea810c
120535.371481 Mesg 70 message_recv: 4fb160e7 8a43061a 57fad972
30c47e18 62709497 d6efefb5 eb367bba 63579695
120535.372046 Mesg 70 message_recv: 9d7a9734 97748da0 80023700
926225a7 ab5b7d97 6c90d6bf bbc438da 2fa7aca3
120535.372493 Mesg 70 message_recv: abf371e1 798b461e 66109a1b
2a1a9403 6c1a71d8 1ecb2c77 d051235e cec5f56c
120535.372967 Mesg 70 message_recv: 83b419bc b8c63311 aa2bdef2
5fe4e7c7 34552f51 993d0d35 92f20d1d b05beb72
120535.373417 Mesg 70 message_recv: 5392faae 6b4bd368 142ffdc9
63a77fff 49769419 e70f0ede 35188f69 fbfb3d51
120535.373865 Mesg 70 message_recv: ab70bc6a 409f14dd d9a27cf0
66eabac1 9f6a819d aad903bb 672d7f3b 6fe66a7f
120535.374313 Mesg 70 message_recv: c791a600 c2fab3f5 d97ce66a
5d33bad0 1ed813cc bb5d31dc cdef4e2d 3cb1446e
120535.374760 Mesg 70 message_recv: 53d4c9bb 933d3d80 7c5d7d30
cc47a053 2c9ab203 66f41e4b 55e546c7 3ad85566
120535.375209 Mesg 70 message_recv: baed439e 3f711ea5 c4317d70
7c67823e c2f52df3 8006794e bfc54895 e5788b7e
(Continue reading)

Permalink | Reply | 0 comments |

Gmane