Re: Connecting to L2TP over IPsec VPN on OpenBSD 6.1 with Ubuntu 16.04

[Stuart Henderson]

On 2018-09-07, Alexander Skwar  wrote:
> Hello
>
> We use a L2TP over IPsec VPN running on OpenBSD 6.1, which was setup
> by prior sysadmins. They are no longer at the company.
>
> Now a user running Ubuntu 16.04 + Gnome tries to connect to the VPN.
> The VPN client (on Linux side) was configured with NetworkManager.
>
> The connection fails. In /var/log/daemon log on the openbsd system,
> there's then (also on https://pastebin.com/xyS6UMsn):
>
> Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
> Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
> Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> ENCRYPTION_ALGORITHM: got 3DES_CBC, expected AES_CBC
> Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> GROUP_DESCRIPTION: got MODP_1536, expected MODP_1024
> Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> HASH_ALGORITHM: got MD5, expected SHA
> Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
> Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
> Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
> GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
> Sep  7 09:46:41 apu isakmpd[69488]: message_negotiate_sa: no
> compatible proposal found
> Sep  7 09:46:41 apu isakmpd[69488]: dropped message from 212.25.17.146
> port 57092 due to notification type NO_PROPOSAL_CHOSEN
>
> Connections from Android, iOS and Mac work just fine. That's the
> first linux user trying to connect.
>
> The ipsec.conf (https://pastebin.com/3gmQR0iN) is:
>
> vpn_ext="redacted"
>
> ike passive esp transport \
> proto udp from { $vpn_ext } to any port 1701 \
> main auth "hmac-sha" enc "aes" group modp1024 \
> quick auth "hmac-sha" enc "aes" \
> psk "redacted"
>
> ike passive esp transport \
> proto udp from { $vpn_ext } to any port 1701 \
> main auth "hmac-sha" enc "3des" group modp1024 \
> quick auth "hmac-sha" enc "3des" \
> psk "redacted"
>
> ike passive esp transport \
> proto udp from { $vpn_ext } to any port 1701 \
> main auth "hmac-sha" enc "3des" group modp1024 \
> quick auth "hmac-sha" enc "aes" \
> psk "redacted"
>
> (vpn_ext and psk are of course not "redacted" in reality.)
>
> Well, uhm, anyone got an idea about what might be the cause of
> this issue?
>
> Thanks a lot,
>
> Alexander
>
>

This type of setup with "to any" uses what is called the "default
peer" which there is only one of, here you're defining it with one
set of ciphers/PFS (main aes/sha, pfs modp1024, quick aes/sha),
then redefining it with a different one (3des/sha/modp1024, 3des/sha),
then again with (3des/sha/modp1024, aes/sha). i.e. the first two
configuration blocks in your file are doing nothing.

The simple fix (that won't break anything currently working) would
be to configure Linux to use the same crypto as you've actually
got configured here, i.e. main: hmac-sha / 3des, PFS modp1024 (group 2),
and quick: hmac-sha / aes.

That is using pretty weak crypto though so it may be better to keep
Linux as-is and try this instead, see if your various clients still
connect:

ike passive esp transport \
proto udp from { $vpn_ext } to any port 1701 \
main auth "hmac-sha" enc "aes" group modp2048 \   
quick auth "hmac-sha" enc "aes" \
psk "redacted"

That's more likely to work with your Linux client, and I've had a
setup with similar settings with Android/iOS and I think
also Windows.

Connecting to L2TP over IPsec VPN on OpenBSD 6.1 with Ubuntu 16.04

[Alexander Skwar]

Hello

We use a L2TP over IPsec VPN running on OpenBSD 6.1, which was setup
by prior sysadmins. They are no longer at the company.

Now a user running Ubuntu 16.04 + Gnome tries to connect to the VPN.
The VPN client (on Linux side) was configured with NetworkManager.

The connection fails. In /var/log/daemon log on the openbsd system,
there's then (also on https://pastebin.com/xyS6UMsn):

Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
ENCRYPTION_ALGORITHM: got 3DES_CBC, expected AES_CBC
Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
GROUP_DESCRIPTION: got MODP_1536, expected MODP_1024
Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
HASH_ALGORITHM: got MD5, expected SHA
Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC
Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
Sep  7 09:46:41 apu isakmpd[69488]: attribute_unacceptable:
GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024
Sep  7 09:46:41 apu isakmpd[69488]: message_negotiate_sa: no
compatible proposal found
Sep  7 09:46:41 apu isakmpd[69488]: dropped message from 212.25.17.146
port 57092 due to notification type NO_PROPOSAL_CHOSEN

Connections from Android, iOS and Mac work just fine. That's the
first linux user trying to connect.

The ipsec.conf (https://pastebin.com/3gmQR0iN) is:

vpn_ext="redacted"

ike passive esp transport \
proto udp from { $vpn_ext } to any port 1701 \
main auth "hmac-sha" enc "aes" group modp1024 \
quick auth "hmac-sha" enc "aes" \
psk "redacted"

ike passive esp transport \
proto udp from { $vpn_ext } to any port 1701 \
main auth "hmac-sha" enc "3des" group modp1024 \
quick auth "hmac-sha" enc "3des" \
psk "redacted"

ike passive esp transport \
proto udp from { $vpn_ext } to any port 1701 \
main auth "hmac-sha" enc "3des" group modp1024 \
quick auth "hmac-sha" enc "aes" \
psk "redacted"

(vpn_ext and psk are of course not "redacted" in reality.)

Well, uhm, anyone got an idea about what might be the cause of
this issue?

Thanks a lot,

Alexander

Re: L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?

[Jurjen Oskam]

Hi Philipp,

Thank you - this was exactly what I was missing. I have now gotten it to
work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1),
which strongly suggests my Nexus 6P (all patched) doesn't implement
hmac-sha2-256 correctly.

The irony is that the manpage of isakmpd.policy explains all this
excellently, but I didn't read it because I misunderstood what the manpage
of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run
at boot time via the isakmpd_flags variable in rc.conf.local(8).  Note that
it will probably need to be run with at least the -K option, to avoid
keynote(4) policy checking." I read this as meaning that keynote policy
checking is *always* unwanted when ipsecctl is used, and that you can avoid
policy checking either by not having a policy file at all (in which case
the -K option doesn't matter), or by using the -K option (in which case
it's certain that policy checking never happens).

But now I know better. :)

Thanks,

Jurjen

2017-03-20 9:33 GMT+01:00 Jurjen Oskam :

> Hi Philipp,
>
> Thank you - this was exactly what I was missing. I have now gotten it to
> work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1),
> which strongly suggests my Nexus 6P (all patched) doesn't implement
> hmac-sha2-256 correctly.
>
> The irony is that the manpage of isakmpd.policy explains all this
> excellently, but I didn't read it because I misunderstood what the manpage
> of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run
> at boot time via the isakmpd_flags variable in rc.conf.local(8).  Note that
> it will probably need to be run with at least the -K option, to avoid
> keynote(4) policy checking." I read this as meaning that keynote policy
> checking is *always* unwanted when ipsecctl is used, and that you can avoid
> policy checking either by not having a policy file at all (in which case
> the -K option doesn't matter), or by using the -K option (in which case
> it's certain that policy checking never happens).
>
> But now I know better. :)
>
> Thanks,
>
> Jurjen
>
>
> 2017-03-20 6:08 GMT+01:00 Philipp Buehler  7...@posteo.net>:
>
>> Am 19.03.2017 15:36 schrieb Jurjen Oskam:
>>
>> So, to validate that I'm indeed hitting this bug (and also as a
>>> workaround)
>>> I tried to set up the OpenBSD side to not use SHA2. I haven't been able
>>> to
>>> get this running yet: isakmpd always seems to offer HMAC_SHA2_256.
>>>
>>
>> It's not offering that - but accepting "better" Phase2 transforms. If
>> isakmpd
>> would start the negotiation, it'd propose HMAC_SHA.
>>
>> To keep out unwanted proposals, you need an isakmpd.policy. (hint: no -K)
>>
>> In my eyes this is 'bad behaviour' and tends to lead to situations where
>> e.g.
>> a remote end "upgrades" (and locks down) the transforms and thus rekeying
>> started by isakmpd start to fail.
>>
>> HTH,
>> --
>> pb

Re: L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?

[Philipp Buehler]

Am 19.03.2017 15:36 schrieb Jurjen Oskam:

So, to validate that I'm indeed hitting this bug (and also as a 
workaround)
I tried to set up the OpenBSD side to not use SHA2. I haven't been able 
to

get this running yet: isakmpd always seems to offer HMAC_SHA2_256.


It's not offering that - but accepting "better" Phase2 transforms. If 
isakmpd

would start the negotiation, it'd propose HMAC_SHA.

To keep out unwanted proposals, you need an isakmpd.policy. (hint: no 
-K)


In my eyes this is 'bad behaviour' and tends to lead to situations where 
e.g.
a remote end "upgrades" (and locks down) the transforms and thus 
rekeying

started by isakmpd start to fail.

HTH,
--
pb

L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?

[Jurjen Oskam]

Hi,

I'm trying to set up my OpenBSD 6.0 box as an L2TP/IPsec server for my
Android phone to connect to. It appears that recent Android versions have a
bug that can prevent it to successfully use HMAC_SHA2_256 for its built-in
L2TP/IPsec VPN client. (Whether the bug occurs seems to depend on the
specifics of the Linux kernel that happens to be used for the device. See
https://code.google.com/p/android/issues/detail?id=196939 for more
information).

I suspect I'm hit by this bug. The isakmpd negotiations seem to work fine,
but npppd doesn't see any traffic. When tcpdumping the external interface
of the OpenBSD box, I see incoming encrypted traffic, but on a
simultaneously running tcpdump on the enc0 interface, I see no traffic at
all. This behavior is consistent with the Android bug description: Android
is requesting a SHA2 HMAC, but it is using a DRAFT version that is
incompatible with the final RFC.

So, to validate that I'm indeed hitting this bug (and also as a workaround)
I tried to set up the OpenBSD side to not use SHA2. I haven't been able to
get this running yet: isakmpd always seems to offer HMAC_SHA2_256.

Here is /etc/ipsec.conf:

ike passive esp transport \
  proto udp from egress to any port 1701 \
  main auth "hmac-sha1" enc "aes" group modp1024 \
  quick auth "hmac-sha1" enc "aes" group modp1024 \
  psk "SHARED_SEEKRIT"

With this configuration, isakmpd still offers HMAC_SHA2_256. See a snippet
of the output of tcpdumping the pcap file created by isakmpd below. The "
ziggo.nl" address is OpenBSD, the "static.kpn.net" address is my Android
phone connected to the cellular network):

15:31:00.865423 static.kpn.net.ipsec-nat-t >
5356F312.cm-6-7d.dynamic.ziggo.nl.isakmp: [bad udp cksum e50! -> 74e4]
udpencap: isakmp v1.0 exchange QUICK_MODE
cookie: 0f659aa030f4904d->64d8256cce1ec37b msgid: 8281d122 len: 460
payload: HASH len: 24
payload: SA len: 336 DOI: 1(IPSEC) situation: IDENTITY_ONLY
payload: PROPOSAL len: 324 proposal: 1 proto: IPSEC_ESP spisz:
4 xforms: 12 SPI: 0x0a89e2b7
payload: TRANSFORM len: 28
transform: 1 ID: AES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 28800
attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
attribute KEY_LENGTH = 256
attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256
payload: TRANSFORM len: 28
transform: 2 ID: AES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 28800
attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
attribute KEY_LENGTH = 256
attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
payload: TRANSFORM len: 28
transform: 3 ID: AES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 28800
attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
attribute KEY_LENGTH = 256
attribute AUTHENTICATION_ALGORITHM = HMAC_MD5
payload: TRANSFORM len: 28
transform: 4 ID: AES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 28800
attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
attribute KEY_LENGTH = 128
attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256
payload: TRANSFORM len: 28
transform: 5 ID: AES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 28800
attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
attribute KEY_LENGTH = 128
attribute AUTHENTICATION_ALGORITHM = HMAC_SHA
payload: TRANSFORM len: 28
transform: 6 ID: AES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 28800
attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
attribute KEY_LENGTH = 128
attribute AUTHENTICATION_ALGORITHM = HMAC_MD5
payload: TRANSFORM len: 24
transform: 7 ID: 3DES
attribute LIFE_TYPE = SECONDS
attribute LIFE_DURATION = 28800
attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT
attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256
payload: TRANSFORM len: 24
transform: 8 ID: 3DES
attribute LIFE_TYPE = SECONDS
  

Re: How to configure OpenBSD L2TP/IPSEC VPN to work with Windows 10?

[Sebastian Wain]

That ipsec.conf works perfectly if I am connecting to the VPN from the LAN
but doesn't work if I put the VPN behind a router doing NAT and redirecting
ports 500 and 4500 to the VPN server. In this case this is logged:

192.168.1.35 is the IP of the machine behind the router at 221.12.3.4 which
is trying to connect to the VPN through the router at 200.1.32.22)

 Aug  6 10:10:19 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 192.168.1.35, responder id
200.1.32.22
 Aug  6 10:10:19 fw isakmpd[7947]: dropped message from 221.12.3.4 port
4500 due to notification type INVALID_ID_INFORMATION
 Aug  6 10:10:34 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 192.168.1.35, responder id
200.1.32.22
 Aug  6 10:10:34 fw isakmpd[7947]: dropped message from 221.12.3.4 port
4500 due to notification type INVALID_ID_INFORMATION
 Aug  6 10:11:16 fw isakmpd[7947]: transport_send_messages: giving up on
exchange peer-default, no response from peer 221.12.3.4:500

Thanks,
Sebastian

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
R0me0 ***
Sent: Thursday, August 4, 2016 1:57 PM
To: Sebastian Wain <sebastian.w...@nektra.com>
Cc: OpenBSD misc <misc@openbsd.org>
Subject: Re: How to configure OpenBSD L2TP/IPSEC VPN to work with Windows
10?

ike passive esp transport proto udp from egress to 0.0.0.0/0 port 1701 \
   main auth hmac-sha1 enc 3des group modp2048 \
   quick auth hmac-sha1 enc 3des psk "YOURSECRET"


You are welcome

(:

2016-08-04 13:15 GMT-03:00 Sebastian Wain <sebastian.w...@nektra.com>:

> I can't figure out how to make an OpenBSD VPN work. I followed the 
> guide at [1] to set up a VPN, modified the network interface there to 
> tun0 instead of pppoe0, and didn't configure the pf.conf. When I tried 
> to connect from Win10 using the "L2TP/IPsec with pre-shared key" VPN 
> type I see the issues below in phase
> 2:
>
> Thanks
> Sebastian
>
> [1] http://blog.fuckingwith.it/2015/08/openbsd-l2tpipsec-vpn-
> works-with.html
>
> Aug  3 responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2
IDs:
> initiator id 192.168.0.129, responder id 192.168.0.253
> Aug  3 11:17:13 fw isakmpd[7947]: dropped message from 
> 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:14 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: 
> peer proposed invalid phase 2 IDs: initiator id 192.168.0.129, 
> responder id
> 192.168.0.253
> Aug  3 11:17:14 fw isakmpd[7947]: dropped message from 
> 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:15 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: 
> peer proposed invalid phase 2 IDs: initiator id 192.168.0.129, 
> responder id
> 192.168.0.253
> Aug  3 11:17:15 fw isakmpd[7947]: dropped message from 
> 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:18 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: 
> peer proposed invalid phase 2 IDs: initiator id 192.168.0.129, 
> responder id
> 192.168.0.253
> Aug  3 11:17:18 fw isakmpd[7947]: dropped message from 
> 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:25 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: 
> peer proposed invalid phase 2 IDs: initiator id 192.168.0.129, 
> responder id
> 192.168.0.253
> Aug  3 11:17:25 fw isakmpd[7947]: dropped message from 
> 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:40 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: 
> peer proposed invalid phase 2 IDs: initiator id 192.168.0.129, 
> responder id
> 192.168.0.253
> Aug  3 11:17:40 fw isakmpd[7947]: dropped message from 
> 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:55 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: 
> peer proposed invalid phase 2 IDs: initiator id 192.168.0.129, 
> responder id
> 192.168.0.253
> Aug  3 11:17:55 fw isakmpd[7947]: dropped message from 
> 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:18:38 fw isakmpd[7947]: transport_send_messages: giving 
> up on exchange peer-default, no response from peer 192.168.0.129:500

Re: How to configure OpenBSD L2TP/IPSEC VPN to work with Windows 10?

[R0me0 ***]

Take a look on router config.
Some routers you need enable "VPN passthrough" "ipsec" something like that,
get the router manual. In the worst case perform DMZ pointing everything to
OpenBSD box ( I particularly prefer this one )

2016-08-06 16:43 GMT-03:00 Sebastian Wain <sebastian.w...@nektra.com>:

> That ipsec.conf works perfectly if I am connecting to the VPN from the LAN
> but doesn't work if I put the VPN behind a router doing NAT and redirecting
> ports 500 and 4500 to the VPN server. In this case this is logged:
>
> 192.168.1.35 is the IP of the machine behind the router at 221.12.3.4 which
> is trying to connect to the VPN through the router at 200.1.32.22)
>
>  Aug  6 10:10:19 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
> proposed invalid phase 2 IDs: initiator id 192.168.1.35, responder id
> 200.1.32.22
>  Aug  6 10:10:19 fw isakmpd[7947]: dropped message from 221.12.3.4 port
> 4500 due to notification type INVALID_ID_INFORMATION
>  Aug  6 10:10:34 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
> proposed invalid phase 2 IDs: initiator id 192.168.1.35, responder id
> 200.1.32.22
>  Aug  6 10:10:34 fw isakmpd[7947]: dropped message from 221.12.3.4 port
> 4500 due to notification type INVALID_ID_INFORMATION
>  Aug  6 10:11:16 fw isakmpd[7947]: transport_send_messages: giving up
> on
> exchange peer-default, no response from peer 221.12.3.4:500
>
> Thanks,
> Sebastian
>
> -Original Message-
> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
> R0me0 ***
> Sent: Thursday, August 4, 2016 1:57 PM
> To: Sebastian Wain <sebastian.w...@nektra.com>
> Cc: OpenBSD misc <misc@openbsd.org>
> Subject: Re: How to configure OpenBSD L2TP/IPSEC VPN to work with Windows
> 10?
>
> ike passive esp transport proto udp from egress to 0.0.0.0/0 port 1701 \
>main auth hmac-sha1 enc 3des group modp2048 \
>quick auth hmac-sha1 enc 3des psk "YOURSECRET"
>
>
> You are welcome
>
> (:
>
> 2016-08-04 13:15 GMT-03:00 Sebastian Wain <sebastian.w...@nektra.com>:
>
> > I can't figure out how to make an OpenBSD VPN work. I followed the
> > guide at [1] to set up a VPN, modified the network interface there to
> > tun0 instead of pppoe0, and didn't configure the pf.conf. When I tried
> > to connect from Win10 using the "L2TP/IPsec with pre-shared key" VPN
> > type I see the issues below in phase
> > 2:
> >
> > Thanks
> > Sebastian
> >
> > [1] http://blog.fuckingwith.it/2015/08/openbsd-l2tpipsec-vpn-
> > works-with.html
> >
> > Aug  3 responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2
> IDs:
> > initiator id 192.168.0.129, responder id 192.168.0.253
> > Aug  3 11:17:13 fw isakmpd[7947]: dropped message from
> > 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> > Aug  3 11:17:14 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE:
> > peer proposed invalid phase 2 IDs: initiator id 192.168.0.129,
> > responder id
> > 192.168.0.253
> > Aug  3 11:17:14 fw isakmpd[7947]: dropped message from
> > 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> > Aug  3 11:17:15 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE:
> > peer proposed invalid phase 2 IDs: initiator id 192.168.0.129,
> > responder id
> > 192.168.0.253
> > Aug  3 11:17:15 fw isakmpd[7947]: dropped message from
> > 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> > Aug  3 11:17:18 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE:
> > peer proposed invalid phase 2 IDs: initiator id 192.168.0.129,
> > responder id
> > 192.168.0.253
> > Aug  3 11:17:18 fw isakmpd[7947]: dropped message from
> > 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> > Aug  3 11:17:25 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE:
> > peer proposed invalid phase 2 IDs: initiator id 192.168.0.129,
> > responder id
> > 192.168.0.253
> > Aug  3 11:17:25 fw isakmpd[7947]: dropped message from
> > 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> > Aug  3 11:17:40 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE:
> > peer proposed invalid phase 2 IDs: initiator id 192.168.0.129,
> > responder id
> > 192.168.0.253
> > Aug  3 11:17:40 fw isakmpd[7947]: dropped message from
> > 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> > Aug  3 11:17:55 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE:
> > peer proposed invalid phase 2 IDs: initiator id 192.168.0.129,
> > responder id
> > 192.168.0.253
> > Aug  3 11:17:55 fw isakmpd[7947]: dropped message from
> > 192.168.0.129 port 500 due to notification type INVALID_ID_INFORMATION
> > Aug  3 11:18:38 fw isakmpd[7947]: transport_send_messages: giving
> > up on exchange peer-default, no response from peer 192.168.0.129:500

Re: How to configure OpenBSD L2TP/IPSEC VPN to work with Windows 10?

[R0me0 ***]

ike passive esp transport proto udp from egress to 0.0.0.0/0 port 1701 \
   main auth hmac-sha1 enc 3des group modp2048 \
   quick auth hmac-sha1 enc 3des psk "YOURSECRET"


You are welcome

(:

2016-08-04 13:15 GMT-03:00 Sebastian Wain :

> I can't figure out how to make an OpenBSD VPN work. I followed the guide at
> [1] to set up
> a VPN, modified the network interface there to tun0 instead of pppoe0, and
> didn't
> configure the pf.conf. When I tried to connect from Win10 using the
> "L2TP/IPsec with pre-shared key" VPN type I see the issues below in phase
> 2:
>
> Thanks
> Sebastian
>
> [1] http://blog.fuckingwith.it/2015/08/openbsd-l2tpipsec-vpn-
> works-with.html
>
> Aug  3 responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs:
> initiator id 192.168.0.129, responder id 192.168.0.253
> Aug  3 11:17:13 fw isakmpd[7947]: dropped message from 192.168.0.129
> port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:14 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
> proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
> 192.168.0.253
> Aug  3 11:17:14 fw isakmpd[7947]: dropped message from 192.168.0.129
> port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:15 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
> proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
> 192.168.0.253
> Aug  3 11:17:15 fw isakmpd[7947]: dropped message from 192.168.0.129
> port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:18 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
> proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
> 192.168.0.253
> Aug  3 11:17:18 fw isakmpd[7947]: dropped message from 192.168.0.129
> port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:25 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
> proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
> 192.168.0.253
> Aug  3 11:17:25 fw isakmpd[7947]: dropped message from 192.168.0.129
> port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:40 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
> proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
> 192.168.0.253
> Aug  3 11:17:40 fw isakmpd[7947]: dropped message from 192.168.0.129
> port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:17:55 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
> proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
> 192.168.0.253
> Aug  3 11:17:55 fw isakmpd[7947]: dropped message from 192.168.0.129
> port 500 due to notification type INVALID_ID_INFORMATION
> Aug  3 11:18:38 fw isakmpd[7947]: transport_send_messages: giving up on
> exchange peer-default, no response from peer 192.168.0.129:500

How to configure OpenBSD L2TP/IPSEC VPN to work with Windows 10?

[Sebastian Wain]

I can't figure out how to make an OpenBSD VPN work. I followed the guide at
[1] to set up
a VPN, modified the network interface there to tun0 instead of pppoe0, and
didn't
configure the pf.conf. When I tried to connect from Win10 using the
"L2TP/IPsec with pre-shared key" VPN type I see the issues below in phase 2:

Thanks
Sebastian

[1] http://blog.fuckingwith.it/2015/08/openbsd-l2tpipsec-vpn-works-with.html

Aug  3 responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs:
initiator id 192.168.0.129, responder id 192.168.0.253
Aug  3 11:17:13 fw isakmpd[7947]: dropped message from 192.168.0.129
port 500 due to notification type INVALID_ID_INFORMATION
Aug  3 11:17:14 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
192.168.0.253
Aug  3 11:17:14 fw isakmpd[7947]: dropped message from 192.168.0.129
port 500 due to notification type INVALID_ID_INFORMATION
Aug  3 11:17:15 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
192.168.0.253
Aug  3 11:17:15 fw isakmpd[7947]: dropped message from 192.168.0.129
port 500 due to notification type INVALID_ID_INFORMATION
Aug  3 11:17:18 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
192.168.0.253
Aug  3 11:17:18 fw isakmpd[7947]: dropped message from 192.168.0.129
port 500 due to notification type INVALID_ID_INFORMATION
Aug  3 11:17:25 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
192.168.0.253
Aug  3 11:17:25 fw isakmpd[7947]: dropped message from 192.168.0.129
port 500 due to notification type INVALID_ID_INFORMATION
Aug  3 11:17:40 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
192.168.0.253
Aug  3 11:17:40 fw isakmpd[7947]: dropped message from 192.168.0.129
port 500 due to notification type INVALID_ID_INFORMATION
Aug  3 11:17:55 fw isakmpd[7947]: responder_recv_HASH_SA_NONCE: peer
proposed invalid phase 2 IDs: initiator id 192.168.0.129, responder id
192.168.0.253
Aug  3 11:17:55 fw isakmpd[7947]: dropped message from 192.168.0.129
port 500 due to notification type INVALID_ID_INFORMATION
Aug  3 11:18:38 fw isakmpd[7947]: transport_send_messages: giving up on
exchange peer-default, no response from peer 192.168.0.129:500

Android 4.4 and L2TP/IPSEC VPN

[Kaya Saman]

Hi,

I'm wondering if anyone has had any experience with VPN and Android 4.4??

I used to use OpenVPN with versions 4.1 through 4.3 however, 4.4 
apparently broke the tun interface so the app doesn't work now.

As I need vpn access I configured ipsec and npppd however, I keep 
getting these errors when trying to establish connection:

responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: 
initiator id 2.2.2.2, responder id 1.1.1.1

dropped message from 2.2.2.2 port 500 due to notification type 
INVALID_ID_INFORMATION

ok my IP range is different but the error still stands where phone is 
2.2.2.2 and OpenBSD IP is 1.1.1.1


On the Droid I setup L2TP/IPsec PSK

with server address and IPSec PSK; and my npppd credentials.


The config I have is standard:

ipsec.conf:

ike passive esp transport \
 proto udp from any to any port 1701  \
 main auth hmac-sha1 enc aes group modp1024 \
 quick auth hmac-sha1 enc aes \
 psk some_key


npppd.conf:

# $OpenBSD: npppd.conf,v 1.2 2014/03/22 04:32:39 yasuoka Exp $
# sample npppd configuration file.  see npppd.conf(5)

authentication LOCAL type local {
 users-file /etc/npppd/npppd-users
}
#authentication RADIUS type radius {
#   authentication-server {
#   address 192.168.0.1 secret hogehoge
#   }
#   accounting-server {
#   address 192.168.0.1 secret hogehoge
#   }
#}

tunnel L2TP protocol l2tp {
 listen on 0.0.0.0
 listen on ::
}

ipcp IPCP {
 pool-address vpn_ip_pool
 dns-servers dns_pool
}

# I elected to go with Tun interface over Pipex

# use tun(4) interface.  multiple ppp sessions concentrate one interface.
interface tun1  address ip ipcp IPCP
bind tunnel from L2TP authenticated by LOCAL to tun1

/etc/hostname.tun1
up


Looking through the @Misc archive I found a similar issue:

http://permalink.gmane.org/gmane.os.openbsd.misc/202338

which also incorporates (I assume) working config; very similar to my own.


My version of OpenBSD is: 5.5 GENERIC.MP#50 amd64 (Current as of a few 
days ago)


The Phase 2 ID issues usually happen when the devices remote and local 
IP addresses aren't what the system is expecting however, I have 
configured this to any.

I do recall a separate issue I had when configuring IPSEC/GRE 
site-to-site tunnel with Cisco's where I had to specifically set:

ike esp from 0.0.0.0/0 to 0.0.0.0/0 peer ip_address

and then configure hostname.greX accordingly.


Even using the Pipex interface:

#interface pppx0 address vpn_ip ipcp IPCP
#bind tunnel from L2TP authenticated by LOCAL to pppx0


as a test I still get the same error of Invalid Phase 2 ID's.

I have analyzed /var/log/messages which gives above output, and in 
addition done a tcpdump -eni (IF) -vvv host (IP) to see what was going 
on but found nothing substantial


npppd output:

npppd[10593]: l2tpd ctrl=9 logtype=Started RecvSCCRQ 
from=2.2.2.2:46783/udp tunnel_id=9/30318 protocol=1.0 winsize=1 
hostname=anonymous vendor=(no vendorname) firm=

npppd[10593]: l2tpd ctrl=9 timeout waiting ack for ctrl packets.

npppd[10593]: l2tpd ctrl=9 logtype=Finished


Could this be a bug with Android 4.4 or is it simply something 
misconfigured on my behalf?

...oh and my handset is rooted so I don't know if that makes a difference?


Thanks.


Kaya

Re: IPSec VPN with iked (8)

[Jan Lambertz]

There is a post of my findings in the archives. Android 2.3 worked fine
with iked and npppd

IPSec VPN with iked (8)

[Benjamin Epitech]

Hello,

I am new to the concept of IPSec VPNs and although there are many tutorials
to set one up with isakmp (8), I find there is less resources on setting up
one with the newer iked.

Can someone give me the main steps required to set up an IPSec VPN with
iked? I understand this is still under development, but what are its
limitations? Would it work with Android phones and Windows 8.1?

I generated some keys using the examples in the iked presentation, I wrote
a very simple and nonrestrictive iked.conf and launched iked. Now what? I
have no idea what to do and I would really want to try it.

Thanks,
Ben.

Re: IPSec VPN with iked (8)

[Stuart Henderson]

On 2013-11-25, Benjamin Epitech mlspira...@gmail.com wrote:
 Hello,

 I am new to the concept of IPSec VPNs and although there are many tutorials
 to set one up with isakmp (8), I find there is less resources on setting up
 one with the newer iked.

 Can someone give me the main steps required to set up an IPSec VPN with
 iked? I understand this is still under development, but what are its
 limitations? Would it work with Android phones and Windows 8.1?

 I generated some keys using the examples in the iked presentation, I wrote
 a very simple and nonrestrictive iked.conf and launched iked. Now what? I
 have no idea what to do and I would really want to try it.

 Thanks,
 Ben.



For Android phones the standard way to do VPNs is l2tp-over-ipsec (IKE).
You can do this with npppd and isakmpd (iked is for IKEv2 which is not
compatible with IKE).

There was an old undeadly post with information about server-side setup,
but the configuration syntax has changed since then; try these slides
for something more current:

http://www.slideshare.net/GiovanniBechis/npppd-easy-vpn-with-openbsd

This should also work with Windows where setup looks something like
http://torguard.net/knowledgebase.php?action=displayarticleid=67

Re: IPSec VPN with iked (8)

[Benjamin Epitech]

On Mon, Nov 25, 2013 at 1:21 PM, Stuart Henderson s...@spacehopper.orgwrote:

 For Android phones the standard way to do VPNs is l2tp-over-ipsec (IKE).
 You can do this with npppd and isakmpd (iked is for IKEv2 which is not
 compatible with IKE).


Apparently someone made an Android app to support IKEv2 (
https://play.google.com/store/apps/details?id=org.strongswan.android).
Might be a good occasion to test iked with it.


 There was an old undeadly post with information about server-side setup,
 but the configuration syntax has changed since then; try these slides
 for something more current:

 http://www.slideshare.net/GiovanniBechis/npppd-easy-vpn-with-openbsd


Awesome, I definitely need to try this out.

Thanks.

routing to IPsec VPN with dummy lo1 broken

[Christopher Zimmermann]

Hi,

My IPsec roadwarrior setup on my laptop broke with one of the latest
snapshots because some outgoing connections are routed wrongly with a
source ip of 127.0.0.1.

On the roadwarrior laptop I use a dummy lo1 interface to which I assign
the internal VPN IP of the laptop.
wlan has the 172.26.153.40/28 subnet, VPN has the 172.26.153.49/28
subnet:

iwn0: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 00:21:6b:a3:70:7a
priority: 4
groups: wlan
status: active
inet 172.26.153.40 netmask 0xfff0 broadcast 172.26.153.47
enc0: flags=0
priority: 0
groups: enc
status: active
lo1: flags=8149UP,LOOPBACK,RUNNING,PROMISC,MULTICAST mtu 33144
priority: 0
groups: lo egress
inet 172.26.153.49 netmask 0xfff0
inet6 fe80::1%lo1 prefixlen 64 scopeid 0x5
inet6 2001:4dd0:fbdf:8::49 prefixlen 48

Routing tables

default route goes to the VPN. Because the IPsec flow matches on
source ip, all VPN packets are routed via lo1 to assign the right
source ip:

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default172.26.153.49  US 1   62 33144 9 lo1
127/8  127.0.0.1  UGRS   00 33144 8 lo0
127.0.0.1  127.0.0.1  UH 2   36 33144 4 lo0
172.26.153.32/28   link#2 UC 10 - 4 iwn0
172.26.153.33  00:1b:b1:f2:f4:6d  UHLc   10 - 4 iwn0
172.26.153.40  127.0.0.1  UGS00 33144 8 lo0
172.26.153.49  172.26.153.49  UH 0  120 33144 4 lo1
217.190.94.19  172.26.153.33  UGHS   2  215 -12 iwn0
224/4  127.0.0.1  URS00 33144 8 lo0

And route get seems to do the right thing:

$ route get 172.26.153.1
   route to: alix
destination: default
   mask: default
  interface: lo1
 if address: mortimer-ipsec (= 172.26.153.49)
   priority: 9 ()
  flags: UP,DONE,STATIC
 use   mtuexpire
  68 33144 0

In the following tests I run two tcpdumps in the background:

tcpdump: listening on pflog0, link-type PFLOG
tcpdump: listening on enc0, link-type ENC

ICMP echo requests get assigned the correct source ip and are
redirected to IPsec:

$ ping -c1 172.26.153.1
PING 172.26.153.1 (172.26.153.1): 56 data bytes
64 bytes from 172.26.153.1: icmp_seq=0 ttl=255 time=2.635 ms
--- 172.26.153.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 2.635/2.635/2.635/0.000 ms

(authentic,confidential): SPI 0x754c6616: 172.26.153.49  172.26.153.1: icmp:
echo request (encap)
(authentic,confidential): SPI 0x9464175d: 172.26.153.1  172.26.153.49: icmp:
echo reply (encap)

But udp/tcp packets get assigned the localhost(!) address and are
blocked by pf, because I disallow any traffic on lo1:

$ nc -u 172.26.153.1 53 /dev/zero

rule 3/(match) block out on lo1: 127.0.0.1.3621  172.26.153.1.53: 0 [0q]
(2048)

[demime 1.01d removed an attachment of type application/pgp-signature]

Re: routing to IPsec VPN with dummy lo1 broken

[Christopher Zimmermann]

On Tue, 2 Jul 2013 10:26:40 +0200
Christopher Zimmermann chr...@openbsd.org wrote:

 Hi,
 
 My IPsec roadwarrior setup on my laptop broke with one of the latest
 snapshots because some outgoing connections are routed wrongly with a
 source ip of 127.0.0.1.

I was wrong in assuming a recent change to the kernel is causing this.
I can reproduce this behaviour with a kernel from 13-05-01 and I'm
pretty sure it did work just fine back then.
Still this looks like a bug to me. ICMP messages being routed with the
correct source ip just fine, but udp and tcp getting a source ip of
127.0.0.1 while leaving on interface lo1 which only has the
172.26.153.49 ip assigned.

Christopherd

Re: routing to IPsec VPN with dummy lo1 broken

[Christopher Zimmermann]

On Tue, 2 Jul 2013 10:26:40 +0200
Christopher Zimmermann chr...@openbsd.org wrote:

 Hi,
 
 My IPsec roadwarrior setup on my laptop broke with one of the latest
 snapshots because some outgoing connections are routed wrongly with a
 source ip of 127.0.0.1.

I found the according line in the source:
netinet/in_pcb.c:836

/*
 * If we found a route, use the address
 * corresponding to the outgoing interface
 * unless it is the loopback (in case a route
 * to our address on another net goes to loopback).
 */
if (ro-ro_rt  ro-ro_rt-rt_ifp 
!(ro-ro_rt-rt_ifp-if_flags  IFF_LOOPBACK)) /* XXX Don't use address of 
any loopback interface */
ia = ifatoia(ro-ro_rt-rt_ifa);
if (ia == 0) {
u_int16_t fport = sin-sin_port;

sin-sin_port = 0;
ia = ifatoia(ifa_ifwithdstaddr(sintosa(sin), rtableid));
if (ia == 0)
ia = ifatoia(ifa_ifwithnet(sintosa(sin), rtableid));
sin-sin_port = fport;
if (ia == 0)
ia = TAILQ_FIRST(in_ifaddr); /* XXX Now use the address of the 
FIRST loopback interface anyways ?!? */
if (ia == 0) {
*errorp = EADDRNOTAVAIL;
return NULL;
}
}

Is this reasonable not to use address of loopback interfaces?
Also this codepath only affects udp/tcp, but NOT icmp.
The icmp codepath will use the address of loopback interfaces.

Christopher

External IP address not to go through IPSec VPN

[ML mail]

Hi,

I have setted up a simple IPSec VPN using the following instructions:

http://www.symantec.com/connect/articles/zero-ipsec-4-minutes

and have noticed that not only my internal networks get routed through the VPN 
but also the external IP address of both firewalls. I would like the external 
IP address of the firewalls to go through the internet and not the VPN. Is this 
kind of configuration possible? If yes how?

Regards,
ML

Re: IPSEC VPN performance

[David Coppa]

On Mon, Oct 1, 2012 at 5:55 PM, Russell Garrison
russell.garri...@gmail.com wrote:
 Is iPerf running threaded? What about dd to null and a loopback listener?

Beware: only -current (since Tue Sep 25) net/iperf port has threading enabled.

ciao,
David

Re: IPSEC VPN performance

[Christiano F. Haesbaert]

On 2 October 2012 08:57, David Coppa dco...@gmail.com wrote:
 On Mon, Oct 1, 2012 at 5:55 PM, Russell Garrison
 russell.garri...@gmail.com wrote:
 Is iPerf running threaded? What about dd to null and a loopback listener?

 Beware: only -current (since Tue Sep 25) net/iperf port has threading enabled.

 ciao,
 David


Why not using tcpbench where you can actually specify the parameters
and know what is going on :).

Play with buffer sizes and you'll see a big difference, using -u will
give you the actual PPS.

Re: IPSEC VPN performance

[Ryan McBride]

On Tue, Oct 02, 2012 at 09:59:05AM +0200, Christiano F. Haesbaert wrote:
 Why not using tcpbench where you can actually specify the parameters
 and know what is going on :).
 
 Play with buffer sizes and you'll see a big difference, using -u will
 give you the actual PPS.

I agree with this.

Also, if you want to compare with other people's you should use the same
tools and specific settings such as buffer sizes.  Otherwise, no point
in comparing and just decide on your own if 600Mbps with netcat is good
enough for you.

As I mentiend in http://marc.info/?l=openbsd-miscm=134033767126930,
I tested with tcpbench -B 262144 -S 262144 -n 10

Re: IPSEC VPN performance

[Reyk Floeter]

On Tue, Oct 2, 2012 at 9:59 AM, Christiano F. Haesbaert
haesba...@haesbaert.org wrote:
 Why not using tcpbench where you can actually specify the parameters
 and know what is going on :).

 Play with buffer sizes and you'll see a big difference, using -u will
 give you the actual PPS.


I agree, I stopped using Iperf after tcpbench was in our tree and
ready (I think it was at n2k8). Nice tool.

While Iperf and tcpbench are good for testing the single- or even
multi-TCP stream performance of the local test systems A and B, I
wouldn't really count on them to test the real routing performance of
a Device-Under-Test C in the middle. It is really hard to get
meaningful max. PPS numbers, especially when you want to max out
Gigabit or start playing with 10G. There will always be the
limitations of the software and network stack of the test systems that
will have difficulties to generate enough PPS to threaten a modern
OpenBSD router (OK, IPsec is a different story...). A normal OpenBSD
router does not involve any networking in userland which makes it MUCH
faster than anything you can test with these tools. Of course, you can
use many hosts on the A side or some fancy kernel-based packet
generators, but this still doesn't give you any numbers because you
will have to receive the packets and analyze the results somewhere on
the B side... (and you simply cannot rely on systat if running on
the OpenBSD router for that - another very basic but non-satisfying
workaround would be to look at the performance counters of a managed
switch in the middle).

Most network and security vendors and larger data centers use these
insanely expensive appliances for network performance testing that use
FPGAs and customs chips to handle the load and give you accurate
numbers. Many other vendors just depend on software testing, lie,
round up or just make up numbers. These appliances can even test IPsec
performance with thousands of simulated tunnels and/or millions of PPS
and max. Mbps. We used to have an Ixia in my former company and it
really helped to find and eliminate some bottlenecks in OpenBSD. We
also tested IPsec performance on amd64, but this was before AES-NI and
iked and I don't remember the numbers. Pure routing performance could
go up to around 9Gbps on fast servers, but only with larger packets
(1k-1.5k, not counting jumbos) because the max. PPS in OpenBSD was
magically limited at this point (again, this is almost two years ago
and many improvements happened afterwards). I would be very interested
in getting updated numbers but I don't have access to such an
appliance anymore.

In summary, it is fine to run Iperf/tcpbench for getting an idea about
your router performance up to a few hundred Mbps, but these numbers
are not perfect and can go totally wrong when you reach Gigabit or
10G.

Reyk

Re: IPSEC VPN performance

[Jim Miller]

I just reran the test again.  I still receive about 600Mbps using iPerf
however using

client
# dd if=/dev/zero bs=1000 count=100 | nc -v 172.16.2.2 12345

server
# nc -v -l 12345  /dev/null

I get numbers around 350Mbps.  I tend to think iPerf is more reliable in
this situation. 
Any ideas why the tests vary so much?
-Jim

On 9/28/12 9:18 PM, Ryan McBride wrote:
 600Mbps seems about right, I tested a pair of E5649-based boxes to
 550Mbps last year (with aes-128-gcm):

 http://marc.info/?l=openbsd-miscm=134033767126930

 You'll probably get slightly more than 600 with with multiple TCP
 streams. 

 Assuming PF was enabled for your test (the default configuration), the
 performance should be about the same with a proper ruleset. Traffic for
 existing states won't hit the ruleset at all.


 On Fri, Sep 28, 2012 at 06:39:14PM -0400, Jim Miller wrote:
 Yes.  Let me double check everything again on Monday.  Keep in mind that
 all devices had 1Gb ethernet interfaces and everything was directly
 cabled.  No pf rules either.  w/o ipsec I could get 900mbps through the
 openbsd boxes.

 Now you've got me thinking I need to recheck everything.

 -Jim

 On 9/28/12 5:19 PM, Hrvoje Popovski wrote:
 Hi,

 On 28.9.2012 22:09, Jim Miller wrote:
 So using another Mac w/ 1Gb ethernet adapter to a Linux box w/ 1Gb eth I
 was able to achieve approx. 600Mbps performance through the test setup
 (via iperf and my dd method).  

 600Mbps via ipsec between two Intel E31220 ?

Re: IPSEC VPN performance

[Otto Moerbeek]

On Mon, Oct 01, 2012 at 11:20:06AM -0400, Jim Miller wrote:

 I just reran the test again.  I still receive about 600Mbps using iPerf
 however using
 
 client
 # dd if=/dev/zero bs=1000 count=100 | nc -v 172.16.2.2 12345
 
 server
 # nc -v -l 12345  /dev/null
 
 I get numbers around 350Mbps.  I tend to think iPerf is more reliable in
 this situation. 
 Any ideas why the tests vary so much?

I suspect nc does less efficient buffering.

-Otto

 -Jim
 
 On 9/28/12 9:18 PM, Ryan McBride wrote:
  600Mbps seems about right, I tested a pair of E5649-based boxes to
  550Mbps last year (with aes-128-gcm):
 
  http://marc.info/?l=openbsd-miscm=134033767126930
 
  You'll probably get slightly more than 600 with with multiple TCP
  streams. 
 
  Assuming PF was enabled for your test (the default configuration), the
  performance should be about the same with a proper ruleset. Traffic for
  existing states won't hit the ruleset at all.
 
 
  On Fri, Sep 28, 2012 at 06:39:14PM -0400, Jim Miller wrote:
  Yes.  Let me double check everything again on Monday.  Keep in mind that
  all devices had 1Gb ethernet interfaces and everything was directly
  cabled.  No pf rules either.  w/o ipsec I could get 900mbps through the
  openbsd boxes.
 
  Now you've got me thinking I need to recheck everything.
 
  -Jim
 
  On 9/28/12 5:19 PM, Hrvoje Popovski wrote:
  Hi,
 
  On 28.9.2012 22:09, Jim Miller wrote:
  So using another Mac w/ 1Gb ethernet adapter to a Linux box w/ 1Gb eth I
  was able to achieve approx. 600Mbps performance through the test setup
  (via iperf and my dd method).  
 
  600Mbps via ipsec between two Intel E31220 ?

Re: IPSEC VPN performance

[Janne Johansson]

Perhaps the pipe size causes degradations, I seem to recall getting better
results on benchmarks without pipes.
Den 1 okt 2012 18:07 skrev Otto Moerbeek o...@drijf.net:

 On Mon, Oct 01, 2012 at 11:20:06AM -0400, Jim Miller wrote:

  I just reran the test again.  I still receive about 600Mbps using iPerf
  however using
 
  client
  # dd if=/dev/zero bs=1000 count=100 | nc -v 172.16.2.2 12345
 
  server
  # nc -v -l 12345  /dev/null
 
  I get numbers around 350Mbps.  I tend to think iPerf is more reliable in
  this situation.
  Any ideas why the tests vary so much?

 I suspect nc does less efficient buffering.

 -Otto

  -Jim
 
  On 9/28/12 9:18 PM, Ryan McBride wrote:
   600Mbps seems about right, I tested a pair of E5649-based boxes to
   550Mbps last year (with aes-128-gcm):
  
   http://marc.info/?l=openbsd-miscm=134033767126930
  
   You'll probably get slightly more than 600 with with multiple TCP
   streams.
  
   Assuming PF was enabled for your test (the default configuration), the
   performance should be about the same with a proper ruleset. Traffic for
   existing states won't hit the ruleset at all.
  
  
   On Fri, Sep 28, 2012 at 06:39:14PM -0400, Jim Miller wrote:
   Yes.  Let me double check everything again on Monday.  Keep in mind
 that
   all devices had 1Gb ethernet interfaces and everything was directly
   cabled.  No pf rules either.  w/o ipsec I could get 900mbps through
 the
   openbsd boxes.
  
   Now you've got me thinking I need to recheck everything.
  
   -Jim
  
   On 9/28/12 5:19 PM, Hrvoje Popovski wrote:
   Hi,
  
   On 28.9.2012 22:09, Jim Miller wrote:
   So using another Mac w/ 1Gb ethernet adapter to a Linux box w/ 1Gb
 eth I
   was able to achieve approx. 600Mbps performance through the test
 setup
   (via iperf and my dd method).
  
   600Mbps via ipsec between two Intel E31220 ?

Re: IPSEC VPN performance

[Andy Bradford]

Thus said Jim Miller on Mon, 01 Oct 2012 11:20:06 EDT:

 # dd if=/dev/zero bs=1000 count=100 | nc -v 172.16.2.2 12345

What if you try a different bs?

$ dd if=/dev/zero bs=1000 count=100  /dev/null
100+0 records in
100+0 records out
10 bytes transferred in 1.102 secs (907004798 bytes/sec)

vs

$ dd if=/dev/zero bs=1 count=10  /dev/null
10+0 records in
10+0 records out
10 bytes transferred in 0.163 secs (6112058480 bytes/sec)

That looks like an order of magnitude  to me... not sure what you'll get
with client/server over the network, but can't hurt to try.

Andy

Re: IPSEC VPN performance

[Otto Moerbeek]

On Thu, Sep 27, 2012 at 05:30:38PM -0400, Jim Miller wrote:

 Hi,
 
 I'm trying to determine if the performance I'm seeing between two
 OpenBSD 5.1 IPSEC VPN endpoints is typical (or expected).  I recognize
 there are quite a few variables to consider and I'm sure I've not
 toggled each one but I could use a sanity check regardless.
 
 Question:
 With the configuration below when I disable ipsec I can route traffic
 between the two hosts (hosts A and B) at about 900mbps.  When I add the
 VPN I am getting speeds of approx. 40mbps.  The CPU load on the OpenBSD
 boxes spikes to about 80% on one of the cores but the other 3 are
 essentially unaffected.  Enabling/Disabling AES-NI in the bios doesn't
 seem to actually do anything as the cpu message in dmesg still shows the
 AES flag. 
 
 The test I'm using is this
 Host A:
 # nc -v -l 12345 | /dev/null
 
 Host B:
 # dd if=/dev/zero bs=1000 count=1 | nc -v host a 12345
 
 The reason these performance numbers are concerning to me is that I
 wanted a solution that would allow me to get decent (a.k.a. 100mbps +/-
 10%) without having to buy expensive cisco/juniper devices.

I would start playing with different modes, to see if that makes a
difference. It could very well be that AES-NI is only used in certain
modes. Start with the iked defaults for a start.

 
 Am I dreaming or have others had better performance?  Also, any recent
 data on AES-NI optimizations would be helpful.
 
 Thanks
 Jim
 
 Hardware Configuration:
 - (2) identical SuperMicro systems with quad core E31220 w/ AES-NI enabled

amd64 or i386? Why strip info from dmesg? It *might* mkae a difference.

-Otto


 
 cpu0: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (GenuineIntel 686-class)
 3.10 GHz
 cpu0:
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,LONG,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,LAHF
 cpu1: ..
 cpu2: ...
 cpu3: ...
 - 2GB ram
 - AES-NI enabled in bios
 - (4) Intel PRO/1000 MT (82574L)
 
 Software Configuration:
 VPN A
 /etc/iked.conf
 ikev2 active esp \
 from 172.16.1.0/24 to 172.16.2.0/24 \
 local 10.0.0.1 peer 10.0.0.2 \
 ikesa enc aes-256 auth hmac-sha2-512 group modp4096 \
 childsa enc aes-256-gmac \
 psk helpmeplease
 
 VPN B
 (reverse of A config)
 
 Host A - 172.16.1.2  (behind VPN A)
 Host B-  172.16.2.2  (behind VPN B)
 VPN A (10.0.0.1) talks to B (10.0.0.2) via a crossover cable.
 No switches/routers/hubs/etc in this test system.  All hosts running
 linux with 1000mb phys.

Re: IPSEC VPN performance

[Mike Belopuhov]

On Thu, Sep 27, 2012 at 11:30 PM, Jim Miller jmil...@sri-inc.com wrote:
 Hi,

 I'm trying to determine if the performance I'm seeing between two
 OpenBSD 5.1 IPSEC VPN endpoints is typical (or expected).  I recognize
 there are quite a few variables to consider and I'm sure I've not
 toggled each one but I could use a sanity check regardless.

 Question:
 With the configuration below when I disable ipsec I can route traffic
 between the two hosts (hosts A and B) at about 900mbps.  When I add the
 VPN I am getting speeds of approx. 40mbps.  The CPU load on the OpenBSD
 boxes spikes to about 80% on one of the cores but the other 3 are
 essentially unaffected.  Enabling/Disabling AES-NI in the bios doesn't
 seem to actually do anything as the cpu message in dmesg still shows the
 AES flag.

 The test I'm using is this
 Host A:
 # nc -v -l 12345 | /dev/null

 Host B:
 # dd if=/dev/zero bs=1000 count=1 | nc -v host a 12345

 The reason these performance numbers are concerning to me is that I
 wanted a solution that would allow me to get decent (a.k.a. 100mbps +/-
 10%) without having to buy expensive cisco/juniper devices.

 Am I dreaming or have others had better performance?  Also, any recent
 data on AES-NI optimizations would be helpful.

 Thanks
 Jim

 Hardware Configuration:
 - (2) identical SuperMicro systems with quad core E31220 w/ AES-NI enabled

 cpu0: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (GenuineIntel 686-class)
 3.10 GHz
 cpu0:
 FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,LONG,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,LAHF
 cpu1: ..
 cpu2: ...
 cpu3: ...
 - 2GB ram
 - AES-NI enabled in bios
 - (4) Intel PRO/1000 MT (82574L)

 Software Configuration:
 VPN A
 /etc/iked.conf
 ikev2 active esp \
 from 172.16.1.0/24 to 172.16.2.0/24 \
 local 10.0.0.1 peer 10.0.0.2 \
 ikesa enc aes-256 auth hmac-sha2-512 group modp4096 \
 childsa enc aes-256-gmac \
 psk helpmeplease

 VPN B
 (reverse of A config)

 Host A - 172.16.1.2  (behind VPN A)
 Host B-  172.16.2.2  (behind VPN B)
 VPN A (10.0.0.1) talks to B (10.0.0.2) via a crossover cable.
 No switches/routers/hubs/etc in this test system.  All hosts running
 linux with 1000mb phys.


Hi,

I have two suggestions:

1) try -current as forwarding performance was improved;
2) try aes-128-gcm for child sa (traffic encryption). aes-256-gmac-gmac
means don't encrypt, just authenticate.

I must say I'm curious about Xeon E3 AES-NI performance myself as
we have tested only core i5, i7 and previous generation xeons, but
the cpu you've picked should be the right choice.

Cheers,
Mike

Re: IPSEC VPN performance

[Mike Belopuhov]

On Fri, Sep 28, 2012 at 11:45 AM, Otto Moerbeek o...@drijf.net wrote:
 On Thu, Sep 27, 2012 at 05:30:38PM -0400, Jim Miller wrote:

 Hi,

 I'm trying to determine if the performance I'm seeing between two
 OpenBSD 5.1 IPSEC VPN endpoints is typical (or expected).  I recognize
 there are quite a few variables to consider and I'm sure I've not
 toggled each one but I could use a sanity check regardless.

 Question:
 With the configuration below when I disable ipsec I can route traffic
 between the two hosts (hosts A and B) at about 900mbps.  When I add the
 VPN I am getting speeds of approx. 40mbps.  The CPU load on the OpenBSD
 boxes spikes to about 80% on one of the cores but the other 3 are
 essentially unaffected.  Enabling/Disabling AES-NI in the bios doesn't
 seem to actually do anything as the cpu message in dmesg still shows the
 AES flag.

 The test I'm using is this
 Host A:
 # nc -v -l 12345 | /dev/null

 Host B:
 # dd if=/dev/zero bs=1000 count=1 | nc -v host a 12345

 The reason these performance numbers are concerning to me is that I
 wanted a solution that would allow me to get decent (a.k.a. 100mbps +/-
 10%) without having to buy expensive cisco/juniper devices.

 I would start playing with different modes, to see if that makes a
 difference. It could very well be that AES-NI is only used in certain
 modes. Start with the iked defaults for a start.


aes-ni is used for all aes-related modes (aes-cbc, aes-ctr, aes-gcm
and aes-gmac)... on amd64.


 Am I dreaming or have others had better performance?  Also, any recent
 data on AES-NI optimizations would be helpful.

 Thanks
 Jim

 Hardware Configuration:
 - (2) identical SuperMicro systems with quad core E31220 w/ AES-NI enabled

 amd64 or i386? Why strip info from dmesg? It *might* mkae a difference.


wow. it definitely makes a difference: aes-ni is not supported on i386.

 -Otto

Re: IPSEC VPN performance

[Peter Hessler]

On 2012 Sep 27 (Thu) at 17:30:38 -0400 (-0400), Jim Miller wrote:
:Hardware Configuration:
:- (2) identical SuperMicro systems with quad core E31220 w/ AES-NI enabled
:
:cpu0: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (GenuineIntel 686-class)
:3.10 GHz
:cpu0:
:FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,LONG,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,LAHF
:cpu1: ..
:cpu2: ...
:cpu3: ...
:- 2GB ram
:- AES-NI enabled in bios
:- (4) Intel PRO/1000 MT (82574L)
:

Please, for the love of everythign that is holy and non, do NOT strip
any info from dmesg.  We want all of it, as some parts that you think
don't matter DO.  In this case: the arch will make a big difference.


-- 
Happiness isn't something you experience; it's something you remember.
-- Oscar Levant

Re: IPSEC VPN performance

[Jim Miller]

 PRO/1000 MT (82574L) rev 0x00: msi,
address 00:25:90:75:91:c1
ppb3 at pci0 dev 28 function 6 Intel 6 Series PCIE rev 0xb5: apic 2 int 18
pci4 at ppb3 bus 4
em2 at pci4 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msi,
address 00:25:90:75:91:c2
ppb4 at pci0 dev 28 function 7 Intel 6 Series PCIE rev 0xb5: apic 2 int 19
pci5 at ppb4 bus 5
em3 at pci5 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msi,
address 00:25:90:75:91:c3
ehci1 at pci0 dev 29 function 0 Intel 6 Series USB rev 0x05: apic 2 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb5 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xa5
pci6 at ppb5 bus 6
vga1 at pci6 dev 3 function 0 Matrox MGA G200eW rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 Intel C204 LPC rev 0x05
ahci0 at pci0 dev 31 function 2 Intel 6 Series AHCI rev 0x05: msi,
AHCI 1.3
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, INTEL SSDSA2CT04, 4PC1 SCSI3
0/direct fixed naa.5001517972e60be6
sd0: 38166MB, 512 bytes/sector, 78165360 sectors, thin
ichiic0 at pci0 dev 31 function 3 Intel 6 Series SMBus rev 0x05: apic
2 int 18
iic0 at ichiic0
sdtemp0 at iic0 addr 0x18: stts2002
sdtemp1 at iic0 addr 0x1a: stts2002
spdmem0 at iic0 addr 0x50: 1GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
spdmem1 at iic0 addr 0x52: 1GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: NCT6776F rev 0x33
lm1 at wbsio0 port 0xa30/8: NCT6776F
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uhidev0 at uhub2 port 2 configuration 1 interface 0 Winbond Electronics
Corp Hermon USB hidmouse Device rev 1.10/0.01 addr 3
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub2 port 2 configuration 1 interface 1 Winbond Electronics
Corp Hermon USB hidmouse Device rev 1.10/0.01 addr 3
uhidev1: iclass 3/1
ukbd0 at uhidev1: 8 modifier keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhub3 at uhub1 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
uhidev2 at uhub3 port 2 configuration 1 interface 0 Generic USB
Keyboard rev 1.10/2.05 addr 3
uhidev2: iclass 3/1
ukbd1 at uhidev2: 8 modifier keys, 6 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
uhidev3 at uhub3 port 2 configuration 1 interface 1 Generic USB
Keyboard rev 1.10/2.05 addr 3
uhidev3: iclass 3/1, 3 report ids
uhid0 at uhidev3 reportid 1: input=1, output=0, feature=0
uhid1 at uhidev3 reportid 2: input=3, output=0, feature=0
ums1 at uhidev3 reportid 3: 0 button, Z dir
wsmouse1 at ums1 mux 0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (532543e2c86874e1.a) swap on sd0b dump on sd0b

On 9/28/12 6:28 AM, Mike Belopuhov wrote:
 On Fri, Sep 28, 2012 at 11:45 AM, Otto Moerbeek o...@drijf.net wrote:
 On Thu, Sep 27, 2012 at 05:30:38PM -0400, Jim Miller wrote:

 Hi,

 I'm trying to determine if the performance I'm seeing between two
 OpenBSD 5.1 IPSEC VPN endpoints is typical (or expected).  I recognize
 there are quite a few variables to consider and I'm sure I've not
 toggled each one but I could use a sanity check regardless.

 Question:
 With the configuration below when I disable ipsec I can route traffic
 between the two hosts (hosts A and B) at about 900mbps.  When I add the
 VPN I am getting speeds of approx. 40mbps.  The CPU load on the OpenBSD
 boxes spikes to about 80% on one of the cores but the other 3 are
 essentially unaffected.  Enabling/Disabling AES-NI in the bios doesn't
 seem to actually do anything as the cpu message in dmesg still shows the
 AES flag.

 The test I'm using is this
 Host A:
 # nc -v -l 12345 | /dev/null

 Host B:
 # dd if=/dev/zero bs=1000 count=1 | nc -v host a 12345

 The reason these performance numbers are concerning to me is that I
 wanted a solution that would allow me to get decent (a.k.a. 100mbps +/-
 10%) without having to buy expensive cisco/juniper devices.
 I would start playing with different modes, to see if that makes a
 difference. It could very well be that AES-NI is only used in certain
 modes. Start with the iked defaults for a start.

 aes-ni is used for all aes-related modes (aes-cbc, aes-ctr, aes-gcm
 and aes-gmac)... on amd64.

 Am I dreaming or have others had better performance?  Also, any recent
 data on AES-NI optimizations would be helpful.

 Thanks
 Jim

Re: IPSEC VPN performance

[Otto Moerbeek]

 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msi,
 address 00:25:90:75:91:c0
 ppb2 at pci0 dev 28 function 5 Intel 6 Series PCIE rev 0xb5: apic 2 int 17
 pci3 at ppb2 bus 3
 em1 at pci3 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msi,
 address 00:25:90:75:91:c1
 ppb3 at pci0 dev 28 function 6 Intel 6 Series PCIE rev 0xb5: apic 2 int 18
 pci4 at ppb3 bus 4
 em2 at pci4 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msi,
 address 00:25:90:75:91:c2
 ppb4 at pci0 dev 28 function 7 Intel 6 Series PCIE rev 0xb5: apic 2 int 19
 pci5 at ppb4 bus 5
 em3 at pci5 dev 0 function 0 Intel PRO/1000 MT (82574L) rev 0x00: msi,
 address 00:25:90:75:91:c3
 ehci1 at pci0 dev 29 function 0 Intel 6 Series USB rev 0x05: apic 2 int 23
 usb1 at ehci1: USB revision 2.0
 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
 ppb5 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xa5
 pci6 at ppb5 bus 6
 vga1 at pci6 dev 3 function 0 Matrox MGA G200eW rev 0x0a
 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
 wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
 pcib0 at pci0 dev 31 function 0 Intel C204 LPC rev 0x05
 ahci0 at pci0 dev 31 function 2 Intel 6 Series AHCI rev 0x05: msi,
 AHCI 1.3
 scsibus0 at ahci0: 32 targets
 sd0 at scsibus0 targ 0 lun 0: ATA, INTEL SSDSA2CT04, 4PC1 SCSI3
 0/direct fixed naa.5001517972e60be6
 sd0: 38166MB, 512 bytes/sector, 78165360 sectors, thin
 ichiic0 at pci0 dev 31 function 3 Intel 6 Series SMBus rev 0x05: apic
 2 int 18
 iic0 at ichiic0
 sdtemp0 at iic0 addr 0x18: stts2002
 sdtemp1 at iic0 addr 0x1a: stts2002
 spdmem0 at iic0 addr 0x50: 1GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
 spdmem1 at iic0 addr 0x52: 1GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
 isa0 at pcib0
 isadma0 at isa0
 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
 com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
 com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
 pckbc0 at isa0 port 0x60/5
 pckbd0 at pckbc0 (kbd slot)
 pckbc0: using irq 1 for kbd slot
 wskbd0 at pckbd0: console keyboard, using wsdisplay0
 pcppi0 at isa0 port 0x61
 spkr0 at pcppi0
 wbsio0 at isa0 port 0x2e/2: NCT6776F rev 0x33
 lm1 at wbsio0 port 0xa30/8: NCT6776F
 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
 mtrr: Pentium Pro MTRR support
 uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
 uhidev0 at uhub2 port 2 configuration 1 interface 0 Winbond Electronics
 Corp Hermon USB hidmouse Device rev 1.10/0.01 addr 3
 uhidev0: iclass 3/1
 ums0 at uhidev0: 3 buttons, Z dir
 wsmouse0 at ums0 mux 0
 uhidev1 at uhub2 port 2 configuration 1 interface 1 Winbond Electronics
 Corp Hermon USB hidmouse Device rev 1.10/0.01 addr 3
 uhidev1: iclass 3/1
 ukbd0 at uhidev1: 8 modifier keys, 6 key codes
 wskbd1 at ukbd0 mux 1
 wskbd1: connecting to wsdisplay0
 uhub3 at uhub1 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
 uhidev2 at uhub3 port 2 configuration 1 interface 0 Generic USB
 Keyboard rev 1.10/2.05 addr 3
 uhidev2: iclass 3/1
 ukbd1 at uhidev2: 8 modifier keys, 6 key codes
 wskbd2 at ukbd1 mux 1
 wskbd2: connecting to wsdisplay0
 uhidev3 at uhub3 port 2 configuration 1 interface 1 Generic USB
 Keyboard rev 1.10/2.05 addr 3
 uhidev3: iclass 3/1, 3 report ids
 uhid0 at uhidev3 reportid 1: input=1, output=0, feature=0
 uhid1 at uhidev3 reportid 2: input=3, output=0, feature=0
 ums1 at uhidev3 reportid 3: 0 button, Z dir
 wsmouse1 at ums1 mux 0
 vscsi0 at root
 scsibus1 at vscsi0: 256 targets
 softraid0 at root
 scsibus2 at softraid0: 256 targets
 root on sd0a (532543e2c86874e1.a) swap on sd0b dump on sd0b
 
 On 9/28/12 6:28 AM, Mike Belopuhov wrote:
  On Fri, Sep 28, 2012 at 11:45 AM, Otto Moerbeek o...@drijf.net wrote:
  On Thu, Sep 27, 2012 at 05:30:38PM -0400, Jim Miller wrote:
 
  Hi,
 
  I'm trying to determine if the performance I'm seeing between two
  OpenBSD 5.1 IPSEC VPN endpoints is typical (or expected).  I recognize
  there are quite a few variables to consider and I'm sure I've not
  toggled each one but I could use a sanity check regardless.
 
  Question:
  With the configuration below when I disable ipsec I can route traffic
  between the two hosts (hosts A and B) at about 900mbps.  When I add the
  VPN I am getting speeds of approx. 40mbps.  The CPU load on the OpenBSD
  boxes spikes to about 80% on one of the cores but the other 3 are
  essentially unaffected.  Enabling/Disabling AES-NI in the bios doesn't
  seem to actually do anything as the cpu message in dmesg still shows the
  AES flag.
 
  The test I'm using is this
  Host A:
  # nc -v -l 12345 | /dev/null
 
  Host B:
  # dd if=/dev/zero bs=1000 count=1 | nc -v host a 12345
 
  The reason these performance numbers are concerning to me is that I
  wanted a solution that would allow me to get decent (a.k.a. 100mbps +/-
  10%) without having to buy expensive cisco/juniper devices.
  I would start playing with different modes, to see if that makes a
  difference. It could very well

Re: IPSEC VPN performance

[Jim Miller]

 6 Series SMBus rev 0x05: apic
 2 int 18
 iic0 at ichiic0
 sdtemp0 at iic0 addr 0x18: stts2002
 sdtemp1 at iic0 addr 0x1a: stts2002
 spdmem0 at iic0 addr 0x50: 1GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
 spdmem1 at iic0 addr 0x52: 1GB DDR3 SDRAM ECC PC3-10600 with thermal sensor
 isa0 at pcib0
 isadma0 at isa0
 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
 com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
 com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
 pckbc0 at isa0 port 0x60/5
 pckbd0 at pckbc0 (kbd slot)
 pckbc0: using irq 1 for kbd slot
 wskbd0 at pckbd0: console keyboard, using wsdisplay0
 pcppi0 at isa0 port 0x61
 spkr0 at pcppi0
 wbsio0 at isa0 port 0x2e/2: NCT6776F rev 0x33
 lm1 at wbsio0 port 0xa30/8: NCT6776F
 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
 mtrr: Pentium Pro MTRR support
 uhub2 at uhub0 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
 uhidev0 at uhub2 port 2 configuration 1 interface 0 Winbond Electronics
 Corp Hermon USB hidmouse Device rev 1.10/0.01 addr 3
 uhidev0: iclass 3/1
 ums0 at uhidev0: 3 buttons, Z dir
 wsmouse0 at ums0 mux 0
 uhidev1 at uhub2 port 2 configuration 1 interface 1 Winbond Electronics
 Corp Hermon USB hidmouse Device rev 1.10/0.01 addr 3
 uhidev1: iclass 3/1
 ukbd0 at uhidev1: 8 modifier keys, 6 key codes
 wskbd1 at ukbd0 mux 1
 wskbd1: connecting to wsdisplay0
 uhub3 at uhub1 port 1 Intel Rate Matching Hub rev 2.00/0.00 addr 2
 uhidev2 at uhub3 port 2 configuration 1 interface 0 Generic USB
 Keyboard rev 1.10/2.05 addr 3
 uhidev2: iclass 3/1
 ukbd1 at uhidev2: 8 modifier keys, 6 key codes
 wskbd2 at ukbd1 mux 1
 wskbd2: connecting to wsdisplay0
 uhidev3 at uhub3 port 2 configuration 1 interface 1 Generic USB
 Keyboard rev 1.10/2.05 addr 3
 uhidev3: iclass 3/1, 3 report ids
 uhid0 at uhidev3 reportid 1: input=1, output=0, feature=0
 uhid1 at uhidev3 reportid 2: input=3, output=0, feature=0
 ums1 at uhidev3 reportid 3: 0 button, Z dir
 wsmouse1 at ums1 mux 0
 vscsi0 at root
 scsibus1 at vscsi0: 256 targets
 softraid0 at root
 scsibus2 at softraid0: 256 targets
 root on sd0a (532543e2c86874e1.a) swap on sd0b dump on sd0b

 On 9/28/12 6:28 AM, Mike Belopuhov wrote:
 On Fri, Sep 28, 2012 at 11:45 AM, Otto Moerbeek o...@drijf.net wrote:
 On Thu, Sep 27, 2012 at 05:30:38PM -0400, Jim Miller wrote:

 Hi,

 I'm trying to determine if the performance I'm seeing between two
 OpenBSD 5.1 IPSEC VPN endpoints is typical (or expected).  I recognize
 there are quite a few variables to consider and I'm sure I've not
 toggled each one but I could use a sanity check regardless.

 Question:
 With the configuration below when I disable ipsec I can route traffic
 between the two hosts (hosts A and B) at about 900mbps.  When I add the
 VPN I am getting speeds of approx. 40mbps.  The CPU load on the OpenBSD
 boxes spikes to about 80% on one of the cores but the other 3 are
 essentially unaffected.  Enabling/Disabling AES-NI in the bios doesn't
 seem to actually do anything as the cpu message in dmesg still shows the
 AES flag.

 The test I'm using is this
 Host A:
 # nc -v -l 12345 | /dev/null

 Host B:
 # dd if=/dev/zero bs=1000 count=1 | nc -v host a 12345

 The reason these performance numbers are concerning to me is that I
 wanted a solution that would allow me to get decent (a.k.a. 100mbps +/-
 10%) without having to buy expensive cisco/juniper devices.
 I would start playing with different modes, to see if that makes a
 difference. It could very well be that AES-NI is only used in certain
 modes. Start with the iked defaults for a start.

 aes-ni is used for all aes-related modes (aes-cbc, aes-ctr, aes-gcm
 and aes-gmac)... on amd64.

 Am I dreaming or have others had better performance?  Also, any recent
 data on AES-NI optimizations would be helpful.

 Thanks
 Jim

 Hardware Configuration:
 - (2) identical SuperMicro systems with quad core E31220 w/ AES-NI enabled
 amd64 or i386? Why strip info from dmesg? It *might* mkae a difference.

 wow. it definitely makes a difference: aes-ni is not supported on i386.

 -Otto

Re: IPSEC VPN performance

[Christian Weisgerber]

Jim Miller jmil...@sri-inc.com wrote:

 The test I'm using is this
 Host A:
 # nc -v -l 12345 | /dev/null
 
 Host B:
 # dd if=/dev/zero bs=1000 count=1 | nc -v host a 12345

I increased the count a bit:
10 bytes transferred in 53.265 secs (18773882 bytes/sec)

That's with AES-256-GCM between two Sandy Bridge Xeons
(Intel Xeon CPU E5-2637 @ 3.00GHz), i.e., with AES-NI, running
OpenBSD-current/amd64.

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: IPSEC VPN performance

[Jim Miller]

So I just realized another serious flaw in my testing.  I was using a
Mac Air w/ USB 100Mb ethernet adapter for one of the hosts behind the
OpenBSD VPN devices.  And it must have been limiting the speed more than
I thought.

So using another Mac w/ 1Gb ethernet adapter to a Linux box w/ 1Gb eth I
was able to achieve approx. 600Mbps performance through the test setup
(via iperf and my dd method).  

Still it baffles me as to why the ASA 5505 performed better with the Mac
Air's USB 100mbps connection than the OpenVPN boxes.  The ASA was able
to do approx 88mbps while I never got above 72mbps on the OpenBSD test. 
Either way, case closed.  I'd say that's fast enough.

Lessons' learned:
- Use the amd64 kernel not i386
- w/ AES-NI enabled AES-256-GMAC, AES-256-GCM, AES-128 all performed
about the same
- For some reason on my supermicro board disabling AES-NI doesn't have
an effect as OpenBSD still seems to find the instructions
- Don't use USB for testing performance. ;)

Thanks to all that helped.
-Jim

On 9/28/12 3:10 PM, Christian Weisgerber wrote:
 Jim Miller jmil...@sri-inc.com wrote:

 The test I'm using is this
 Host A:
 # nc -v -l 12345 | /dev/null

 Host B:
 # dd if=/dev/zero bs=1000 count=1 | nc -v host a 12345
 I increased the count a bit:
 10 bytes transferred in 53.265 secs (18773882 bytes/sec)

 That's with AES-256-GCM between two Sandy Bridge Xeons
 (Intel Xeon CPU E5-2637 @ 3.00GHz), i.e., with AES-NI, running
 OpenBSD-current/amd64.

Re: IPSEC VPN performance

[Hrvoje Popovski]

Hi,

On 28.9.2012 22:09, Jim Miller wrote:
 So using another Mac w/ 1Gb ethernet adapter to a Linux box w/ 1Gb eth I
 was able to achieve approx. 600Mbps performance through the test setup
 (via iperf and my dd method).  
 

600Mbps via ipsec between two Intel E31220 ?

Re: IPSEC VPN performance

[Jim Miller]

Yes.  Let me double check everything again on Monday.  Keep in mind that
all devices had 1Gb ethernet interfaces and everything was directly
cabled.  No pf rules either.  w/o ipsec I could get 900mbps through the
openbsd boxes.

Now you've got me thinking I need to recheck everything.

-Jim

On 9/28/12 5:19 PM, Hrvoje Popovski wrote:
 Hi,

 On 28.9.2012 22:09, Jim Miller wrote:
 So using another Mac w/ 1Gb ethernet adapter to a Linux box w/ 1Gb eth I
 was able to achieve approx. 600Mbps performance through the test setup
 (via iperf and my dd method).  

 600Mbps via ipsec between two Intel E31220 ?

Re: IPSEC VPN performance

[Ryan McBride]

600Mbps seems about right, I tested a pair of E5649-based boxes to
550Mbps last year (with aes-128-gcm):

http://marc.info/?l=openbsd-miscm=134033767126930

You'll probably get slightly more than 600 with with multiple TCP
streams. 

Assuming PF was enabled for your test (the default configuration), the
performance should be about the same with a proper ruleset. Traffic for
existing states won't hit the ruleset at all.


On Fri, Sep 28, 2012 at 06:39:14PM -0400, Jim Miller wrote:
 Yes.  Let me double check everything again on Monday.  Keep in mind that
 all devices had 1Gb ethernet interfaces and everything was directly
 cabled.  No pf rules either.  w/o ipsec I could get 900mbps through the
 openbsd boxes.
 
 Now you've got me thinking I need to recheck everything.
 
 -Jim
 
 On 9/28/12 5:19 PM, Hrvoje Popovski wrote:
  Hi,
 
  On 28.9.2012 22:09, Jim Miller wrote:
  So using another Mac w/ 1Gb ethernet adapter to a Linux box w/ 1Gb eth I
  was able to achieve approx. 600Mbps performance through the test setup
  (via iperf and my dd method).  
 
  600Mbps via ipsec between two Intel E31220 ?

IPSEC VPN performance

[Jim Miller]

Hi,

I'm trying to determine if the performance I'm seeing between two
OpenBSD 5.1 IPSEC VPN endpoints is typical (or expected).  I recognize
there are quite a few variables to consider and I'm sure I've not
toggled each one but I could use a sanity check regardless.

Question:
With the configuration below when I disable ipsec I can route traffic
between the two hosts (hosts A and B) at about 900mbps.  When I add the
VPN I am getting speeds of approx. 40mbps.  The CPU load on the OpenBSD
boxes spikes to about 80% on one of the cores but the other 3 are
essentially unaffected.  Enabling/Disabling AES-NI in the bios doesn't
seem to actually do anything as the cpu message in dmesg still shows the
AES flag. 

The test I'm using is this
Host A:
# nc -v -l 12345 | /dev/null

Host B:
# dd if=/dev/zero bs=1000 count=1 | nc -v host a 12345

The reason these performance numbers are concerning to me is that I
wanted a solution that would allow me to get decent (a.k.a. 100mbps +/-
10%) without having to buy expensive cisco/juniper devices.

Am I dreaming or have others had better performance?  Also, any recent
data on AES-NI optimizations would be helpful.

Thanks
Jim

Hardware Configuration:
- (2) identical SuperMicro systems with quad core E31220 w/ AES-NI enabled

cpu0: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz (GenuineIntel 686-class)
3.10 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,NXE,LONG,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,LAHF
cpu1: ..
cpu2: ...
cpu3: ...
- 2GB ram
- AES-NI enabled in bios
- (4) Intel PRO/1000 MT (82574L)

Software Configuration:
VPN A
/etc/iked.conf
ikev2 active esp \
from 172.16.1.0/24 to 172.16.2.0/24 \
local 10.0.0.1 peer 10.0.0.2 \
ikesa enc aes-256 auth hmac-sha2-512 group modp4096 \
childsa enc aes-256-gmac \
psk helpmeplease

VPN B
(reverse of A config)

Host A - 172.16.1.2  (behind VPN A)
Host B-  172.16.2.2  (behind VPN B)
VPN A (10.0.0.1) talks to B (10.0.0.2) via a crossover cable.
No switches/routers/hubs/etc in this test system.  All hosts running
linux with 1000mb phys.

Re: IPSEC newbie looking to replace vpnc with Openbsd built-in IPSEC vpn

[Stuart Henderson]

On 2012-06-01, Sarah Caswell s.casw...@protocol6.com wrote:
 Hi all,

 I am currently using vpnc to connect to a client site (which has an CISCO ASA 
 firewall/vpn endpoint)
 This setup works, but everytime I use vpnc from my server it breaks other 
 networking, especially the openvpn tunnels I maintain to other sites.

 I'd prefer to use the built-in IPSEC software in OpenBSD to establish the 
 tunnel instead (and terminate it locally on a tun or tap interface)

 All my attempts so far have failed and I must admit I'm an IPSEC newbie, at 
 least with the OpenBSD tools.

 My vpc.conf file is very simple:

 ---
 IPSec gateway ww.xx.yy.zz
 IPSec ID somevpn
 IPSec secret somesecretString
 IKE Authmode psk
 ---

 Is there an equivalent config for ipsecctl (and/or isakmpd) that is known to 
 work with remote ASA firewalls?

 Any help or suggestions would be greatly appreciated.

 Thanks in advance.

:-)

 Sarah



Presumably some default settings are different between vpnc and isakmpd.
Typical possibilities are the authentication and encryption parameters
and one which people often forget, lifetime values.

Usually you would get these settings froe the people operating the
other side (or tell them what you are using and have them adjust theirs).
If they are not forthcoming then tcpdump can help (on the physical
interface and also on isakmpd packet capture files, see isakmpd manual
about -L).

Note that lifetimes are set in /etc/isakmpd/isakmpd.conf even if you
use ipsec.conf, here's an example of a file I'm using

[General]
Default-phase-1-lifetime=86400,60:86400
Default-phase-2-lifetime=86400,60:86400

The biggest problem I had running IPsec to an ASA with isakmpd was when the
ASA was behind NAT; cisco didn't bother to follow the RFC document they helped
write and still use encapsulation-type values from the internet-draft...
But if NAT is not involved then that's not your problem.

IPSEC newbie looking to replace vpnc with Openbsd built-in IPSEC vpn

[Sarah Caswell]

Hi all,

I am currently using vpnc to connect to a client site (which has an CISCO ASA 
firewall/vpn endpoint)
This setup works, but everytime I use vpnc from my server it breaks other 
networking, especially the openvpn tunnels I maintain to other sites.

I'd prefer to use the built-in IPSEC software in OpenBSD to establish the 
tunnel instead (and terminate it locally on a tun or tap interface)

All my attempts so far have failed and I must admit I'm an IPSEC newbie, at 
least with the OpenBSD tools.

My vpc.conf file is very simple:

---
IPSec gateway ww.xx.yy.zz
IPSec ID somevpn
IPSec secret somesecretString
IKE Authmode psk
---

Is there an equivalent config for ipsecctl (and/or isakmpd) that is known to 
work with remote ASA firewalls?

Any help or suggestions would be greatly appreciated.

Thanks in advance.

:-)

Sarah

Re: IPSEC newbie looking to replace vpnc with Openbsd built-in IPSEC vpn

[carlos albino garcia grijalba]

not having any practive with cisco ASA but searching the web have seen several
post about openbsd-ipsec + cisco asa and from another mails i have seen it
seems pretty easy as long as u have the same crypto transforms in the sides

 Date: Fri, 1 Jun 2012 15:48:37 -0400
 From: s.casw...@protocol6.com
 To: misc@openbsd.org
 Subject: IPSEC newbie looking to replace vpnc with Openbsd built-in IPSEC
vpn

 Hi all,

 I am currently using vpnc to connect to a client site (which has an CISCO
ASA firewall/vpn endpoint)
 This setup works, but everytime I use vpnc from my server it breaks other
networking, especially the openvpn tunnels I maintain to other sites.

 I'd prefer to use the built-in IPSEC software in OpenBSD to establish the
tunnel instead (and terminate it locally on a tun or tap interface)

 All my attempts so far have failed and I must admit I'm an IPSEC newbie, at
least with the OpenBSD tools.

 My vpc.conf file is very simple:

 ---
 IPSec gateway ww.xx.yy.zz
 IPSec ID somevpn
 IPSec secret somesecretString
 IKE Authmode psk
 ---

 Is there an equivalent config for ipsecctl (and/or isakmpd) that is known to
work with remote ASA firewalls?

 Any help or suggestions would be greatly appreciated.

 Thanks in advance.

 :-)

 Sarah

IPSec VPN dropping packets from time to time

[Georg Buschbeck]

Hi,

i've two openbsd firewalls running

1x OpenBSD 4.9 (amd64) in our office
1x OpenBSD 5.0 (amd64) in our co location.

we have a vpn set up between both locations via /etc/ipsec.conf
isakmpd is setup to not read any konfiguration files:

=== /etc/rc.conf.local ===
isakmpd_flags=-4 -K -v
=== /etc/rc.conf.local ===

now from time to time the vpn becomes unavailable,
though the established security association is visible via ipsecctl -sa.

i don't find anything suspucios in the log only quick mode done

=== /etc/ipsec.conf ===
ike active esp from $local_net to   $remotenet   peer $remotepeer \
main auth hmac-sha1  enc aes group modp1024\
quick auth hmac-sha1 enc aes group modp1024\
psk MyPsKMyPsKMyPsKMyPsKMyPsKMyPsKMyPsKMyPsKMyPsKMyPsK
=== /etc/ipsec.conf ===

are there any hints what would be the best to debug next?
as till now i didn't see a pattern there.

delete the ruleset manually by  solves the probleme temporarily
which could be needed more often when forced.

===
ipsecctl -d -f /etc/ipsec.conf; ipsecctl -f /etc/ipsec.conf
===


Georg

Re: IPSec VPN dropping packets from time to time

[Steven Surdock]

See -stable fixes to 4.9.  Otherwise consider upgrading 4.9-5.0.

-Steve S.

-Steve S.


-Original Message-
From: Georg Buschbeck [open...@thomas-daily.de]
Received: Tuesday, 20 Dec 2011, 2:35am
To: misc@openbsd.org [misc@openbsd.org]
Subject: IPSec VPN dropping packets from time to time


Hi,

i've two openbsd firewalls running

1x OpenBSD 4.9 (amd64) in our office
1x OpenBSD 5.0 (amd64) in our co location.

we have a vpn set up between both locations via /etc/ipsec.conf
isakmpd is setup to not read any konfiguration files:

=== /etc/rc.conf.local ===
isakmpd_flags=-4 -K -v
=== /etc/rc.conf.local ===

now from time to time the vpn becomes unavailable,
though the established security association is visible via ipsecctl -sa.

i don't find anything suspucios in the log only quick mode done

=== /etc/ipsec.conf ===
ike active esp from $local_net to   $remotenet   peer $remotepeer \
 main auth hmac-sha1  enc aes group modp1024\
 quick auth hmac-sha1 enc aes group modp1024\
 psk MyPsKMyPsKMyPsKMyPsKMyPsKMyPsKMyPsKMyPsKMyPsKMyPsK
=== /etc/ipsec.conf ===

are there any hints what would be the best to debug next?
as till now i didn't see a pattern there.

delete the ruleset manually by  solves the probleme temporarily
which could be needed more often when forced.

===
ipsecctl -d -f /etc/ipsec.conf; ipsecctl -f /etc/ipsec.conf
===


Georg

ipsec vpn 'colouring'

[Oeschger Patrick]

*hmmm*
i did a test using ipsec vpn colouring aka. tagging
ipsec.conf offers the option to tag the vpn traffic for further PF filtering
using these tags i can instruct PF to use different public NAT addresses
(outgoing to internet) for each VPN
but when you have overlapping subnets behind the VPNs then it it difficult to
get the reply traffic into the right VPN
maybe i am missing something here...
i expected some feature so tagged traffic will be routed into the VPN carrying
the same tag (...somehow...)
did some tests using 'reply-to' in pf rules but that did not work... - an a
default route will not help because i have many VPN all overlapping in worst
case
any ideas? an important option i missed?
thank you
/pat

Re: ipsec vpn 'colouring'

[Claer]

On Fri, May 27 2011 at 07:16, Oeschger Patrick wrote:
 *hmmm*
*hmmm*,

 i did a test using ipsec vpn colouring aka. tagging
 ipsec.conf offers the option to tag the vpn traffic for further PF filtering
 using these tags i can instruct PF to use different public NAT addresses
 (outgoing to internet) for each VPN
 but when you have overlapping subnets behind the VPNs then it it difficult to
 get the reply traffic into the right VPN
 maybe i am missing something here...
Why not using the local keyword of ipsec.conf for outgoing address 
instead of NAT ?

 I expected some feature so tagged traffic will be routed into the VPN carrying
 the same tag (...somehow...)
 did some tests using 'reply-to' in pf rules but that did not work... - an a
 default route will not help because i have many VPN all overlapping in worst
 case
 any ideas? an important option i missed?
Using ipsec tunnels in different rdomains to manage overlapping easily?
(Thanks to Reyk to clarify the usage of ipsec+rdomain)

Claer

Routing all traffic through IPSEC VPN

[Matt S]

Hello @misc

I seem to still be having some problems but I have made progress.  The branch 
office cannot get out to the internet at large which I think may be a NAT 
problem.  At least, when changing the default route on the branch office, I 
don't lose connectivity to it.  On the branch office, the routing tables don't 
display unless I use netstat -rn -f inet.  I also cannot traceroute.  Kindly 
advise what pf rules and additionaly static routing is appropriate.

--Main Office--
# The main office has a PPPoE connection to the internet
cat /etc/pf.conf:
pass all
match out on tun0 from 10.40.60.0 to any nat-to (tun0)

cat /etc/hostname.gre0:
inet 172.16.254.1 255.255.255.255 172.16.254.2 link0 up
tunnel hq.valleybusinesssolutions.us vps.valleybusinesssolutions.us

route add -net 10.40.65.0/24 

netstat -r:
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
defaultphnx-dsl-gw55-247. UGS345750 - 8 tun0
10.40.60/24link#1 UC 10 - 4 em0
10.40.60.3 00:24:2c:07:d4:d0  UHLc   225728 - 4 em0
10.40.65/24172.16.254.2   UGS0  110 - 8 gif0
phnx-dsl-gw55-247. 71-223-156-37.phnx UH 18  1492 4 tun0
loopback   localhost  UGRS   00 33200 8 lo0
localhost  localhost  UH 00 33200 4 lo0
172.16.254.2   172.16.254.1  UH 1  68 - 4 gif0
BASE-ADDRESS.MCAST localhost  URS00 33200 8 lo0


--Branch Office--
# The branch office has a cable-based internet connection
cat /etc/pf.conf:
pass all
match out on em0 from 10.40.65.0 to any nat-to(em0)

cat /etc/hostname.gre0:
inet 172.16.254.2 255.255.255.255 172.16.254.1 link0 up
tunnel vps.valleybusinesssolutions.us hq.valleybusinesssolutions.us

route add -host hq.valleybusinesssolutions.us 206.125.169.97 #206.125.169.97 is 
the ISP's gateway
route change default 172.16.254.1

netstat -rn -finet
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default172.16.254.1UGS0   98 - 8 gif0
10.40.65/24link#4UC 00 - 4 vether0
71.223.156.37  206.125.169.97 UGHS   0  201  - 8 em0
127/8  127.0.0.1  UGRS   00 33160 8 lo0
127.0.0.1  127.0.0.1  UH 12 33160 4 lo0
172.16.254.1   172.16.254.2   UH 2   91 - 4 gif0
206.125.169.96/29  link#1 UC 20  - 4 em0
206.125.169.97 00:0d:65:ab:c8:bf  UHLc   10 -4 em0
206.125.169.98 52:54:00:27:26:22  UHLc   00- 4 lo0
224/4  127.0.0.1  URS00 33160 8 lo0

Thank you again,
Matt

Re: Routing all traffic through IPSEC VPN

[lilit-aibolit]

Matt S P?P8QP5Q:

Hello @misc:

I am up against a stumper.  I have a Site-to-Site IPSEC VPN working beautifully. 
 However, I would like the remote site to route all of its traffic through the 
VPN.  After googling, I seemed to come up with a suggestion to do a route change 
-net 0.0.0.0/0 gateway which didn't work well.  I think it might have to do 
with NAT.  The main office is doing the NAT.  Perhaps I need to some sort of NAT 
traversal on the VPN??



  

Hello.
Here is working config. I have two nets 15.0/24 and 16.0/24.
16.0/24 have default gateway to Internet.
between 15 and 16 setup IPSec.
from 15 for lucky boys I setup tunnel to any.
on router in 16 lucky boys go out with NAT.
===net 15.0=
ipsec.conf

remote_nets = { 192.168.16.0/24, 172.20.252.0/24}
nat_clients = { 192.168.15.10, 192.168.15.167, 192.168.15.170 }
flow esp from 192.168.15.0/24 to $remote_nets peer 192.168.10.1
flow esp from $nat_clients to any peer 192.168.10.1
esp from 192.168.10.2 to 192.168.10.1

ifconfig

rl0: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 00:02:44:56:39:04
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.15.6 netmask 0xff00 broadcast 192.168.15.255
vr0: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 00:13:d3:36:f5:ce
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.10.2 netmask 0xff00 broadcast 192.168.10.255

route -n show
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 192.168.10.1 UGS 5 5440 - 8 vr0
127/8 127.0.0.1 UGRS 0 0 33200 8 lo0
127.0.0.1 127.0.0.1 UH 2 4 33200 4 lo0
192.168.10/24 link#2 UC 1 0 - 4 vr0
192.168.10.1 00:d0:b7:60:5f:5c UHLc 3 1357436 - 4 vr0
192.168.15/24 link#1 UC 38 0 - 4 rl0
Encap:
Source Port Destination Port Proto SA(Address/Proto/Type/Direction)
default 0 192.168.15.170/32 0 0 192.168.10.1/esp/require/in
192.168.15.170/32 0 default 0 0 192.168.10.1/esp/require/out
default 0 192.168.15.167/32 0 0 192.168.10.1/esp/require/in
192.168.15.167/32 0 default 0 0 192.168.10.1/esp/require/out
default 0 192.168.15.10/32 0 0 192.168.10.1/esp/require/in
192.168.15.10/32 0 default 0 0 192.168.10.1/esp/require/out
172.20.252/24 0 192.168.15/24 0 0 192.168.10.1/esp/require/in
192.168.15/24 0 172.20.252/24 0 0 192.168.10.1/esp/require/out
192.168.16/24 0 192.168.15/24 0 0 192.168.10.1/esp/require/in
192.168.15/24 0 192.168.16/24 0 0 192.168.10.1/esp/require/out

net 16=
local_nets = { 172.20.252.0/24, 192.168.16.0/24 }
flow esp from $local_nets to 192.168.15.0/24 peer 192.168.10.2
flow esp from any to { 192.168.15.10, 192.168.15.167, 192.168.15.170 } 
peer 192.168.10.2

esp from 192.168.10.1 to 192.168.10.2

fxp0: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 00:d0:b7:60:75:51
priority: 0
groups: egress
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.16.6 netmask 0xff00 broadcast 192.168.16.255
fxp1: flags=28843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,NOINET6 mtu 1500
lladdr 00:d0:b7:60:5f:5c
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.10.1 netmask 0xff00 broadcast 192.168.10.255
fxp2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:d0:b7:60:5d:9c
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 172.20.252.36 netmask 0xfff8 broadcast 172.20.252.39
inet6 fe80::2d0:b7ff:fe60:5d9c%fxp2 prefixlen 64 scopeid 0x3
rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:0d:88:45:68:aa
priority: 0
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 192.168.20.55 netmask 0xff00 broadcast 192.168.20.255

Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 192.168.16.8 UGS 6 14997670 - 8 fxp0
127/8 127.0.0.1 UGRS 0 0 33200 8 lo0
127.0.0.1 127.0.0.1 UH 2 11204 33200 4 lo0
172.20.252.32/29 link#3 UC 1 0 - 4 fxp2
172.20.252.38 00:03:7e:00:73:40 UHLc 0 4831569 - 4 fxp2
192.168.10/24 link#2 UC 2 0 - 4 fxp1
192.168.10.1 00:d0:b7:60:5f:5c UHLc 0 4 - 4 lo0
192.168.10.2 00:13:d3:36:f5:ce UHLc 15 102190836 - 4 fxp1
192.168.15/24 192.168.10.2 UGS 0 119979 - 8 fxp1
Encap:
Source Port Destination Port Proto SA(Address/Proto/Type/Direction)
192.168.15.170/32 0 default 0 0 192.168.10.2/esp/require/in
default 0 192.168.15.170/32 0 0 192.168.10.2/esp/require/out
192.168.15.167/32 0 default 0 0 192.168.10.2/esp/require/in
default 0 192.168.15.167/32 0 0 192.168.10.2/esp/require/out
192.168.15.10/32 0 default 0 0 192.168.10.2/esp/require/in
default 0 192.168.15.10/32 0 0 192.168.10.2/esp/require/out
192.168.15/24 0 192.168.16/24 0 0 192.168.10.2/esp/require/in
192.168.16/24 0 192.168.15/24 0 0 192.168.10.2/esp/require/out
192.168.15/24 0 172.20.252/24 0 0 192.168.10.2/esp/require/in
172.20.252/24 0 192.168.15/24 0 0 192.168.10.2/esp/require/out


host 192.168.16.8 doint

Re: Routing all traffic through IPSEC VPN

[Claudiu Pruna]

On Tue, 2011-04-12 at 19:53 -0700, Matt S wrote:
 Hello @misc:
 
 I am up against a stumper.  I have a Site-to-Site IPSEC VPN working 
 beautifully. 
  However, I would like the remote site to route all of its traffic through 
 the 
 VPN.  After googling, I seemed to come up with a suggestion to do a route 
 change 
 -net 0.0.0.0/0 gateway which didn't work well.  I think it might have to do 
 with NAT.  The main office is doing the NAT.  Perhaps I need to some sort of 
 NAT 
 traversal on the VPN??
 
 Here is my setup:
 
 --Main Office--
 cat /etc/ipsec.conf:
 me=A.B.C.D
 mypeer=E.F.G.H
 mypsk=mypsk
 
 ike passive esp from $me to $mypeer peer $mypeer \
   main auth hmac-sha1 enc 3des group modp1024 \
   srcid $me dstid $mypeer \
   psk $mypsk
 
 cat /etc/hostname.gre0:
 inet 172.16.254.1 255.255.255.252 172.16.254.2
 tunnel A.B.C.D E.F.G.H
 !route add -net 10.40.65 -netmask 255.255.255.0 172.16.254.2
 
 cat /etc/pf.conf:
 set skip on {lo, gre0, enc0}
 
 anchor ftp-proxy/*
 
 block in log all
 pass out all
 
 antispoof for tun0
 table bruteforce persist
 table trustednets {10.40.60.0/24, 10.40.65.0/24}
 
 match out on tun0 from trustednets to any nat-to (tun0)
 
 pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
 pass in quick proto tcp from localhost to any port {http,https} rdr-to 
 127.0.0.1 
 port 3128
 pass quick proto {gre, esp, tcp, udp} from E.F.G.H to (tun0)
 block log quick from bruteforce
 pass inet proto icmp all icmp-type {echoreq, unreach}
 pass in on tun0 inet proto tcp from any to any port ssh keep state 
 (max-src-conn 
 6, max-src-conn-rate 3/1, overload bruteforce flush global) rdr-to 
 10.40.60.1
 pass on em0 from trustednets to any
 
 
 --Branch Office--
 cat /etc/ipsec.conf:
 me=E.F.G.H
 mypeer=A.B.C.D
 mypsk=mypsk
 
 ike esp from $me to $mypeer peer $mypeer \
   main auth hmac-sha1 enc 3des group modp1024 \
   srcid $me dstid $mypeer \
   psk $mypsk
 
 cat /etc/hostname.gre0:
 inet 172.16.254.2 255.255.255.252 172.16.254.1
 tunnel E.F.G.H A.B.C.D
 !route add -net 10.40.60 -netmask 255.255.255.0 172.16.254.1
 
 Firewall disabled for now - nothing other than sshd and isakmpd are running.
 
 Thanks,
 Matt
 

Matt

did you put on the branch router a route like 
route add A.B.C.D branch isp gateway ?

beware that if you issue just route add default 172.16.254.1 then your
router will tend to also route the vpn traffic through your tunnel, so
you get a race condition.

claudiu.


-- 
Claudiu Pruna clau...@net-go.net

Re: Routing all traffic through IPSEC VPN

[Matt S]

Hi Claudiu:

Thank you for your reply.  I did try your suggestion to do a route add 
A.B.C.D.E 
isp gateway and unfortunately it did not work so well.  I lost connectivity 
to 
the branch altogether over the VPN.  At least I have console access :)  Once I 
removed the route, I regained connectivity over the vpn.  Perhaps, I can show 
you the routing tables, if that will help?

Main
Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default   phnx-dsl-gw55-247. UGS   19  1629401 - 8 tun0
10.40.60/24link#1 UC 20 - 4 em0
10.40.60.3 00:24:2c:07:d4:d0  UHLc   1 3217 - 4 em0
10.40.60.5 link#1 UHLc   1  847 - 4 em0
10.40.65/24172.16.254.2   UG 0   22 -32 gre0
phnx-dsl-gw55-247. 71-223-148-144.phn UH 1   12  1492 4 tun0
loopback   localhost  UGRS   00 33200 8 lo0
localhost   localhost  UH 0   60 33200 4 lo0
172.16.254.1/32172.16.254.2   UG 00 -32 gre0
172.16.254.2   172.16.254.1   UH 2  157 - 4 gre0
BASE-ADDRESS.MCAST localhost  URS00 33200 8 lo0

Branch
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
default206.125.169.97 UGS311772 - 8 em0
10.40.60/24172.16.254.1   UG 1   50 -32 gre0
10.40.65/24link#4 UC 10 - 4 vether0
10.40.65.1 fe:e1:ba:d0:da:7e  UHLc   04 - 4 lo0
loopback   localhost  UGRS   00 33160 8 lo0
localhost  localhost  UH 1   60 33160 4 lo0
172.16.254.1   172.16.254.2   UH 2   87 - 4 gre0
172.16.254.2/32172.16.254.1   UG 00 -32 gre0
206.125.169.96/29  link#1 UC 20 - 4 em0
206.125.169.97 00:0d:65:ab:c8:bf  UHLc   10 - 4 em0
matthew-schwartz.c 52:54:00:27:26:22  UHLc   00 - 4 lo0
BASE-ADDRESS.MCAST localhost  URS00 33160 8 lo0

On Tue, 2011-04-12 at 19:53 -0700, Matt S wrote:
 Hello @misc:
 
 I am up against a stumper.  I have a Site-to-Site IPSEC VPN working 
beautifully. 

  However, I would like the remote site to route all of its traffic through 
 the 

 VPN.  After googling, I seemed to come up with a suggestion to do a route 
change 

 -net 0.0.0.0/0 gateway which didn't work well.  I think it might have to do 
 with NAT.  The main office is doing the NAT.  Perhaps I need to some sort of 
NAT 

 traversal on the VPN??
 
 Here is my setup:
 
 --Main Office--
 cat /etc/ipsec.conf:
 me=A.B.C.D
 mypeer=E.F.G.H
 mypsk=mypsk
 
 ike passive esp from $me to $mypeer peer $mypeer \
   main auth hmac-sha1 enc 3des group modp1024 \
   srcid $me dstid $mypeer \
   psk $mypsk
 
 cat /etc/hostname.gre0:
 inet 172.16.254.1 255.255.255.252 172.16.254.2
 tunnel A.B.C.D E.F.G.H
 !route add -net 10.40.65 -netmask 255.255.255.0 172.16.254.2
 
 cat /etc/pf.conf:
 set skip on {lo, gre0, enc0}
 
 anchor ftp-proxy/*
 
 block in log all
 pass out all
 
 antispoof for tun0
 table bruteforce persist
 table trustednets {10.40.60.0/24, 10.40.65.0/24}
 
 match out on tun0 from trustednets to any nat-to (tun0)
 
 pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
 pass in quick proto tcp from localhost to any port {http,https} rdr-to 
127.0.0.1 

 port 3128
 pass quick proto {gre, esp, tcp, udp} from E.F.G.H to (tun0)
 block log quick from bruteforce
 pass inet proto icmp all icmp-type {echoreq, unreach}
 pass in on tun0 inet proto tcp from any to any port ssh keep state 
(max-src-conn 

 6, max-src-conn-rate 3/1, overload bruteforce flush global) rdr-to 
10.40.60.1
 pass on em0 from trustednets to any
 
 
 --Branch Office--
 cat /etc/ipsec.conf:
 me=E.F.G.H
 mypeer=A.B.C.D
 mypsk=mypsk
 
 ike esp from $me to $mypeer peer $mypeer \
   main auth hmac-sha1 enc 3des group modp1024 \
   srcid $me dstid $mypeer \
   psk $mypsk
 
 cat /etc/hostname.gre0:
 inet 172.16.254.2 255.255.255.252 172.16.254.1
 tunnel E.F.G.H A.B.C.D
 !route add -net 10.40.60 -netmask 255.255.255.0 172.16.254.1
 
 Firewall disabled for now - nothing other than sshd and isakmpd are running.
 
 Thanks,
 Matt
 

Matt

did you put on the branch router a route like 
route add A.B.C.D branch isp gateway ?

beware that if you issue just route add default 172.16.254.1 then your
router will tend to also route the vpn traffic through your tunnel, so
you get a race condition.

claudiu.


-- 
Claudiu Pruna clau...@net-go.net

Re: Routing all traffic through IPSEC VPN

[Christiano F. Haesbaert]

On 12 April 2011 23:53, Matt S maschwa...@yahoo.com wrote:
 Hello @misc:

 I am up against a stumper.  I have a Site-to-Site IPSEC VPN working
beautifully.
  However, I would like the remote site to route all of its traffic through
the
 VPN.  After googling, I seemed to come up with a suggestion to do a route
change
 -net 0.0.0.0/0 gateway which didn't work well.  I think it might have to
do
 with NAT.  The main office is doing the NAT.  Perhaps I need to some sort of
NAT
 traversal on the VPN??

 Here is my setup:

 --Main Office--
 cat /etc/ipsec.conf:
 me=A.B.C.D
 mypeer=E.F.G.H
 mypsk=mypsk

 ike passive esp from $me to $mypeer peer $mypeer \
  main auth hmac-sha1 enc 3des group modp1024 \
  srcid $me dstid $mypeer \
  psk $mypsk

 cat /etc/hostname.gre0:
 inet 172.16.254.1 255.255.255.252 172.16.254.2
 tunnel A.B.C.D E.F.G.H
 !route add -net 10.40.65 -netmask 255.255.255.0 172.16.254.2

 cat /etc/pf.conf:
 set skip on {lo, gre0, enc0}

 anchor ftp-proxy/*

 block in log all
 pass out all

 antispoof for tun0
 table bruteforce persist
 table trustednets {10.40.60.0/24, 10.40.65.0/24}

 match out on tun0 from trustednets to any nat-to (tun0)

 pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
 pass in quick proto tcp from localhost to any port {http,https} rdr-to
127.0.0.1
 port 3128
 pass quick proto {gre, esp, tcp, udp} from E.F.G.H to (tun0)
 block log quick from bruteforce
 pass inet proto icmp all icmp-type {echoreq, unreach}
 pass in on tun0 inet proto tcp from any to any port ssh keep state
(max-src-conn
 6, max-src-conn-rate 3/1, overload bruteforce flush global) rdr-to
10.40.60.1
 pass on em0 from trustednets to any


 --Branch Office--
 cat /etc/ipsec.conf:
 me=E.F.G.H
 mypeer=A.B.C.D
 mypsk=mypsk

 ike esp from $me to $mypeer peer $mypeer \
  main auth hmac-sha1 enc 3des group modp1024 \
  srcid $me dstid $mypeer \
  psk $mypsk

 cat /etc/hostname.gre0:
 inet 172.16.254.2 255.255.255.252 172.16.254.1
 tunnel E.F.G.H A.B.C.D
 !route add -net 10.40.60 -netmask 255.255.255.0 172.16.254.1

 Firewall disabled for now - nothing other than sshd and isakmpd are
running.

 Thanks,
 Matt



I do that with openvpn.
You need to add a default route to the other vpn end (so that every
traffic goes through the tunnel)
Then you add a host route to the external address of the other way via
the local gateway (so that the tunnel will work).
Since host routes have priority over network routes, this works fine.
You obviously need to nat the incoming traffic from the tunnel to the
outside world.

Re: Routing all traffic through IPSEC VPN

[Matt S]

Christiano:

Thanks for your help.  So, if I am understanding correctly, I need to create 
the 
following routes on the branch office router (OpenBSD):

route change -net 0.0.0.0/0 172.16.254.2  #I tried using 10.40.60.1 as the 
gateway and I got a network unreachable error
route add -host 172.16.254.2 A.B.C.D.E

My setup is using a GRE tunnel.  I have the GRE Tunnel endpoints configured on 
/30 subnet.  There might be a gap in my understanding.

Thank you again,
Matt


On 12 April 2011 23:53, Matt S maschwa...@yahoo.com wrote:
 Hello @misc:

 I am up against a stumper.  I have a Site-to-Site IPSEC VPN working 
beautifully.
  However, I would like the remote site to route all of its traffic through the
 VPN.  After googling, I seemed to come up with a suggestion to do a route 
change
 -net 0.0.0.0/0 gateway which didn't work well.  I think it might have to do
 with NAT.  The main office is doing the NAT.  Perhaps I need to some sort of 
NAT
 traversal on the VPN??

 Here is my setup:

 --Main Office--
 cat /etc/ipsec.conf:
 me=A.B.C.D
 mypeer=E.F.G.H
 mypsk=mypsk

 ike passive esp from $me to $mypeer peer $mypeer \
  main auth hmac-sha1 enc 3des group modp1024 \
  srcid $me dstid $mypeer \
  psk $mypsk

 cat /etc/hostname.gre0:
 inet 172.16.254.1 255.255.255.252 172.16.254.2
 tunnel A.B.C.D E.F.G.H
 !route add -net 10.40.65 -netmask 255.255.255.0 172.16.254.2

 cat /etc/pf.conf:
 set skip on {lo, gre0, enc0}

 anchor ftp-proxy/*

 block in log all
 pass out all

 antispoof for tun0
 table bruteforce persist
 table trustednets {10.40.60.0/24, 10.40.65.0/24}

 match out on tun0 from trustednets to any nat-to (tun0)

 pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
 pass in quick proto tcp from localhost to any port {http,https} rdr-to 
127.0.0.1
 port 3128
 pass quick proto {gre, esp, tcp, udp} from E.F.G.H to (tun0)
 block log quick from bruteforce
 pass inet proto icmp all icmp-type {echoreq, unreach}
 pass in on tun0 inet proto tcp from any to any port ssh keep state 
(max-src-conn
 6, max-src-conn-rate 3/1, overload bruteforce flush global) rdr-to 
10.40.60.1
 pass on em0 from trustednets to any


 --Branch Office--
 cat /etc/ipsec.conf:
 me=E.F.G.H
 mypeer=A.B.C.D
 mypsk=mypsk

 ike esp from $me to $mypeer peer $mypeer \
  main auth hmac-sha1 enc 3des group modp1024 \
  srcid $me dstid $mypeer \
  psk $mypsk

 cat /etc/hostname.gre0:
 inet 172.16.254.2 255.255.255.252 172.16.254.1
 tunnel E.F.G.H A.B.C.D
 !route add -net 10.40.60 -netmask 255.255.255.0 172.16.254.1

 Firewall disabled for now - nothing other than sshd and isakmpd are running.

 Thanks,
 Matt



I do that with openvpn.
You need to add a default route to the other vpn end (so that every
traffic goes through the tunnel)
Then you add a host route to the external address of the other way via
the local gateway (so that the tunnel will work).
Since host routes have priority over network routes, this works fine.
You obviously need to nat the incoming traffic from the tunnel to the
outside world.

Re: Routing all traffic through IPSEC VPN

[Claudiu Pruna]

On Wed, 2011-04-13 at 07:34 -0700, Matt S wrote:
 Hi Claudiu:
 
 
 Thank you for your reply.  I did try your suggestion to do a route add
 A.B.C.D.E isp gateway and unfortunately it did not work so well.  I
 lost connectivity to the branch altogether over the VPN.  At least I
 have console access :)  Once I removed the route, I regained
 connectivity over the vpn.  Perhaps, I can show you the routing
 tables, if that will help?
 
 
 Main
 Internet:
 DestinationGatewayFlags   Refs  Use   Mtu
  Prio Iface
 default   phnx-dsl-gw55-247. UGS   19  1629401 -
 8 tun0
 10.40.60/24link#1 UC 20 -
 4 em0
 10.40.60.3 00:24:2c:07:d4:d0  UHLc   1 3217 -
 4 em0
 10.40.60.5 link#1 UHLc   1  847 -
 4 em0
 10.40.65/24172.16.254.2   UG 0   22 -
  32 gre0
 phnx-dsl-gw55-247. 71-223-148-144.phn UH 1   12  1492
 4 tun0
 loopback   localhost  UGRS   00 33200
 8 lo0
 localhost   localhost  UH 0   60 33200
 4 lo0
 172.16.254.1/32172.16.254.2   UG 00 -
  32 gre0
 172.16.254.2   172.16.254.1   UH 2  157 -
 4 gre0
 BASE-ADDRESS.MCAST localhost  URS00 33200
 8 lo0
 
 
 Branch
 DestinationGatewayFlags   Refs  Use   Mtu
  Prio Iface
 default206.125.169.97 UGS311772 -
 8 em0
 10.40.60/24172.16.254.1   UG 1   50 -
  32 gre0
 10.40.65/24link#4 UC 10 -
 4 vether0
 10.40.65.1 fe:e1:ba:d0:da:7e  UHLc   04 -
 4 lo0
 loopback   localhost  UGRS   00 33160
 8 lo0
 localhost  localhost  UH 1   60 33160
 4 lo0
 172.16.254.1   172.16.254.2   UH 2   87 -
 4 gre0
 172.16.254.2/32172.16.254.1   UG 00 -
  32 gre0
 206.125.169.96/29  link#1 UC 20 -
 4 em0
 206.125.169.97 00:0d:65:ab:c8:bf  UHLc   10 -
 4 em0
 matthew-schwartz.c 52:54:00:27:26:22  UHLc   00 -
 4 lo0
 BASE-ADDRESS.MCAST localhost  URS00 33160
 8 lo0
 
 
 
 On Tue, 2011-04-12 at 19:53 -0700, Matt S wrote:
  Hello @misc:
  
  I am up against a stumper.  I have a Site-to-Site IPSEC VPN working
 beautifully. 
   However, I would like the remote site to route all of its traffic
 through the 
  VPN.  After googling, I seemed to come up with a suggestion to do a
 route change 
  -net 0.0.0.0/0 gateway which didn't work well.  I think it might
 have to do 
  with NAT.  The main office is doing the NAT.  Perhaps I need to some
 sort of NAT 
  traversal on the VPN??
  
  Here is my setup:
  
  --Main Office--
  cat /etc/ipsec.conf:
  me=A.B.C.D
  mypeer=E.F.G.H
  mypsk=mypsk
  
  ike passive esp from $me to $mypeer peer $mypeer \
   main auth hmac-sha1 enc 3des group modp1024 \
   srcid $me dstid $mypeer \
   psk $mypsk
  
  cat /etc/hostname.gre0:
  inet 172.16.254.1 255.255.255.252 172.16.254.2
  tunnel A.B.C.D E.F.G.H
  !route add -net 10.40.65 -netmask 255.255.255.0 172.16.254.2
  
  cat /etc/pf.conf:
  set skip on {lo, gre0, enc0}
  
  anchor ftp-proxy/*
  
  block in log all
  pass out all
  
  antispoof for tun0
  table bruteforce persist
  table trustednets {10.40.60.0/24, 10.40.65.0/24}
  
  match out on tun0 from trustednets to any nat-to (tun0)
  
  pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
  pass in quick proto tcp from localhost to any port {http,https}
 rdr-to 127.0.0.1 
  port 3128
  pass quick proto {gre, esp, tcp, udp} from E.F.G.H to (tun0)
  block log quick from bruteforce
  pass inet proto icmp all icmp-type {echoreq, unreach}
  pass in on tun0 inet proto tcp from any to any port ssh keep state
 (max-src-conn 
  6, max-src-conn-rate 3/1, overload bruteforce flush global) rdr-to
 10.40.60.1
  pass on em0 from trustednets to any
  
  
  --Branch Office--
  cat /etc/ipsec.conf:
  me=E.F.G.H
  mypeer=A.B.C.D
  mypsk=mypsk
  
  ike esp from $me to $mypeer peer $mypeer \
   main auth hmac-sha1 enc 3des group modp1024 \
   srcid $me dstid $mypeer \
   psk $mypsk
  
  cat /etc/hostname.gre0:
  inet 172.16.254.2 255.255.255.252 172.16.254.1
  tunnel E.F.G.H A.B.C.D
  !route add -net 10.40.60 -netmask 255.255.255.0 172.16.254.1
  
  Firewall disabled for now - nothing other than sshd and isakmpd are
 running.
  
  Thanks,
  Matt
  
 
 Matt
 
 did you put on the branch router a route like 
 route add A.B.C.D branch isp gateway ?
 
 beware that if you issue just route add default 172.16.254.1 then your
 router will tend to also route the vpn traffic through your tunnel, so
 you get a race condition.
 
 claudiu.
 
 
 -- 
 Claudiu Pruna clau...@net-go.net
 
 
 
supposing, as I understood, yhay you want to route ALL the branch's

Re: Routing all traffic through IPSEC VPN

[Matt S]

Thank you for all of the help.  I am effectively giving up on doing it this 
way.  OpenVPN seems to have facilities to make it easier to achieve what I want 
to do.  I appreciate all of the time and effort spent.


On Wed, 2011-04-13 at 07:34 -0700, Matt S wrote:
 Hi Claudiu:
 
 
 Thank you for your reply.  I did try your suggestion to do a route add
 A.B.C.D.E isp gateway and unfortunately it did not work so well.  I
 lost connectivity to the branch altogether over the VPN.  At least I
 have console access :)  Once I removed the route, I regained
 connectivity over the vpn.  Perhaps, I can show you the routing
 tables, if that will help?
 
 
 Main
 Internet:
 DestinationGatewayFlags   Refs  Use   Mtu
  Prio Iface
 default   phnx-dsl-gw55-247. UGS   19  1629401 -
 8 tun0
 10.40.60/24link#1 UC 20 -
 4 em0
 10.40.60.3 00:24:2c:07:d4:d0  UHLc   1 3217 -
 4 em0
 10.40.60.5 link#1 UHLc   1  847 -
 4 em0
 10.40.65/24172.16.254.2   UG 0   22 -
  32 gre0
 phnx-dsl-gw55-247. 71-223-148-144.phn UH 1   12  1492
 4 tun0
 loopback   localhost  UGRS   00 33200
 8 lo0
 localhost   localhost  UH 0   60 33200
 4 lo0
 172.16.254.1/32172.16.254.2   UG 00 -
  32 gre0
 172.16.254.2   172.16.254.1   UH 2  157 -
 4 gre0
 BASE-ADDRESS.MCAST localhost  URS00 33200
 8 lo0
 
 
 Branch
 DestinationGatewayFlags   Refs  Use   Mtu
  Prio Iface
 default206.125.169.97 UGS311772 -
 8 em0
 10.40.60/24172.16.254.1   UG 1   50 -
  32 gre0
 10.40.65/24link#4 UC 10 -
 4 vether0
 10.40.65.1 fe:e1:ba:d0:da:7e  UHLc   04 -
 4 lo0
 loopback   localhost  UGRS   00 33160
 8 lo0
 localhost  localhost  UH 1   60 33160
 4 lo0
 172.16.254.1   172.16.254.2   UH 2   87 -
 4 gre0
 172.16.254.2/32172.16.254.1   UG 00 -
  32 gre0
 206.125.169.96/29  link#1 UC 20 -
 4 em0
 206.125.169.97 00:0d:65:ab:c8:bf  UHLc   10 -
 4 em0
 matthew-schwartz.c 52:54:00:27:26:22  UHLc   00 -
 4 lo0
 BASE-ADDRESS.MCAST localhost  URS00 33160
 8 lo0
 
 
 
 On Tue, 2011-04-12 at 19:53 -0700, Matt S wrote:
  Hello @misc:
  
  I am up against a stumper.  I have a Site-to-Site IPSEC VPN working
 beautifully. 
   However, I would like the remote site to route all of its traffic
 through the 
  VPN.  After googling, I seemed to come up with a suggestion to do a
 route change 
  -net 0.0.0.0/0 gateway which didn't work well.  I think it might
 have to do 
  with NAT.  The main office is doing the NAT.  Perhaps I need to some
 sort of NAT 
  traversal on the VPN??
  
  Here is my setup:
  
  --Main Office--
  cat /etc/ipsec.conf:
  me=A.B.C.D
  mypeer=E.F.G.H
  mypsk=mypsk
  
  ike passive esp from $me to $mypeer peer $mypeer \
   main auth hmac-sha1 enc 3des group modp1024 \
   srcid $me dstid $mypeer \
   psk $mypsk
  
  cat /etc/hostname.gre0:
  inet 172.16.254.1 255.255.255.252 172.16.254.2
  tunnel A.B.C.D E.F.G.H
  !route add -net 10.40.65 -netmask 255.255.255.0 172.16.254.2
  
  cat /etc/pf.conf:
  set skip on {lo, gre0, enc0}
  
  anchor ftp-proxy/*
  
  block in log all
  pass out all
  
  antispoof for tun0
  table bruteforce persist
  table trustednets {10.40.60.0/24, 10.40.65.0/24}
  
  match out on tun0 from trustednets to any nat-to (tun0)
  
  pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
  pass in quick proto tcp from localhost to any port {http,https}
 rdr-to 127.0.0.1 
  port 3128
  pass quick proto {gre, esp, tcp, udp} from E.F.G.H to (tun0)
  block log quick from bruteforce
  pass inet proto icmp all icmp-type {echoreq, unreach}
  pass in on tun0 inet proto tcp from any to any port ssh keep state
 (max-src-conn 
  6, max-src-conn-rate 3/1, overload bruteforce flush global) rdr-to
 10.40.60.1
  pass on em0 from trustednets to any
  
  
  --Branch Office--
  cat /etc/ipsec.conf:
  me=E.F.G.H
  mypeer=A.B.C.D
  mypsk=mypsk
  
  ike esp from $me to $mypeer peer $mypeer \
   main auth hmac-sha1 enc 3des group modp1024 \
   srcid $me dstid $mypeer \
   psk $mypsk
  
  cat /etc/hostname.gre0:
  inet 172.16.254.2 255.255.255.252 172.16.254.1
  tunnel E.F.G.H A.B.C.D
  !route add -net 10.40.60 -netmask 255.255.255.0 172.16.254.1
  
  Firewall disabled for now - nothing other than sshd and isakmpd are
 running.
  
  Thanks,
  Matt
  
 
 Matt
 
 did you put on the branch router a route like 
 route add A.B.C.D branch isp gateway ?
 
 beware that if you issue just route add default 172.16.254.1 then your
 router

Re: Routing all traffic through IPSEC VPN

[Christiano F. Haesbaert]

On Wed, Apr 13, 2011 at 02:53:29PM -0700, Matt S wrote:
 Thank you for all of the help.  I am effectively giving up on doing it this 
 way.  OpenVPN seems to have facilities to make it easier to achieve what I 
 want 
 to do.  I appreciate all of the time and effort spent.
 
 

There should be no difference in using OpenVPN or IPSEC, your problem is not
related to that. I'll try this again.

1. Make the VPN
2. Add a host route to the other-end external address through the local gateway.
3. Add the default gateway as the other-end VPN address.

So your tunnel will be able to reach the other side (the external host route).
Sorry but I'm a bit busy to understand your setup.

I'm sending you a script which does that.

 On Wed, 2011-04-13 at 07:34 -0700, Matt S wrote:
  Hi Claudiu:
  
  
  Thank you for your reply.  I did try your suggestion to do a route add
  A.B.C.D.E isp gateway and unfortunately it did not work so well.  I
  lost connectivity to the branch altogether over the VPN.  At least I
  have console access :)  Once I removed the route, I regained
  connectivity over the vpn.  Perhaps, I can show you the routing
  tables, if that will help?
  
  
  Main
  Internet:
  DestinationGatewayFlags   Refs  Use   Mtu
   Prio Iface
  default   phnx-dsl-gw55-247. UGS   19  1629401 -
  8 tun0
  10.40.60/24link#1 UC 20 -
  4 em0
  10.40.60.3 00:24:2c:07:d4:d0  UHLc   1 3217 -
  4 em0
  10.40.60.5 link#1 UHLc   1  847 -
  4 em0
  10.40.65/24172.16.254.2   UG 0   22 -
   32 gre0
  phnx-dsl-gw55-247. 71-223-148-144.phn UH 1   12  1492
  4 tun0
  loopback   localhost  UGRS   00 33200
  8 lo0
  localhost   localhost  UH 0   60 33200
  4 lo0
  172.16.254.1/32172.16.254.2   UG 00 -
   32 gre0
  172.16.254.2   172.16.254.1   UH 2  157 -
  4 gre0
  BASE-ADDRESS.MCAST localhost  URS00 33200
  8 lo0
  
  
  Branch
  DestinationGatewayFlags   Refs  Use   Mtu
   Prio Iface
  default206.125.169.97 UGS311772 -
  8 em0
  10.40.60/24172.16.254.1   UG 1   50 -
   32 gre0
  10.40.65/24link#4 UC 10 -
  4 vether0
  10.40.65.1 fe:e1:ba:d0:da:7e  UHLc   04 -
  4 lo0
  loopback   localhost  UGRS   00 33160
  8 lo0
  localhost  localhost  UH 1   60 33160
  4 lo0
  172.16.254.1   172.16.254.2   UH 2   87 -
  4 gre0
  172.16.254.2/32172.16.254.1   UG 00 -
   32 gre0
  206.125.169.96/29  link#1 UC 20 -
  4 em0
  206.125.169.97 00:0d:65:ab:c8:bf  UHLc   10 -
  4 em0
  matthew-schwartz.c 52:54:00:27:26:22  UHLc   00 -
  4 lo0
  BASE-ADDRESS.MCAST localhost  URS00 33160
  8 lo0
  
  
  
  On Tue, 2011-04-12 at 19:53 -0700, Matt S wrote:
   Hello @misc:
   
   I am up against a stumper.  I have a Site-to-Site IPSEC VPN working
  beautifully. 
However, I would like the remote site to route all of its traffic
  through the 
   VPN.  After googling, I seemed to come up with a suggestion to do a
  route change 
   -net 0.0.0.0/0 gateway which didn't work well.  I think it might
  have to do 
   with NAT.  The main office is doing the NAT.  Perhaps I need to some
  sort of NAT 
   traversal on the VPN??
   
   Here is my setup:
   
   --Main Office--
   cat /etc/ipsec.conf:
   me=A.B.C.D
   mypeer=E.F.G.H
   mypsk=mypsk
   
   ike passive esp from $me to $mypeer peer $mypeer \
main auth hmac-sha1 enc 3des group modp1024 \
srcid $me dstid $mypeer \
psk $mypsk
   
   cat /etc/hostname.gre0:
   inet 172.16.254.1 255.255.255.252 172.16.254.2
   tunnel A.B.C.D E.F.G.H
   !route add -net 10.40.65 -netmask 255.255.255.0 172.16.254.2
   
   cat /etc/pf.conf:
   set skip on {lo, gre0, enc0}
   
   anchor ftp-proxy/*
   
   block in log all
   pass out all
   
   antispoof for tun0
   table bruteforce persist
   table trustednets {10.40.60.0/24, 10.40.65.0/24}
   
   match out on tun0 from trustednets to any nat-to (tun0)
   
   pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
   pass in quick proto tcp from localhost to any port {http,https}
  rdr-to 127.0.0.1 
   port 3128
   pass quick proto {gre, esp, tcp, udp} from E.F.G.H to (tun0)
   block log quick from bruteforce
   pass inet proto icmp all icmp-type {echoreq, unreach}
   pass in on tun0 inet proto tcp from any to any port ssh keep state
  (max-src-conn 
   6, max-src-conn-rate 3/1, overload bruteforce flush global) rdr-to
  10.40.60.1
   pass on em0 from trustednets to any
   
   
   --Branch Office--
   cat /etc/ipsec.conf

Routing all traffic through IPSEC VPN

[Matt S]

Hello @misc:

I am up against a stumper.  I have a Site-to-Site IPSEC VPN working 
beautifully. 
 However, I would like the remote site to route all of its traffic through the 
VPN.  After googling, I seemed to come up with a suggestion to do a route 
change 
-net 0.0.0.0/0 gateway which didn't work well.  I think it might have to do 
with NAT.  The main office is doing the NAT.  Perhaps I need to some sort of 
NAT 
traversal on the VPN??

Here is my setup:

--Main Office--
cat /etc/ipsec.conf:
me=A.B.C.D
mypeer=E.F.G.H
mypsk=mypsk

ike passive esp from $me to $mypeer peer $mypeer \
  main auth hmac-sha1 enc 3des group modp1024 \
  srcid $me dstid $mypeer \
  psk $mypsk

cat /etc/hostname.gre0:
inet 172.16.254.1 255.255.255.252 172.16.254.2
tunnel A.B.C.D E.F.G.H
!route add -net 10.40.65 -netmask 255.255.255.0 172.16.254.2

cat /etc/pf.conf:
set skip on {lo, gre0, enc0}

anchor ftp-proxy/*

block in log all
pass out all

antispoof for tun0
table bruteforce persist
table trustednets {10.40.60.0/24, 10.40.65.0/24}

match out on tun0 from trustednets to any nat-to (tun0)

pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
pass in quick proto tcp from localhost to any port {http,https} rdr-to 
127.0.0.1 
port 3128
pass quick proto {gre, esp, tcp, udp} from E.F.G.H to (tun0)
block log quick from bruteforce
pass inet proto icmp all icmp-type {echoreq, unreach}
pass in on tun0 inet proto tcp from any to any port ssh keep state 
(max-src-conn 
6, max-src-conn-rate 3/1, overload bruteforce flush global) rdr-to 10.40.60.1
pass on em0 from trustednets to any


--Branch Office--
cat /etc/ipsec.conf:
me=E.F.G.H
mypeer=A.B.C.D
mypsk=mypsk

ike esp from $me to $mypeer peer $mypeer \
  main auth hmac-sha1 enc 3des group modp1024 \
  srcid $me dstid $mypeer \
  psk $mypsk

cat /etc/hostname.gre0:
inet 172.16.254.2 255.255.255.252 172.16.254.1
tunnel E.F.G.H A.B.C.D
!route add -net 10.40.60 -netmask 255.255.255.0 172.16.254.1

Firewall disabled for now - nothing other than sshd and isakmpd are running.

Thanks,
Matt

Re: Force Internet traffic out IPSec VPN

[Stuart Henderson]

On 2011-04-07, Andrew Klettke aklet...@opticfusion.net wrote:
 We have a working IPSec VPN between two 4.8 endpoints. One of them is at 
 a remote location, and the other at the main office. The remote location 
 has its own external, routable IP (to establish the VPN), and an 
 internal subnet behind it. The main office has its own external IP, 
 though which it is NATing its own internal subnet.

 Basically, I want to force all internet traffic from the remote, 
 internal subnet through the main office's internal gateway so it can NAT 
 out from there.

 I've been attempting to accomplish this with route-to and reply-to 
 rules on the remote box, but have had no luck. I know IPSec keeps its 
 own routing table, is this interfering? Is this possible to do with PF?

OpenBSD's IPsec implementation uses flows which must strictly match
the traffic's source/destination(/port/protocol) in order for it to be
handled by IPsec (the first approach as described in rfc3884 2.3;
see the paragraphs at the end of that section).

So if you want the traffic to be directly handled by IPsec, the
flows you configure must match all internet traffic, i.e. they must
be between the remote subnet and 0.0.0.0/0. (You will have additional
considerations due to the natting if the VPN endpoint is also the
router for internet traffic).

The alternative is to have IPsec protect just a gif(4) or gre(4)
tunnel between the VPN endpoints, and use route table entries to pass
internet traffic over that tunnel. This is easier to grasp as the
usual PF/routing operations work with it. For this to work you'll
need OpenBSD or an OS with a compatible tunnel device (e.g. gif
or gre) at both ends and I think you probably also need static IP
addresses at both ends.

I strongly recommend testing on a non-production network especially
if you will be attempting to use 0.0.0.0/0 flows. Get it wrong and
you'll send *all* traffic from the main office's VPN endpoint to the
remote location. (this is amusing, but not while it's happening :-)

Re: Force Internet traffic out IPSec VPN

[Ivan Nudzik]

It is not demand of PF... It's about IPSec behavior. IPSec tunnels could
be established between exact 2 IPs, or exact 2 IP networks. You can't
have IP net on one side of tunnel and rest of Internet on other side,
which is case you wrote about.
Solutions:
1. Build IP-IP IPSec and then build GRE tunnel on those 2 IP. You could
route anything over GRE tunnel. Beware of encapsulation overhead, cause
it is tunnel in tunnel.
2. Use OpenVPN instead of IPSec. It is far less painful.

I.

On Thu, 2011-04-07 at 16:51 -0700, Andrew Klettke wrote:
 We have a working IPSec VPN between two 4.8 endpoints. One of them is at 
 a remote location, and the other at the main office. The remote location 
 has its own external, routable IP (to establish the VPN), and an 
 internal subnet behind it. The main office has its own external IP, 
 though which it is NATing its own internal subnet.
 
 Basically, I want to force all internet traffic from the remote, 
 internal subnet through the main office's internal gateway so it can NAT 
 out from there.
 
 I've been attempting to accomplish this with route-to and reply-to 
 rules on the remote box, but have had no luck. I know IPSec keeps its 
 own routing table, is this interfering? Is this possible to do with PF?

Re: Force Internet traffic out IPSec VPN

[Evgeniy Sudyr]

What about mobile VPN?  For PUBKEY auth you can use UFQDN identities

http://openbsd.org/papers/asiabsdcon07-ipsec/mgp00065.html

and
http://www.openbsd.org/cgi-bin/man.cgi?query=isakmpd
http://www.openbsd.org/cgi-bin/man.cgi?query=ipsec.conf

On Fri, Apr 8, 2011 at 10:41 AM, Ivan Nudzik ivan.nud...@gmail.com wrote:
 It is not demand of PF... It's about IPSec behavior. IPSec tunnels could
 be established between exact 2 IPs, or exact 2 IP networks. You can't
 have IP net on one side of tunnel and rest of Internet on other side,
 which is case you wrote about.
 Solutions:
 1. Build IP-IP IPSec and then build GRE tunnel on those 2 IP. You could
 route anything over GRE tunnel. Beware of encapsulation overhead, cause
 it is tunnel in tunnel.
 2. Use OpenVPN instead of IPSec. It is far less painful.

 I.

 On Thu, 2011-04-07 at 16:51 -0700, Andrew Klettke wrote:
 We have a working IPSec VPN between two 4.8 endpoints. One of them is at
 a remote location, and the other at the main office. The remote location
 has its own external, routable IP (to establish the VPN), and an
 internal subnet behind it. The main office has its own external IP,
 though which it is NATing its own internal subnet.

 Basically, I want to force all internet traffic from the remote,
 internal subnet through the main office's internal gateway so it can NAT
 out from there.

 I've been attempting to accomplish this with route-to and reply-to
 rules on the remote box, but have had no luck. I know IPSec keeps its
 own routing table, is this interfering? Is this possible to do with PF?





-- 
--
With regards,
Eugene Sudyr

Force Internet traffic out IPSec VPN

[Andrew Klettke]

We have a working IPSec VPN between two 4.8 endpoints. One of them is at 
a remote location, and the other at the main office. The remote location 
has its own external, routable IP (to establish the VPN), and an 
internal subnet behind it. The main office has its own external IP, 
though which it is NATing its own internal subnet.


Basically, I want to force all internet traffic from the remote, 
internal subnet through the main office's internal gateway so it can NAT 
out from there.


I've been attempting to accomplish this with route-to and reply-to 
rules on the remote box, but have had no luck. I know IPSec keeps its 
own routing table, is this interfering? Is this possible to do with PF?


--
Thanks,

Andrew Klettke
Systems Admin
Optic Fusion NOC
253-830-2943

Re: ipsec vpn unexpected flow

[Stuart Henderson]

On 2010/11/27 23:47, Andrea Parazzini wrote:
 On Fri, 26 Nov 2010 12:58:09 + (UTC), Stuart Henderson
 s...@spacehopper.org wrote:
  isakmpd.policy(5), and have some aspirin ready for the inevitable
  headache.
 
 
 Stuart is right.
 I tried to play with isakmpd.policy and it's rather complicated.
 Reading the manuals again I noticed the -a option of isakmpd.
 So my new configuration could be the following:
 
 /etc/rc.conf.local
 ipsec=YES
 isakmpd_flags=-a -K -v
 
 /etc/ipsec.conf
 ike active esp tunnel \
   from 10.1.0.0/16 to 192.168.90.0/24 \
   local A.B.C.D peer W.X.Y.Z \
   main auth hmac-sha1 enc 3des group modp1024 \
   quick auth hmac-sha1 enc 3des group modp1024 \
   psk PRESHAREDKEY
 flow esp from 0.0.0.0/0 to 192.168.90.0/24 \
   local A.B.C.D peer W.X.Y.Z
 
 It might work? What do you think?

Hmm, yes it might do. If you test and find out, please let misc@ know :)

Re: ipsec vpn unexpected flow

[Andrea Parazzini]

On Thu, 11/25/10, Andrea Parazzini a.parazz...@sirtisistemi.net wrote:
 Hi,
 we have a vpn connection with a customer.
 The remote peer is not under our management.
 Our box is an OpenBSD 4.7 i386.
 We have configured the vpn as follows:
 
 /etc/rc.conf.local
 ipsec=YES
 isakmpd_flags=-K -v
 
 /etc/ipsec.conf
 ike active esp tunnel \
   from 10.1.0.0/16 (0.0.0.0/0) to 192.168.90.0/24 \
   local A.B.C.D peer W.X.Y.Z \
   main auth hmac-sha1 enc 3des group modp1024 \
   quick auth hmac-sha1 enc 3des group modp1024 \
   psk PRESHAREDKEY
 
 
 The vpn works fine, but there is a strange thing.
 Whith netstat -nrf encap I see something like:
 
 Source Port  DestinationPort  Proto  SA
 192.168.71/24  0 10.1/160 0  W.X.Y.Z/esp/use/in
 10.1/160 192.168.71/24  0 0  W.X.Y.Z/esp/require/out
 192.168.90/24  0 default0 0  W.X.Y.Z/esp/use/in
 default0 192.168.90/24  0 0  W.X.Y.Z/esp/require/out
 
 As you can see there is a flow that is not configured on our box.
 It is probably configured on the remote peer.
 Is a normal behavior?
 How can I protect myself from an incorrect configuration on the remote
 peer?


On Fri, 26 Nov 2010 12:58:09 + (UTC), Stuart Henderson
s...@spacehopper.org wrote:
 isakmpd.policy(5), and have some aspirin ready for the inevitable
 headache.


Stuart is right.
I tried to play with isakmpd.policy and it's rather complicated.
Reading the manuals again I noticed the -a option of isakmpd.
So my new configuration could be the following:

/etc/rc.conf.local
ipsec=YES
isakmpd_flags=-a -K -v

/etc/ipsec.conf
ike active esp tunnel \
  from 10.1.0.0/16 to 192.168.90.0/24 \
  local A.B.C.D peer W.X.Y.Z \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group modp1024 \
  psk PRESHAREDKEY
flow esp from 0.0.0.0/0 to 192.168.90.0/24 \
  local A.B.C.D peer W.X.Y.Z

It might work? What do you think?

Thanks.

Regards,
Andrea

Re: ipsec vpn unexpected flow

[Andrea Parazzini]

On Fri, 26 Nov 2010 10:32:59 +0330, Bahador NazariFard
bahador.nazarif...@gmail.com wrote:
 On Fri, Nov 26, 2010 at 8:50 AM, Andrea Parazzini 
 a.parazz...@sirtisistemi.net wrote:
 
 Hi,
 from 10.1.0.0/16 is the network id that I would negotiate with the
 remote
 peer.
 (0.0.0.0/0) is our real network, we have a lot of networks behind this
 box.
 We perform NAT on traffic leaving through the VPN tunnel.


 192.168.71/24  0 10.1/160 0  W.X.Y.Z/esp/use/in
 10.1/160 192.168.71/24  0 0  W.X.Y.Z/esp/require/out
 Why this flow?
 I would only flows defined in the configuration files.

 Thanks
 Andrea


 On Thu, 25 Nov 2010 13:39:33 -0800 (PST), Damon Schlosser
 damons...@yahoo.com wrote:
  1. what is the (0.0.0.0/0) good for?2. how are you inspecting traffic
 in
  the
  tunnel?3. is nat allowed in the tunnel? 4. you may have let in more
  networks
  than you realize
  -damon
 
  --- On Thu, 11/25/10, Andrea Parazzini a.parazz...@sirtisistemi.net
  wrote:
 
  From: Andrea Parazzini a.parazz...@sirtisistemi.net
  Subject: ipsec vpn unexpected flow
  To: misc@openbsd.org
  Date: Thursday, November 25, 2010, 2:40 PM
 
  Hi,
  we have a vpn connection with a customer.
  The remote peer is not under our management.
  Our box is an OpenBSD 4.7 i386.
  We have configured the vpn as follows:
 
  /etc/rc.conf.local
  ipsec=YES
  isakmpd_flags=-K -v
 
  /etc/ipsec.conf
  ike active esp tunnel \
from 10.1.0.0/16 (0.0.0.0/0) to 192.168.90.0/24 \
local A.B.C.D peer W.X.Y.Z \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des group modp1024 \
psk PRESHAREDKEY
 
 
  The vpn works fine, but there is a strange thing.
  Whith netstat -nrf encap I see something like:
 
  Source Port  DestinationPort  Proto  SA
  192.168.71/24  0 10.1/160 0  W.X.Y.Z/esp/use/in
  10.1/160 192.168.71/24  0 0 
 W.X.Y.Z/esp/require/out
  192.168.90/24  0 default0 0  W.X.Y.Z/esp/use/in
  default0 192.168.90/24  0 0 
 W.X.Y.Z/esp/require/out
 
  As you can see there is a flow that is not configured on our box.
  It is probably configured on the remote peer.
  Is a normal behavior?
  How can I protect myself from an incorrect configuration on the remote
  peer?
 
  Thanks.
 
  Regards,
  Andrea


 pleas read ipsec.conf manual page agian specially OUTGOING NETWORK
 ADDRESS
 TRANSLATION Section.
 10.1.0.0/16 (0.0.0.0/0) means you want to nat anything from 
 10.1.0.0/16to
 0.0.0.0/0 !
 I think this is so strange .I can not understand your configuration rule.
 Are you sure your traffic really pass through your IPSec Tunnel.
 

Yes the traffic pass through the tunnel. The vpn works fine.
If I understand the manual 10.1.0.0/16 (0.0.0.0/0) means that
I can perform NAT on traffic leaving through the VPN tunnel to 10.1.0.0/16
addresses.

Thanks.
Andrea

Re: ipsec vpn unexpected flow

[Stuart Henderson]

On 2010-11-25, Andrea Parazzini a.parazz...@sirtisistemi.net wrote:
 As you can see there is a flow that is not configured on our box.
 It is probably configured on the remote peer.
 Is a normal behavior?

Yes. This is especially fun when you end up accidentally routing
all traffic from a 100mb-connected site down an ADSL link by getting
a flow for 0.0.0.0/0 added...

 How can I protect myself from an incorrect configuration on the remote
 peer?

isakmpd.policy(5), and have some aspirin ready for the inevitable headache.

Re: ipsec vpn unexpected flow

[Andrea Parazzini]

On Fri, 26 Nov 2010 12:58:09 + (UTC), Stuart Henderson
s...@spacehopper.org wrote:
 On 2010-11-25, Andrea Parazzini a.parazz...@sirtisistemi.net wrote:
 As you can see there is a flow that is not configured on our box.
 It is probably configured on the remote peer.
 Is a normal behavior?
 
 Yes. This is especially fun when you end up accidentally routing
 all traffic from a 100mb-connected site down an ADSL link by getting
 a flow for 0.0.0.0/0 added...
 
 How can I protect myself from an incorrect configuration on the remote
 peer?
 
 isakmpd.policy(5), and have some aspirin ready for the inevitable
 headache.

Thank you for your reply.
Now I have to study the manual.

Regards,
Andrea

ipsec vpn unexpected flow

[Andrea Parazzini]

Hi,
we have a vpn connection with a customer.
The remote peer is not under our management.
Our box is an OpenBSD 4.7 i386.
We have configured the vpn as follows:

/etc/rc.conf.local
ipsec=YES
isakmpd_flags=-K -v

/etc/ipsec.conf
ike active esp tunnel \
  from 10.1.0.0/16 (0.0.0.0/0) to 192.168.90.0/24 \
  local A.B.C.D peer W.X.Y.Z \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group modp1024 \
  psk PRESHAREDKEY


The vpn works fine, but there is a strange thing.
Whith netstat -nrf encap I see something like:

Source Port  DestinationPort  Proto  SA
192.168.71/24  0 10.1/160 0  W.X.Y.Z/esp/use/in
10.1/160 192.168.71/24  0 0  W.X.Y.Z/esp/require/out
192.168.90/24  0 default0 0  W.X.Y.Z/esp/use/in
default0 192.168.90/24  0 0  W.X.Y.Z/esp/require/out

As you can see there is a flow that is not configured on our box.
It is probably configured on the remote peer.
Is a normal behavior?
How can I protect myself from an incorrect configuration on the remote
peer?

Thanks.

Regards,
Andrea

Re: ipsec vpn unexpected flow

[Damon Schlosser]

1. what is the (0.0.0.0/0) good for?2. how are you inspecting traffic in the
tunnel?3. is nat allowed in the tunnel? 4. you may have let in more networks
than you realize
-damon

--- On Thu, 11/25/10, Andrea Parazzini a.parazz...@sirtisistemi.net wrote:

From: Andrea Parazzini a.parazz...@sirtisistemi.net
Subject: ipsec vpn unexpected flow
To: misc@openbsd.org
Date: Thursday, November 25, 2010, 2:40 PM

Hi,
we have a vpn connection with a customer.
The remote peer is not under our management.
Our box is an OpenBSD 4.7 i386.
We have configured the vpn as follows:

/etc/rc.conf.local
ipsec=YES
isakmpd_flags=-K -v

/etc/ipsec.conf
ike active esp tunnel \
  from 10.1.0.0/16 (0.0.0.0/0) to 192.168.90.0/24 \
  local A.B.C.D peer W.X.Y.Z \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group modp1024 \
  psk PRESHAREDKEY


The vpn works fine, but there is a strange thing.
Whith netstat -nrf encap I see something like:

Source Port  DestinationPort  Proto  SA
192.168.71/24  0 10.1/160 0  W.X.Y.Z/esp/use/in
10.1/160 192.168.71/24  0 0  W.X.Y.Z/esp/require/out
192.168.90/24  0 default0 0  W.X.Y.Z/esp/use/in
default0 192.168.90/24  0 0  W.X.Y.Z/esp/require/out

As you can see there is a flow that is not configured on our box.
It is probably configured on the remote peer.
Is a normal behavior?
How can I protect myself from an incorrect configuration on the remote
peer?

Thanks.

Regards,
Andrea

Re: ipsec vpn unexpected flow

[Andrea Parazzini]

Hi,
from 10.1.0.0/16 is the network id that I would negotiate with the remote
peer.
(0.0.0.0/0) is our real network, we have a lot of networks behind this
box.
We perform NAT on traffic leaving through the VPN tunnel.


192.168.71/24  0 10.1/160 0  W.X.Y.Z/esp/use/in
10.1/160 192.168.71/24  0 0  W.X.Y.Z/esp/require/out
Why this flow?
I would only flows defined in the configuration files.

Thanks
Andrea


On Thu, 25 Nov 2010 13:39:33 -0800 (PST), Damon Schlosser
damons...@yahoo.com wrote:
 1. what is the (0.0.0.0/0) good for?2. how are you inspecting traffic in
 the
 tunnel?3. is nat allowed in the tunnel? 4. you may have let in more
 networks
 than you realize
 -damon
 
 --- On Thu, 11/25/10, Andrea Parazzini a.parazz...@sirtisistemi.net
 wrote:
 
 From: Andrea Parazzini a.parazz...@sirtisistemi.net
 Subject: ipsec vpn unexpected flow
 To: misc@openbsd.org
 Date: Thursday, November 25, 2010, 2:40 PM
 
 Hi,
 we have a vpn connection with a customer.
 The remote peer is not under our management.
 Our box is an OpenBSD 4.7 i386.
 We have configured the vpn as follows:
 
 /etc/rc.conf.local
 ipsec=YES
 isakmpd_flags=-K -v
 
 /etc/ipsec.conf
 ike active esp tunnel \
   from 10.1.0.0/16 (0.0.0.0/0) to 192.168.90.0/24 \
   local A.B.C.D peer W.X.Y.Z \
   main auth hmac-sha1 enc 3des group modp1024 \
   quick auth hmac-sha1 enc 3des group modp1024 \
   psk PRESHAREDKEY
 
 
 The vpn works fine, but there is a strange thing.
 Whith netstat -nrf encap I see something like:
 
 Source Port  DestinationPort  Proto  SA
 192.168.71/24  0 10.1/160 0  W.X.Y.Z/esp/use/in
 10.1/160 192.168.71/24  0 0  W.X.Y.Z/esp/require/out
 192.168.90/24  0 default0 0  W.X.Y.Z/esp/use/in
 default0 192.168.90/24  0 0  W.X.Y.Z/esp/require/out
 
 As you can see there is a flow that is not configured on our box.
 It is probably configured on the remote peer.
 Is a normal behavior?
 How can I protect myself from an incorrect configuration on the remote
 peer?
 
 Thanks.
 
 Regards,
 Andrea

Re: ipsec vpn unexpected flow

[Bahador NazariFard]

On Fri, Nov 26, 2010 at 8:50 AM, Andrea Parazzini 
a.parazz...@sirtisistemi.net wrote:

 Hi,
 from 10.1.0.0/16 is the network id that I would negotiate with the
 remote
 peer.
 (0.0.0.0/0) is our real network, we have a lot of networks behind this
 box.
 We perform NAT on traffic leaving through the VPN tunnel.


 192.168.71/24  0 10.1/160 0  W.X.Y.Z/esp/use/in
 10.1/160 192.168.71/24  0 0  W.X.Y.Z/esp/require/out
 Why this flow?
 I would only flows defined in the configuration files.

 Thanks
 Andrea


 On Thu, 25 Nov 2010 13:39:33 -0800 (PST), Damon Schlosser
 damons...@yahoo.com wrote:
  1. what is the (0.0.0.0/0) good for?2. how are you inspecting traffic in
  the
  tunnel?3. is nat allowed in the tunnel? 4. you may have let in more
  networks
  than you realize
  -damon
 
  --- On Thu, 11/25/10, Andrea Parazzini a.parazz...@sirtisistemi.net
  wrote:
 
  From: Andrea Parazzini a.parazz...@sirtisistemi.net
  Subject: ipsec vpn unexpected flow
  To: misc@openbsd.org
  Date: Thursday, November 25, 2010, 2:40 PM
 
  Hi,
  we have a vpn connection with a customer.
  The remote peer is not under our management.
  Our box is an OpenBSD 4.7 i386.
  We have configured the vpn as follows:
 
  /etc/rc.conf.local
  ipsec=YES
  isakmpd_flags=-K -v
 
  /etc/ipsec.conf
  ike active esp tunnel \
from 10.1.0.0/16 (0.0.0.0/0) to 192.168.90.0/24 \
local A.B.C.D peer W.X.Y.Z \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des group modp1024 \
psk PRESHAREDKEY
 
 
  The vpn works fine, but there is a strange thing.
  Whith netstat -nrf encap I see something like:
 
  Source Port  DestinationPort  Proto  SA
  192.168.71/24  0 10.1/160 0  W.X.Y.Z/esp/use/in
  10.1/160 192.168.71/24  0 0  W.X.Y.Z/esp/require/out
  192.168.90/24  0 default0 0  W.X.Y.Z/esp/use/in
  default0 192.168.90/24  0 0  W.X.Y.Z/esp/require/out
 
  As you can see there is a flow that is not configured on our box.
  It is probably configured on the remote peer.
  Is a normal behavior?
  How can I protect myself from an incorrect configuration on the remote
  peer?
 
  Thanks.
 
  Regards,
  Andrea


pleas read ipsec.conf manual page agian specially OUTGOING NETWORK ADDRESS
TRANSLATION Section.
10.1.0.0/16 (0.0.0.0/0) means you want to nat anything from  10.1.0.0/16to
0.0.0.0/0 !
I think this is so strange .I can not understand your configuration rule.
Are you sure your traffic really pass through your IPSec Tunnel.


-- 
Gula_Gula =;=; BNF

IPSEC VPN

[Jorge Medina]

1.- IPSEC VPN Load Balancer connections it's make that posible ?
2.- somebody have benchmark or something to reference CPU consuption
of  vpn tunel

--
Jorge Andris Medina Oliva.

IPSEC VPN

[Matt S]

Hello

I am wondering if anyone whom uses OpenBSD as an IPSEC VPN concentrator
could provide an example configuration.  I am planning on using OpenBSD 4.7
to achieve this and I need to be able to support multiple road warrior users
who will have dynamic IP addresses.  If possible, I would also like for
each user to authenticate with their own certificate.  I always do best with
examples so anyone that could provide one, it would be greatly appreciated.
I managed to get IPSEC working between two branch offices based on the man
page example.

Thank you in advance,
Matt

test : ipsec vpn and mac road warrior

[openbsd]

Hi,

I ve done theses tests :

inter...@work (OpenBSD PF)(ip fixe)  (dynamic ip) Home (A mac)

I mounted vpn on mac to Work with third software : VPN Tracker
VPN is OK, i can ping my openbsd gateway and ping my Windows 7 Workstation.
But i cant access any ressource except pings. Why ? Enc0 is not used ?
Someone can help me ?

@Work:
I configured my /etc/ipsec.conf to accept dynamic clients
Here a bit of my pf .conf concerning VPN :
...
set skip on { lo enc0 }
block log all
pass in on egress proto udp from any to egress port 500
pass in on egress proto udp from any to egress port 4500
pass in on egress proto esp from any to egress
...

IPSec VPN and tunnel mode routing

[Girish Venkatachalam]

Dear all,

I find no explicit mention of how to encapsulate and decapsulate IPsec
protected packets in tunnel mode.

Are we supposed to use gre0 or gif0 interface to add routes?

I am able to create SAs using automatic keying with isakmpd and 1 line
in ipsec.conf.

But I am unable to connect two private networks. How to achieve that?

Google did not help at all. Neither did a paper on www.openbsd.org.

Thanks.

-Girish

-- 
Gayatri Hitech
web: http://gayatri-hitech.com

SpamCheetah Spam filter:
http://spam-cheetah.com

Re: IPSec VPN and tunnel mode routing

[Schöberle Dániel]

 Dear all,

 I find no explicit mention of how to encapsulate and decapsulate IPsec
 protected packets in tunnel mode.

 Are we supposed to use gre0 or gif0 interface to add routes?

 I am able to create SAs using automatic keying with isakmpd and 1 line
 in ipsec.conf.

 But I am unable to connect two private networks. How to achieve that?

 Google did not help at all. Neither did a paper on www.openbsd.org.

 Thanks.

 -Girish

This was for 3.8 but it still works (at least on 4.6):

http://www.symantec.com/connect/articles/zero-ipsec-4-minutes
(note that symantec mangled the \n characters in the configuration examples,
you will need to add extra new lines)

No need to setup any tunnelling ifaces by hand, everything comes out of enc0.
If you're firewalling keep in mind that sometimes IPSec packets may come out
twice from the same interface. tcpdumping on pflog is your friend.

Regards, Daniel.

Re: IPSec VPN and tunnel mode routing

[Stuart Henderson]

On 2010-03-30, Girish Venkatachalam girishvenkatacha...@gmail.com wrote:
 Dear all,

 I find no explicit mention of how to encapsulate and decapsulate IPsec
 protected packets in tunnel mode.

 Are we supposed to use gre0 or gif0 interface to add routes?

 I am able to create SAs using automatic keying with isakmpd and 1 line
 in ipsec.conf.

If you describe your configuration, the output from the relevant
commands (e.g. sudo ipsecctl -sa, netstat -n), what if any changes
you've made to PF rules to accommodate the vpn, how you're testing,
etc, perhaps someone can help.

 But I am unable to connect two private networks. How to achieve that?

the simplest way is basically: setup automatic keying, add an
ike esp... line to ipsec.conf, turn on IP forwarding, make sure
the firewall is setup correctly, and that's about it.

Re: IPSec VPN and tunnel mode routing

[Girish Venkatachalam]

Many thanks for the answers. I should certainly thank Daniel with a full heart
since he really made my day. Many thanks.

On Tue, Mar 30, 2010 at 6:32 PM, Stuart Henderson s...@spacehopper.org wrote:
 I am able to create SAs using automatic keying with isakmpd and 1 line
 in ipsec.conf.

 If you describe your configuration, the output from the relevant
 commands (e.g. sudo ipsecctl -sa, netstat -n), what if any changes
 you've made to PF rules to accommodate the vpn, how you're testing,
 etc, perhaps someone can help.

I always thought that pf should have nothing to do with IPsec VPN at least
till we get the basic traffic going. And that is what I did. I shall add pf now.

 But I am unable to connect two private networks. How to achieve that?

 the simplest way is basically: setup automatic keying, add an
 ike esp... line to ipsec.conf, turn on IP forwarding, make sure
 the firewall is setup correctly, and that's about it.

Well I want IPsec to do the tunnel encapsulation and routing for me first.

Crypto as well of course. ;)

I checked with the command given in the enc man page.

# tcpdump -envps 1500 -i enc0 -l

I shall write a webpage about this since others might lose sleep over this.

Rather disappointing that such a basic crypto setup is poorly documented.

For now, I shall give my two cents worth tips for the archives.

(This is without NAT or any firewall in between and no pf on either
tunnel endpoints. pfctl -d ;)

host A IP : 192.168.11.3
host A private net: 10.1.1.0/24

host B IP: 192.168.11.4
host B private net: 10.2.2.0/24

In case it is not clear, I am trying to access 10.2.2.0/24 machines
from 10.1.1.0/24 machines using host A and host B as tunnel endpoints.
IPsec is only between
host A and B. Hope I don't confuse.

Obviously things will work in reverse too.

Here is the sequence of commands I run on host A.

Before we start, here is the Zeroth step. We need to have the public
key of one IP available on the other side.

On host B(192.168.11.4)

#scp /etc/isakmpd/local.pub 192.168.11.3:/etc/isakmpd/pubkeys/ipv4/192.168.11.4

Ditto on host A.

#scp /etc/isakmpd/local.pub 192.168.11.4:/etc/isakmpd/pubkeys/ipv4/192.168.11.3

Now the game starts.

# pfctl -d

# isakmpd -K

# cat /etc/ipsec.cont
 localip = 192.168.11.3
remoteip = 192.168.11.4
local_net = 10.1.1.0/24
remote_net = 10.2.2.0/24
ike esp from $local_net to $remote_net peer $remoteip
ike esp from $localip to $remote_net peer $remoteip
ike esp from $localip to $remoteip

(this is what the file contains)

# ipsecctl -n -f /etc/ipsec.conf
(Things are fine)

Now start things up.

# ipsecctl -f /etc/ipsec.conf

-
On to host B now.

# pfctl -d

# isakmpd -K

# cat /etc/ipsec.conf
localip = 192.168.11.4
remoteip = 192.168.11.3
local_net = 10.2.2.0/24
remote_net = 10.1.1.0/24
ike passive esp from $local_net to $remote_net peer $remoteip
ike passive esp from $localip to $remote_net peer $remoteip
ike passive esp from $localip to $remoteip

#ipsecctl -f /etc/ipsec.conf

---
Now we are all set. No more configuration necessary.

Now I come to the part that hurt me the most.

How to test that we are doing things correctly?

# ipsecctl -F

will flush all SAs.

# ipsecctl -sa

should give an output like this.


FLOWS:
flow esp in from 192.168.11.3 to 192.168.11.4 peer 192.168.11.3 srcid
192.168.11.4/32 dstid 192.168.11.3/32 type use
flow esp out from 192.168.11.4 to 192.168.11.3 peer 192.168.11.3 srcid
192.168.11.4/32 dstid 192.168.11.3/32 type require
flow esp in from 10.1.1.0/24 to 10.2.2.0/24 peer 192.168.11.3 srcid
192.168.11.4/32 dstid 192.168.11.3/32 type use
flow esp out from 10.2.2.0/24 to 10.1.1.0/24 peer 192.168.11.3 srcid
192.168.11.4/32 dstid 192.168.11.3/32 type require
flow esp in from 192.168.11.3 to 10.2.2.0/24 peer 192.168.11.3 srcid
192.168.11.4/32 dstid 192.168.11.3/32 type use
flow esp out from 10.2.2.0/24 to 192.168.11.3 peer 192.168.11.3 srcid
192.168.11.4/32 dstid 192.168.11.3/32 type require

SAD:
esp tunnel from 192.168.11.4 to 192.168.11.3 spi 0x2c37b55e auth
hmac-sha2-256 enc aes
esp tunnel from 192.168.11.3 to 192.168.11.4 spi 0x5d7e114e auth
hmac-sha2-256 enc aes
esp tunnel from 192.168.11.4 to 192.168.11.3 spi 0x70420aad auth
hmac-sha2-256 enc aes
esp tunnel from 192.168.11.3 to 192.168.11.4 spi 0xa0b67b12 auth
hmac-sha2-256 enc aes
esp tunnel from 192.168.11.4 to 192.168.11.3 spi 0xa84c08c3 auth
hmac-sha2-256 enc aes
esp tunnel from 192.168.11.3 to 192.168.11.4 spi 0xf517c42c auth
hmac-sha2-256 enc aes


Don't worry. I am not revealing any secret information. We are using
automatic keying here.

Since I have only two machines I have to simulate private networks. Here is a
very useful tip. Interface aliasing saves the day.

I run this on host A to simulate the 10.1.1.0/24 network. I only need one IP.

# ifconfig rl0 alias 10.1.1.1 netmask 255.255.255.0

If you type ifconfig, you

IPSEC VPN and NAT

[openbsd]

It works, i remove my enc0 from set skip on {lo enc0 } like told Mitja.
Thank's to Mitja.

Ipsec VPN and NAT

[openbsd]

I'm trying to do vpn ipsec with nat. (I can do fully some test @ work with
have sdsl with 5 ip address)

To resume i want to do ipsec vpn between Site A (192.168.0.0/24) and Site B
(192.168.0.0/24). They have same network address.
So i ve done done with this good article :
http://undeadly.org/cgi?action=artic...20090127205841 (from Mitja)
Tunnel is monted but i can't connect to workstations. Can you help me ?
Here is what i ve done :

PC1PF1INTERNET-PF2---PC2

PF1 : OpenBSD 4.6
rl0 : connected to sdsl, have an ip fixe (11.11.11.11), this interface is
the egress.
rl1 : our network, his ip address : 192.168.0.11
DNS : ISP
There's only PF,isakmpd(-K), and ipsec services. No dhcp, no bind

PF2 : OpenBSD 4.6
rl0 : connected to sdsl, have an ip fixe (22.22.22.22), this interface is
the egress.
rl1 : our network, his ip address : 192.168.0.12
There's only PF,isakmpd(-K), and ipsec services. No dhcp, no bind

PC1 : XP PRO (workgroup)
IP : 192.168.0.93/24 should be 192.168.1.93 using NAT
Gateway : 192.168.0.11
DNS : ISP

PC2 : XP PRO (workgroup)
IP : 192.168.0.92/24 should be 192.168.2.92 using NAT
Gateway : 192.168.0.12
DNS : ISP

When i type on a PF machine (PF1 or PF2) : ipsecctl -sa, there's flow and
sa.
Tunnel is monted. I can verify it using tcpdump -i enc0 on PF1, type
tracert 192.168.1.93 (using PC2). There's traffic encrypted

ipsecctl -sa on PF2 :
FLOWS:
flow esp in from 192.168.1.0/24 to 192.168.0.0/24 peer 11.11.11.11 srcid
22.22.22.22/32 dstid 11.11.11.11/32 type use
flow esp out from 192.168.0.0/24 to 192.168.1.0/24 peer 11.11.11.11 srcid
22.22.22.22/32 dstid 11.11.11.11/32 type require
SAD:
esp tunnel from 11.11.11.11 to 22.22.22.22 spi 0x14f92c81 auth hmac-sha1
enc aes-256
esp tunnel from 22.22.22.22 to 11.11.11.11 spi 0xb1b3d4a6 auth hmac-sha1
enc aes-256

Test i ve done :
On machine PC1(192.168.0.93), i tryied ping PC2 using NAT 192.168.2.92
(doesn't work), i ve the following on the PF2 console using tcpdump -i enc0
:

tcpdump: listening on enc0, link-type ENC
18:31:36.608877 (authentic,confidential): SPI 0x14f92c81: 192.168.0.93  
192.168.2.92: icmp: echo request (encap)
18:31:41.818990 (authentic,confidential): SPI 0x14f92c81: 192.168.0.93 
192.168.2.92: icmp: echo request (encap)
18:31:47.329048 (authentic,confidential): SPI 0x14f92c81: 192.168.0.93  
192.168.2.92: icmp: echo request (encap)
18:31:52.846117 (authentic,confidential): SPI 0x14f92c81: 192.168.0.93  
192.168.2.92: icmp: echo request (encap)
^C
4 packets received by filter
0 packets dropped by kernel

Conclusion, something is missing, PF can't redirect packet to the machine.
he doesnt know who is 192.168.1.93 (should be 192.168.0.93 in real)
Have you an idea? On the document :
http://undeadly.org/cgi?action=artic...20090127205841 He talks about need
to use split dns to it works ? is it really necessary ? If yes how can i do
that ?
Can you help me ? See pf.conf, ipsec.conf :

ipsec.conf (PF1):
ike esp from 192.168.1.0/24 (192.168.0.0/24) to 192.168.2.0/24 \
peer 22.22.22.22 \
main auth hmac-sha1 enc aes-256 group modp1024 \
quick auth hmac-sha1 enc aes-256 group modp1024 \
psk thisisanexample

ipsec.conf (PF2):
ike esp from 192.168.2.0/24 (192.168.0.0/24) to 192.168.1.0/24 \
peer 11.11.11.11 \
main auth hmac-sha1 enc aes-256 group modp1024 \
quick auth hmac-sha1 enc aes-256 group modp1024 \
psk thisisanexample

pf.conf (PF1) :
me=11.11.11.11
distant=22.22.22.22
set skip on {loi enc0}
set block-policy drop
nat on egress from rl1:network to any - egress
binat on enc0 inet from 192.168.0.0/24 to 192.168.2.0/24 - 192.168.1.0/24 
block in log on egress
pass in on egress inet proto udp from $distant to $me port 500
pass in on egress inet proto udp from $distant to $me port 4500
pass in on egress proto esp from $distant to $me
pass out keep state

pf.conf (PF2) :
me=22.22.22.22
distant=11.11.11.11
set skip on {loi enc0}
set block-policy drop
nat on egress from rl1:network to any - egress
binat on enc0 inet from 192.168.0.0/24 to 192.168.1.0/24 - 192.168.2.0/24 
block in log on egress
pass in on egress inet proto udp from $distant to $me port 500
pass in on egress inet proto udp from $distant to $me port 4500
pass in on egress proto esp from $distant to $me
pass out keep state

Re: Ipsec VPN and NAT

[openbsd]

Yes it is lo for loopback, a keyboard error.
I can't do any modification because i'm not any more at work.
I will do changes Monday (GMT+4). I keep you inform, and of course thank
you very much for your help.

On Fri, 12 Mar 2010 16:54:50 +0100, Mitja MuEeniD
 / Kerberos.si /
mi...@kerberos.si wrote:
 Just a quick reply because I was just going out - try to remove enc0 from
 the set skip on {loi enc0} line. If you skip enc0 then the binat rule
on
 enc0 won't work. Also, what is loi? You probably mean lo.
 
 If this doesn't help I'll look at your config again later tonight.
 
 -Original Message-
 From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf
Of
 open...@e-solutions.re
 Sent: Friday, March 12, 2010 4:34 PM
 To: misc@openbsd.org
 Subject: Ipsec VPN and NAT
 
 I'm trying to do vpn ipsec with nat. (I can do fully some test @ work
 with
 have sdsl with 5 ip address)
 
 To resume i want to do ipsec vpn between Site A (192.168.0.0/24) and
Site
 B
 (192.168.0.0/24). They have same network address.
 So i ve done done with this good article :
 http://undeadly.org/cgi?action=artic...20090127205841 (from Mitja)
 Tunnel is monted but i can't connect to workstations. Can you help me ?
 Here is what i ve done :
 
 PC1PF1INTERNET-PF2---PC2
 
 PF1 : OpenBSD 4.6
 rl0 : connected to sdsl, have an ip fixe (11.11.11.11), this interface
is
 the egress.
 rl1 : our network, his ip address : 192.168.0.11
 DNS : ISP
 There's only PF,isakmpd(-K), and ipsec services. No dhcp, no bind
 
 PF2 : OpenBSD 4.6
 rl0 : connected to sdsl, have an ip fixe (22.22.22.22), this interface
is
 the egress.
 rl1 : our network, his ip address : 192.168.0.12
 There's only PF,isakmpd(-K), and ipsec services. No dhcp, no bind
 
 PC1 : XP PRO (workgroup)
 IP : 192.168.0.93/24 should be 192.168.1.93 using NAT
 Gateway : 192.168.0.11
 DNS : ISP
 
 PC2 : XP PRO (workgroup)
 IP : 192.168.0.92/24 should be 192.168.2.92 using NAT
 Gateway : 192.168.0.12
 DNS : ISP
 
 When i type on a PF machine (PF1 or PF2) : ipsecctl -sa, there's flow
and
 sa.
 Tunnel is monted. I can verify it using tcpdump -i enc0 on PF1, type
 tracert 192.168.1.93 (using PC2). There's traffic encrypted
 
 ipsecctl -sa on PF2 :
 FLOWS:
 flow esp in from 192.168.1.0/24 to 192.168.0.0/24 peer 11.11.11.11 srcid
 22.22.22.22/32 dstid 11.11.11.11/32 type use
 flow esp out from 192.168.0.0/24 to 192.168.1.0/24 peer 11.11.11.11
srcid
 22.22.22.22/32 dstid 11.11.11.11/32 type require
 SAD:
 esp tunnel from 11.11.11.11 to 22.22.22.22 spi 0x14f92c81 auth hmac-sha1
 enc aes-256
 esp tunnel from 22.22.22.22 to 11.11.11.11 spi 0xb1b3d4a6 auth hmac-sha1
 enc aes-256
 
 Test i ve done :
 On machine PC1(192.168.0.93), i tryied ping PC2 using NAT 192.168.2.92
 (doesn't work), i ve the following on the PF2 console using tcpdump -i
 enc0
 :
 
 tcpdump: listening on enc0, link-type ENC
 18:31:36.608877 (authentic,confidential): SPI 0x14f92c81: 192.168.0.93 
 192.168.2.92: icmp: echo request (encap)
 18:31:41.818990 (authentic,confidential): SPI 0x14f92c81: 192.168.0.93 
 192.168.2.92: icmp: echo request (encap)
 18:31:47.329048 (authentic,confidential): SPI 0x14f92c81: 192.168.0.93 
 192.168.2.92: icmp: echo request (encap)
 18:31:52.846117 (authentic,confidential): SPI 0x14f92c81: 192.168.0.93 
 192.168.2.92: icmp: echo request (encap)
 ^C
 4 packets received by filter
 0 packets dropped by kernel
 
 Conclusion, something is missing, PF can't redirect packet to the
 machine.
 he doesnt know who is 192.168.1.93 (should be 192.168.0.93 in real)
 Have you an idea? On the document :
 http://undeadly.org/cgi?action=artic...20090127205841 He talks about
need
 to use split dns to it works ? is it really necessary ? If yes how can i
 do
 that ?
 Can you help me ? See pf.conf, ipsec.conf :
 
 ipsec.conf (PF1):
 ike esp from 192.168.1.0/24 (192.168.0.0/24) to 192.168.2.0/24 \
 peer 22.22.22.22 \
 main auth hmac-sha1 enc aes-256 group modp1024 \
 quick auth hmac-sha1 enc aes-256 group modp1024 \
 psk thisisanexample
 
 ipsec.conf (PF2):
 ike esp from 192.168.2.0/24 (192.168.0.0/24) to 192.168.1.0/24 \
 peer 11.11.11.11 \
 main auth hmac-sha1 enc aes-256 group modp1024 \
 quick auth hmac-sha1 enc aes-256 group modp1024 \
 psk thisisanexample
 
 pf.conf (PF1) :
 me=11.11.11.11
 distant=22.22.22.22
 set skip on {loi enc0}
 set block-policy drop
 nat on egress from rl1:network to any - egress
 binat on enc0 inet from 192.168.0.0/24 to 192.168.2.0/24 -
 192.168.1.0/24
 block in log on egress
 pass in on egress inet proto udp from $distant to $me port 500
 pass in on egress inet proto udp from $distant to $me port 4500
 pass in on egress proto esp from $distant to $me
 pass out keep state
 
 pf.conf (PF2) :
 me=22.22.22.22
 distant=11.11.11.11
 set skip on {loi enc0}
 set block-policy drop
 nat on egress from rl1:network to any - egress
 binat on enc0 inet from 192.168.0.0/24 to 192.168.1.0/24 -
 192.168.2.0/24
 block in log on egress
 pass in on egress

Ipsec vpn and nat

[openbsd]

Hello, we have to connect factory using ipsec vpn and nat.
The factory server (windows 2003) will send his backup
to our NAS using FTP,so : Site A and Site B (factory)

Site A , OpenBSD 4.5 -RELEASE, used like firewall (and ftpproxy)
Ip address (provided by IAP): 11.11.11.11(Egress), IP : 10.0.0.113(lan)

Site B , We don't know what they use ad equipements, but they have 
a hundred sites connected by ipsec vpn.
Ip address (provided by IAP) : 22.22.22.22

Our 2 sites have the same network : 10.0.0.0/24 (us) and 10.0.0.0/8
(factory)
So we need to implement translations
We have decided that :
Site A will use : 192.168.192.0/24
Site B will use : 192.168.191.0/24

Admin factory has sent me informations to configure my ipsec vpn on
OpenBSD:
Authentication Mode: Preshared Keys
Diffie-Hellman Group 2 (1024 bit)
Encryption Algorithm: AES 256 
Hashing Algoritm: SHA-1
Negotiation Mode: Main
Lifetime : 28800 sec

IPSec-Parameter:
Perfect Forward Secrecy: Group 2
Encapsulation : ESP
Encryption Algorithm: AES 256
Authentication Algorithm : SHA-1
Encapsulation Mode: Tunnel
Lifetime : 3600 sec

the preshared key : haiku (it is just an example, not the true key)

I have already read man pages of ipsec.conf, pf.conf, isakmpd, ipsecctl
And of course : http://undeadly.org/cgi?action=articlesid=20090127205841
I come back. For over a week, i break my head to run the vpn, 
it is mounted, but there is no traffic, what is more, 
i have a problem about phase 2 in ipsec.conf.

Now the error i have is :
/var/log/daemon :
Sep 17 11:00:01 sdsl114 newsyslog[5191]: logfile turned over
Sep 17 11:04:18 sdsl114 savecore: no core dump
Sep 17 11:04:19 sdsl114 isakmpd[19476]: 
responder_recv_HASH_SA_NONCE: 
peer proposed invalid phase 2 IDs: initiator id
192.168.191.0/255.255.255.0, responder id 192.168.192.0/255.255.255.0
Sep 17 11:04:19 sdsl114 isakmpd[19476]: 
dropped message from 22.22.22.22 port 500 due to notification type
INVALID_ID_INFORMATION
Sep 17 11:04:19 sdsl114 ftp-proxy[13321]: listening on 11.11.11.11 port 21

ipsecctl -sa :
flow esp in from 192.168.191.0/24 to 10.0.0.0/24 
peer 22.22.22.22 srcid 11.11.11.11/32 dstid 22.22.22.22/32 type use
flow esp out from 10.0.0.0/24 to 192.168.191.0/24 
peer 22.22.22.22 srcid 11.11.11.11/32 dstid 22.22.22.22/32 type require
SAD:
esp tunnel from 11.11.11.11 to 22.22.22.22 spi 0x5f3b4329 auth hmac-sha1
enc aes-256
esp tunnel from 22.22.22.22 to 11.11.11.11 spi 0x60ecca8f auth hmac-sha1
enc aes-256

What i have done :
ipsec.conf :
ike esp from 192.168.192.0/24 (10.0.0.0/24) to 192.168.191.0/24 \
peer 22.22.22.22 \
main auth hmac-sha1 enc aes-256 group modp1024 \
quick auth hmac-sha1 enc aes-256 group modp1024 \
psk Haiku 

pf.conf :
lan=bge0:network
int_if=bge0
gw=11.11.11.11
ftp_server=10.0.0.115


clients_out={ ssh, www, https, imap, imaps, pop3, pop3s, smtp, smtps, \
3389, ftp, ftp-data, 8080, submission, sftp } 


set require-order no
set skip on { lo, enc0 }
set block-policy drop
scrub in

nat-anchor ftp-proxy/*
nat on egress from $lan - egress 
rdr-anchor ftp-proxy/*
binat on enc0 inet from 10.0.0.0/24 to 192.168.1.0/24 - 192.168.192.0/24

block log all

pass quick proto esp keep state
pass quick proto udp to port { isakmp, ipsec-nat-t } keep state

pass quick inet proto { tcp, udp } from $lan to any port domain
pass inet proto icmp all icmp-type { echoreq, unreach }
pass inet proto tcp from $lan to any port $clients_out
pass out on egress from $gw to any

pass in on egress inet proto tcp to $gw port 21 \
flags S/SA keep state
pass out on $int_if inet proto tcp to $ftp_server port 21 \
user proxy flags S/SA keep state
anchor ftp-proxy/*

My dmesg :
OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 2.80GHz (GenuineIntel 686-class) 2.80 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 1073291264 (1023MB)
avail mem = 1029545984 (981MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 09/08/03, BIOS32 rev. 0 @ 0xf1780,
SMBIOS rev. 2.3 @ 0xf3180 (42 entries)
bios0: vendor Award Software, Inc. version 6.00.23 RV (09/08/2003) date
09/08/2003
bios0: Hewlett-Packard HP Server
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP BOOT SPCR APIC
acpi0: wakeup devices NIC0(S1) UAR1(S4) UAR2(S4) PS2K(S4) PS2M(S4) USB0(S1)
PCI0(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 11, 16 pins
ioapic0: misconfigured as apic 1, remapped to apid 2
ioapic1 at mainbus0: apid 3 pa 0xfec01000, version 11, 16 pins
ioapic1: misconfigured as apic 2, remapped to apid 3
ioapic2 at mainbus0: apid 4 pa 0xfec02000, version 11, 16 pins
ioapic2: misconfigured as apic 3, remapped to apid 4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
acpiprt0 at acpi0: bus 0

OpenBSD Road Warrior connecting to L2TP/IPSec VPN?

[Aaron W. Hsu]

Hell All,

I am trying to connect to my University's VPN System, with little luck, 
I am not sure how to even begin, though I have found Undeadly articles 
on IPSec in Under 4 Minutes, as well as some various tutorials and 
documents on connecting OpenBSD Servers to other Servers and gateways.

I don't even know if this is possible, but looking at ipsec.conf, I can't 
see any details about how I would configure my system to connect to 
this VPN. Is it possible? If so, how?

I've added just a basic ipsec.conf line:

ike dynamic esp from any to any peer ipsec.indiana.edu psk hermanbwells 

But I haven't gotten much further than that. Does any one have any 
suggestions? The University's Guide to the VPN is: 

http://kb.iu.edu/data/ajrq.html

Aaron Hsu

Re: OpenBSD Road Warrior connecting to L2TP/IPSec VPN?

[Christoph Leser]

 -Urspr|ngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Im Auftrag von Aaron W. Hsu
 Gesendet: Montag, 22. September 2008 20:04
 An: misc@openbsd.org
 Betreff: OpenBSD Road Warrior connecting to L2TP/IPSec VPN?


 Hell All,

 I am trying to connect to my University's VPN System, with
 little luck,
 I am not sure how to even begin, though I have found Undeadly
 articles
 on IPSec in Under 4 Minutes, as well as some various tutorials and
 documents on connecting OpenBSD Servers to other Servers and gateways.

 I don't even know if this is possible, but looking at
 ipsec.conf, I can't
 see any details about how I would configure my system to connect to
 this VPN. Is it possible? If so, how?

 I've added just a basic ipsec.conf line:

   ike dynamic esp from any to any peer ipsec.indiana.edu
 psk hermanbwells

 But I haven't gotten much further than that. Does any one have any
 suggestions? The University's Guide to the VPN is:

   http://kb.iu.edu/data/ajrq.html

   Aaron Hsu



From the cited page I would guess they use l2tp over ipsec. I think this is
not suppoerted by openbsd, but I may be wrong.

Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)

[Dirk Mast]

This config works for me: 

OpenBSD 4.3 as GW and Debian Linux with OpenSWAN as client, and
the package ike is installed under Linux, too.



OpenBSD:
ike esp from any to 172.16.1.98 quick auth hmac-sha1 enc aes
group modp1024 psk IMTEHLINUXCLIENT


Linux:
/etc/ipsec.conf
version 2.0
cono,
g setup
interfaces=wlan0
plutodebug=ballb
nat traversal=yes
plutowait=yes
nhelpers=0
uniqueids=yes
conn openbsd
type=transport
left=172.16.1.98
right=172.16.1.1
rightsubnet=0.0.0.0/0
keyexchange=ike
esp=aes128-sha1
ike=aes128-sha1-modp1024
auto=route
auth=esp
authby=secret
pfs=yes
keyingtries=rekeymargin=4m
disablearrivalcheck=no
rekey=yes
aggrmode=no

/etc/ipsec.secrets
172.16.1.1 172.16.1.98: PSK IMTEHLINUXCLIENT

Laurent CARON wrote:

 Sean Malloy wrote:
 It looks like you are trying to use different encryption algorithms and
 hash functions for the phase 2 SA. They need to match at both end points.
 It looks like the Linux box is configured to do 3DES and SHA1. The
 OpenBSD box is configured to do AES and SHA256.
 
 
 Hi,
 
 Even with this setup it doesn't establish the tunnel properly.
 
 BSD:
 
 
 ike esp from 10.50.0.0/24 to 192.168.9.0/24 peer LINUX_PUBLIC \
  main auth hmac-sha1 enc aes group modp1024 \
  quick auth hmac-sha1 enc aes group modp1024 \
  psk passphrase
 
 Linux:
 
 conn lnx-bsd
  left=LINUX_PUBLIC
  leftsubnet=192.168.9.0/24
  right=BSD_PUBLIC
  rightsubnet=10.50.0.0/24
  authby=secret
  ike=aes-sha1-modp1024
  auto=start
  esp=aes-sha1
  keyexchange=ike
 
 Here are the logs:
 
 Linux side:
 
 lnx-bsd #2: I did not send a certificate because I do not have one.
 lnx-bsd #2: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
 lnx-bsd #2: STATE_MAIN_I3: sent MI3, expecting MR3
 lnx-bsd #7: responding to Main Mode
 lnx-bsd #7: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
 lnx-bsd #7: STATE_MAIN_R1: sent MR1, expecting MI2
 lnx-bsd #7: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
 lnx-bsd #7: STATE_MAIN_R2: sent MR2, expecting MI3
 lnx-bsd #7: ignoring informational payload, type IPSEC_INITIAL_CONTACT
 lnx-bsd #7: Main mode peer ID is ID_IPV4_ADDR: 'BSD_PUBLIC'
 lnx-bsd #7: I did not send a certificate because I do not have one.
 lnx-bsd #7: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
 lnx-bsd #7: STATE_MAIN_R3: sent MR3, ISAKMP SA established
 {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1024}
 lnx-bsd #8: responding to Quick Mode {msgid:de9df09c}
 lnx-bsd #8: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
 lnx-bsd #8: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed,
 expecting QI2
 lnx-bsd #8: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
 lnx-bsd #8: STATE_QUICK_R2: IPsec SA established {ESP=0xa2b93f3b
 0x38351b1b xfrm=AES_128-HMAC_SHA1 NATD=none DPD=none}
 
 
 BSD side:
 Aug 27 10:17:52 fw-001 isakmpd[11393]: message_parse_payloads: invalid
 next payload type Unknown 96 in payload of type 5
 Aug 27 10:17:52 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
 port 500 due to notification type INVALID_PAYLOAD_TYPE
 Aug 27 10:18:03 fw-001 isakmpd[11393]: message_parse_payloads: invalid
 next payload type Unknown 96 in payload of type 5
 Aug 27 10:18:03 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
 port 500 due to notification type INVALID_PAYLOAD_TYPE
 Aug 27 10:18:22 fw-001 isakmpd[11393]: message_parse_payloads: invalid
 next payload type Unknown 96 in payload of type 5
 Aug 27 10:18:22 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
 port 500 due to notification type INVALID_PAYLOAD_TYPE
 Aug 27 10:20:14 fw-001 isakmpd[11393]: message_parse_payloads: reserved
 field non-zero: d
 Aug 27 10:20:14 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
 port 500 due to notification type PAYLOAD_MALFORMED
 Aug 27 10:20:24 fw-001 isakmpd[11393]: message_parse_payloads: reserved
 field non-zero: d
 Aug 27 10:20:24 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
 port 500 due to notification type PAYLOAD_MALFORMED
 Aug 27 10:20:44 fw-001 isakmpd[11393]: message_parse_payloads: reserved
 field non-zero: d
 Aug 27 10:20:44 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
 port 500 due to notification type PAYLOAD_MALFORMED
 Aug 27 10:22:34 fw-001 isakmpd[11393]: message_parse_payloads: reserved
 field non-zero: 6d
 Aug 27 10:22:34 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
 port 500 due to notification type PAYLOAD_MALFORMED
 Aug 27 10:22:45 fw-001 isakmpd[11393]: message_parse_payloads: reserved
 field non-zero: 6d
 Aug 27 10:22:45 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
 port 500 due to notification type PAYLOAD_MALFORMED
 Aug 27 10:23:04 fw-001 isakmpd[11393]: message_parse_payloads: reserved
 field non-zero: 6d
 Aug 27 10:23:04 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
 port 500 due to notification type PAYLOAD_MALFORMED
 Aug 27 10:24:56 fw-001 

Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)

[Laurent CARON]

Dirk Mast wrote:
This config works for me: 


Hi,



OpenBSD 4.3 as GW and Debian Linux with OpenSWAN as client, and
the package ike is installed under Linux, too.


The openswan package is not sufficient to get a working IPsec between 
Linux and OpenBSD ?




OpenBSD:
ike esp from any to 172.16.1.98 quick auth hmac-sha1 enc aes
group modp1024 psk IMTEHLINUXCLIENT


on my setup i would need to add peer W.X.Y.Z (the linux ip)
no ?




Linux:
/etc/ipsec.conf
version 2.0
cono,
g setup
interfaces=wlan0
plutodebug=ballb
nat traversal=yes


you mean
nat_traversal=yes ?


plutowait=yes
nhelpers=0
uniqueids=yes




conn openbsd
type=transport
left=172.16.1.98
right=172.16.1.1
rightsubnet=0.0.0.0/0

i would add leftsubnet too
no ?


keyexchange=ike
esp=aes128-sha1
ike=aes128-sha1-modp1024
auto=route
auth=esp
authby=secret
pfs=yes
keyingtries=rekeymargin=4m


you mean
keytries=%forever
?


disablearrivalcheck=no
rekey=yes
aggrmode=no

/etc/ipsec.secrets
172.16.1.1 172.16.1.98: PSK IMTEHLINUXCLIENT




Thanks

Laurent

Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)

[Dirk Mast]

Laurent CARON wrote:

 Dirk Mast wrote:
 This config works for me:
 
 Hi,
 
 
 OpenBSD 4.3 as GW and Debian Linux with OpenSWAN as client, and
 the package ike is installed under Linux, too.
 
 The openswan package is not sufficient to get a working IPsec between
 Linux and OpenBSD ?
 
 
 OpenBSD:
 ike esp from any to 172.16.1.98 quick auth hmac-sha1 enc aes
 group modp1024 psk IMTEHLINUXCLIENT
 
 on my setup i would need to add peer W.X.Y.Z (the linux ip)
 no ?
 
 
 
 Linux:
 /etc/ipsec.conf
 version 2.0
 cono,
g setup
 interfaces=wlan0
 plutodebug=ballb
 nat traversal=yes
 
 you mean
 nat_traversal=yes ?
 
 plutowait=yes
 nhelpers=0
 uniqueids=yes
 
 
 conn openbsd
 type=transport
 left=172.16.1.98
 right=172.16.1.1
 rightsubnet=0.0.0.0/0
 i would add leftsubnet too
 no ?
 
 keyexchange=ike
 esp=aes128-sha1
 ike=aes128-sha1-modp1024
 auto=route
 auth=esp
 authby=secret
 pfs=yes
 keyingtries=rekeymargin=4m
 
 you mean
 keytries=%forever
 ?
 
 disablearrivalcheck=no
 rekey=yes
 aggrmode=no
 
 /etc/ipsec.secrets
 172.16.1.1 172.16.1.98: PSK IMTEHLINUXCLIENT
 
 
 
 Thanks
 
 Laurent

Hi,

just the OpenSWAN package doesn't bring up the tunnel, that's right.
I guess, it doesn't make the SA setup, Pluto somehow requires the
package 'ike', but I'm not too much into IPSEC,
it simply works for this Linux laptop.

The config is a bit messed up, due to copy pasting from a PDF I've created,
here's the right (and complete!) one:

172.16.1.1 is the IP of the OpenBSD gateway and .98 is the IP of the Linux
client. So yes, the OpenBSD gateway needs your linux client IP
in /etc/ipsec.conf 
 ike esp from any to 172.16.1.98 quick auth hmac-sha1 enc aes
 group modp1024 psk IMTEHLINUXCLIENT


Linux /etc/ipsec.conf:

version 2.0
config setup
interfaces=wlan0
plutodebug=all
nat_traversal=yes
plutowait=yes
nhelpers=0
uniqueids=yes
conn openbsd
type=transport
left=172.16.1.98
right=172.16.1.1
rightsubnet=0.0.0.0/0
keyexchange=ike
esp=aes128-sha1
ike=aes128-sha1-modp1024
auto=route
auth=esp
authby=secret
pfs=yes
keyingtries=%forever
rekeymargin=4m
disablearrivalcheck=no
rekey=yes
aggrmode=no

Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)

[Laurent CARON]

Dirk Mast wrote:

Linux /etc/ipsec.conf:

version 2.0
config setup

... (snip)

Hi,

I finally managed to get it up and working (without IKE).

OpenBSD:
/etc/ipsec.conf:
ike esp from 10.50.0.0/24 to 192.168.9.0/24 peer PUBLIC_LINUX quick \
auth hmac-sha1 enc aes group modp1024 psk secret

Linux:
/etc/ipsec.conf
conn openbsd
left=PUBLIC_LINUX
leftsubnet=192.168.9.0/24
right=PUBLIC_BSD
rightsubnet=10.50.0.0/24
keyexchange=ike
auto=start
auth=esp
authby=secret
pfs=yes
keyingtries=%forever
rekeymargin=4m
disablearrivalcheck=no
rekey=yes
aggrmode=no
esp=aes128-sha1
ike=aes128-sha1-modp1024

There is of course an appropriate entry in /etc/ipsec.secrets

Thanks for everybody's help.

Laurent

IPSEC VPN between OpenBSD and Linux (OpenSwan)

[Laurent CARON]

Hi,

I'm basically trying to setup a VPN between a linux box (debian) and an 
OpenBSD one.


I'd like to use a PSK for that VPN.

Here are the config files:

Linux box:
conn jak-ha
left=PUBLICIP_OF_LINUX_BOX
leftsubnet=192.168.9.0/24
right=PUBLIC_IP_OF_BSD_BOX
rightsubnet=10.50.0.0/24
auto=start
authby=secret

abstract of ipsec.secrets:
PUBLIC_IP_OF_LNUX_BOX PUBLIC_IP_OF_BSD_BOX : PSK 
azD1HPpljzd5ZNzybmjcCiJfonlXwJk8


Bsd box:
ike esp from 10.50.0.0/24 to 192.168.9.0/24 peer PUBLIC_IP_OF_LINUX_BOX 
main auth hmac-md5 enc 3des group modp1536 quick auth hmac-md5 enc 3des 
group modp1536 psk azD1HPpljzd5ZNzybmjcCiJfonlXwJk8
ike esp from PUBLIC_IP_OF_BSD_BOX to 192.168.9.0/24 peer 
PUBLIC_IP_OF_LINUX_BOX main auth hmac-md5 enc 3des group modp1536 quick 
auth hmac-md5 enc 3des group modp1536 psk azD1HPpljzd5ZNzybmjcCiJfonlXwJk8

ike esp from PUBLIC_IP_OF_BSD_BOX to PUBLIC_IP_OF_LINUX_BOX


I got those messages on the /var/log/messages file on the BSD box:
Aug 25 13:21:55 fw-001 isakmpd[15732]: attribute_unacceptable: 
ENCRYPTION_ALGORITHM: got 3DES_CBC, expected AES_CBC
Aug 25 13:21:55 fw-001 isakmpd[15732]: attribute_unacceptable: 
ENCRYPTION_ALGORITHM: got 3DES_CBC, expected AES_CBC
Aug 25 13:21:55 fw-001 isakmpd[15732]: attribute_unacceptable: 
GROUP_DESCRIPTION: got MODP_1536, expected MODP_1024
Aug 25 13:24:03 fw-001 isakmpd[15732]: attribute_unacceptable: 
ENCRYPTION_ALGORITHM: got 3DES_CBC, expected AES_CBC
Aug 25 13:24:03 fw-001 isakmpd[15732]: attribute_unacceptable: 
ENCRYPTION_ALGORITHM: got 3DES_CBC, expected AES_CBC
Aug 25 13:24:03 fw-001 isakmpd[15732]: attribute_unacceptable: 
GROUP_DESCRIPTION: got MODP_1536, expected MODP_1024
Aug 25 13:24:19 fw-001 isakmpd[15732]: transport_send_messages: giving 
up on exchange IPsec-212.99.8.244-192.168.9.0/24, no response from peer 
219.83.41.82:500
Aug 25 13:24:19 fw-001 isakmpd[15732]: transport_send_messages: giving 
up on exchange IPsec-PUBLIC_IP_OF_BSD_BOX-PUBLIC_IP_OF_LINUX_BOX, no 
response from peer PUBLIC_IP_OF_LINUX_BOX:500
Aug 25 13:26:51 fw-001 isakmpd[15732]: message_parse_payloads: invalid 
next payload type Unknown 111 in payload of type 8
Aug 25 13:26:51 fw-001 isakmpd[15732]: dropped message from 
PUBLIC_IP_OF_LINUX_BOX port 500 due to notification type 
INVALID_PAYLOAD_TYPE
Aug 25 13:26:51 fw-001 isakmpd[15732]: message_parse_payloads: invalid 
next payload type Unknown 56 in payload of type 8



Seems i misconfigured something.

Did anyone see what ?

Thanks

Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)

[Imre Oolberg]

Hi!



I'm basically trying to setup a VPN between a linux box (debian) and an 
OpenBSD one.


I am not a seasoned IPSec user but i tried out couple of configurations 
and one of them was Debian with Racoon and OpenBSD's native isakmpd.


I based my experimentation on article which is about FreeBSD's Racoon 
and OpenBSD


http://it.toolbox.com/blogs/unix-sysadmin/ipsec-done-bsd-way-part-1-17355

I dont believe you read fluently Estonian but if you do, please :)

http://kuutorvaja.eenet.ee/wiki/IPSec_kasutamine_Debianiga

Maybe examples are of some use, still.


Imre

PS I am sorry if you insist using OpenSwan and i started talking about 
Racoon, havent tried OpenSwan out myself yet. And also havent built 
anything big with ipsec.

Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)

[John Jackson]

It may also be worth noting that Debian has OpenBSD's isakmpd packaged,
'apt-get install isakmpd'.  I've had success using isakmpd on Debian to
create VPN's between OpenBSD and Debian gateways.

John

On Mon, Aug 25, 2008 at 03:52:42PM +0300, Imre Oolberg wrote:
 Hi!
 
 
 I'm basically trying to setup a VPN between a linux box (debian) and an 
 OpenBSD one.
 
 I am not a seasoned IPSec user but i tried out couple of configurations 
 and one of them was Debian with Racoon and OpenBSD's native isakmpd.
 
 I based my experimentation on article which is about FreeBSD's Racoon 
 and OpenBSD
 
 http://it.toolbox.com/blogs/unix-sysadmin/ipsec-done-bsd-way-part-1-17355
 
 I dont believe you read fluently Estonian but if you do, please :)
 
 http://kuutorvaja.eenet.ee/wiki/IPSec_kasutamine_Debianiga
 
 Maybe examples are of some use, still.
 
 
 Imre
 
 PS I am sorry if you insist using OpenSwan and i started talking about 
 Racoon, havent tried OpenSwan out myself yet. And also havent built 
 anything big with ipsec.

Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)

[Laurent CARON]

John Jackson wrote:

It may also be worth noting that Debian has OpenBSD's isakmpd packaged,
'apt-get install isakmpd'.  I've had success using isakmpd on Debian to
create VPN's between OpenBSD and Debian gateways.

Since i'm using OpenSwan on 99% of my servers, i'd like to be able to 
integrate OpenBSD's isakmpd without modifying too much my setup.

Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)

[Laurent CARON]

John Jackson wrote:

It may also be worth noting that Debian has OpenBSD's isakmpd packaged,
'apt-get install isakmpd'.  I've had success using isakmpd on Debian to
create VPN's between OpenBSD and Debian gateways.



Here is where I'm now:

Openswan's side:

conn lncjakarta-lncha
leftsubnet=192.168.9.0/24
left=LINUX_IP
right=BSD_IP
rightsubnet=10.50.0.0/24
authby=secret
auto=start
pfs=yes
ike=aes128-sha1-modp1024
esp=3des-sha1-96

BSD side:

ike esp tunnel from 10.50.0.0/24 to 192.168.9.0/24 peer LINUX_IP main 
auth hmac-sha1 enc aes group modp1024 quick auth hmac-sha2-256 enc aes 
group modp1024  psk MYPSK


Now the log shows:

Linux Side

STATE_MAIN.
 STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=0xdb08bdcf 
0x57b31855 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}


The vpn seems to be apparently up

but  getting such messages:

Quick Mode message is for a non-existent (expired?) ISAKMP SA

BSD side:
Default transport_send_messages: giving up on exchange 
IPsec-10.50.0.0/24-192.168.9.0/24, no response from peer LINUX_IP:500


Any hint ?

Thanks

Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)

[Sean Malloy]

On Mon, Aug 25, 2008 at 09:50:08PM +0200, Laurent CARON wrote:
 John Jackson wrote:
 It may also be worth noting that Debian has OpenBSD's isakmpd packaged,
 'apt-get install isakmpd'.  I've had success using isakmpd on Debian to
 create VPN's between OpenBSD and Debian gateways.
 
 
 Here is where I'm now:
 
 Openswan's side:
 
 conn lncjakarta-lncha
 leftsubnet=192.168.9.0/24
 left=LINUX_IP
 right=BSD_IP
 rightsubnet=10.50.0.0/24
 authby=secret
 auto=start
 pfs=yes
 ike=aes128-sha1-modp1024
 esp=3des-sha1-96

 
 BSD side:
 
 ike esp tunnel from 10.50.0.0/24 to 192.168.9.0/24 peer LINUX_IP main 
 auth hmac-sha1 enc aes group modp1024 quick auth hmac-sha2-256 enc aes 
 group modp1024  psk MYPSK
 
 Now the log shows:
 
 Linux Side
 
 STATE_MAIN.
  STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=0xdb08bdcf 
 0x57b31855 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
 
 The vpn seems to be apparently up
 
 but  getting such messages:
 
 Quick Mode message is for a non-existent (expired?) ISAKMP SA
 
 BSD side:
 Default transport_send_messages: giving up on exchange 
 IPsec-10.50.0.0/24-192.168.9.0/24, no response from peer LINUX_IP:500
 
 Any hint ?
 
 Thanks


It looks like you are trying to use different encryption algorithms and
hash functions for the phase 2 SA. They need to match at both end points.
It looks like the Linux box is configured to do 3DES and SHA1. The
OpenBSD box is configured to do AES and SHA256.

-- 
Sean Malloy
www.spmalloy.com
GPG KeyID: 0x13EEB747
GPG Fingerprint: D059 5076 ABB3 1E08 9965 1958 F820 CE83 13EE B747

Re: ipsec vpn problem

[jared r r spiegel]

On Fri, Aug 22, 2008 at 03:11:16PM +0200, Claus Larsen wrote:
 Well I did get a bit futher with the problem, it seems it was cause by a
 firewall blocking some of the traffic.
 
 So new problem now.
 Using the Greenbow vpn client.
 
 It says Phase 2 algoritm problem.
 
 From the isakmpd output I get (a larger portion of the output included
 below):
 164658.900458 Default responder_recv_HASH_SA_NONCE: peer proposed invalid
 phase 2 IDs: initiator id d5ade2e5: 213.173.226.229, responder id c0a80102:
 192.168.1.2
 164658.901274 Default dropped message from 213.173.226.229 port 500 due to
 notification type NO_PROPOSAL_CHOSEN
 
 Any idea whats going on?

  when this happens to me, it is a config mismatch between the two peers.

  sometimes the mismatch can be excruciatingly subtle.

  but one wrong little anything will make the flow or sa or whatever it
  is that the wrong peer installs end up completely not matching
  what the other has.

  at times i've resorted to doing line-by-line echo $LINE | md5 to
  help speed the process of finding the mismatch along.

  given that in this case, there's 1918 IP on one side and !1918 on the
  other, the 1918 peer is perhaps using its 1918 IP by default but the
  other peer expects him to be sending his public IP.

  you can also see this type of mismatch with loglines that say
  something like Expected: 3DES, Received: $whatever_you're_trying_to_use
  for the algorithm in question; has always been the same thing 
  for me in that case, (potentially subtle) config mismatch.
  
  /etc/ipsec.conf
  ike passive from any to any \
   main auth hmac-sha1 enc 3des group modp1024 \
   quick auth hmac-sha1 enc 3des group none \
   psk openbsdrules

  hrm; i guess i'd assume 'any' would make it not care, so maybe my
  whole suggestion is shot.  maybe for starters, copy that off to a
  new ike setup and specifically define the stuff that it seems
  the remote peer is sending that your end is complaining about, and
  then work back from there after you get that working.

-- 

  jared

ipsec vpn problem

[Claus Larsen]

Have a problem getting a vpn tunnel up between a zyxel vpn gw and my openbsd
4.3 system.

/etc/ipsec.conf
ike passive from any to any \
 main auth hmac-sha1 enc 3des group modp1024 \
 quick auth hmac-sha1 enc 3des group none \
 psk openbsdrules

Below follows output from cmd:
isakmpd -d  -DA=99 -K

In the output is the line:
173307.589683 Exch 90 check_vendor_openbsd: bad size 20 != 16
which does not seem to cause any problems

A then futher down the line:
173307.682833 Default sendmsg (14, 0xcfbd65a0, 0): Permission denied
which does not have any lines before it which (to me) explains what goes
wrong.

These two lines is what I found strange, but I have no idea where to go from
here.

Thanks,
Claus

173307.533538 Trpt 70 transport_setup: added 0x7ce24ac0 to transport list
173307.534309 Trpt 70 transport_setup: added 0x7ce24b00 to transport list
173307.535214 Trpt 50 virtual_clone: old 0x7ce24680 new 0x7ce249c0 (main is
0x7ce24ac0)
173307.536014 Trpt 70 transport_setup: virtual transport 0x7ce249c0
173307.536809 Trpt 95 transport_reference: transport 0x7ce249c0 now has 1
references
173307.537700 Mesg 90 message_alloc: allocated 0x83151280
173307.538473 Mesg 70 message_recv: message 0x83151280
173307.539310 Mesg 70 ICOOKIE: 4558dc89993e4538
173307.540292 Mesg 70 RCOOKIE: 
173307.540993 Mesg 70 NEXT_PAYLOAD: SA
173307.541788 Mesg 70 VERSION: 16
173307.542575 Mesg 70 EXCH_TYPE: ID_PROT
173307.543469 Mesg 70 FLAGS: [ ]
173307.544277 Mesg 70 MESSAGE_ID: 
173307.544951 Mesg 70 LENGTH: 128
173307.546067 Mesg 70 message_recv: 4558dc89 993e4538  
01100200  0080 0d38
173307.547105 Mesg 70 message_recv: 0001 0001 002c 01010001
0024 0101 80010005 80020002
173307.548131 Mesg 70 message_recv: 80030001 80040002 800b0001 000c0004
00015180 0d14 afcad713 68a1f1c9
173307.549317 Mesg 70 message_recv: 6b8696fc 77570100 0018 62502774
9d5ab97f 5616c160 2765cf48 0a3b7d0b
173307.550011 SA   90 sa_find: no SA matched query
173307.550936 Mesg 50 message_parse_payloads: offset 28 payload SA
173307.551623 Mesg 50 message_parse_payloads: offset 84 payload VENDOR
173307.552429 Mesg 50 message_parse_payloads: offset 104 payload VENDOR
173307.553226 Mesg 60 message_validate_payloads: payload SA at 0x8315131c of
message 0x83151280
173307.554202 Mesg 70 DOI: 1
173307.554834 Mesg 70 SIT:
173307.555797 Misc 95 conf_get_str: configuration value not found [Phase 1]:
195.184.124.220
173307.556514 Misc 95 conf_get_str: [Phase 1]:Default-peer-default
173307.557474 Misc 95 conf_get_str: [peer-default]:Configuration-mm-default
173307.558177 Misc 95 conf_get_str: configuration value not found
[mm-default]:DOI
173307.558977 Misc 95 conf_get_str: [mm-default]:EXCHANGE_TYPE-ID_PROT
173307.559852 Misc 95 conf_get_str: [General]:Exchange-max-time-120
173307.560688 Timr 10 timer_add_event: event exchange_free_aux(0x7de79800)
added last, expiration in 120s
173307.561565 Misc 95 conf_get_str: configuration value not found
[peer-default]:Flags
173307.562379 Cryp 60 hash_get: requested algorithm 1
173307.563305 Exch 10 exchange_setup_p1: 0x7de79800 peer-default mm-default
policy responder phase 1 doi 1 exchange 2 step 0
173307.564149 Exch 10 exchange_setup_p1: icookie 4558dc89993e4538 rcookie
a42fec0b4dc4e6f0
173307.564962 Exch 10 exchange_setup_p1: msgid 
173307.565751 Trpt 95 transport_reference: transport 0x7ce249c0 now has 2
references
173307.566558 SA   80 sa_reference: SA 0x7de79900 now has 1 references
173307.567493 SA   70 sa_enter: SA 0x7de79900 added to SA list
173307.568157 SA   80 sa_reference: SA 0x7de79900 now has 2 references
173307.568944 SA   60 sa_create: sa 0x7de79900 phase 1 added to exchange
0x7de79800 (peer-default)
173307.569762 SA   80 sa_reference: SA 0x7de79900 now has 3 references
173307.570682 Mesg 50 message_parse_payloads: offset 40 payload PROPOSAL
173307.571360 Mesg 50 message_parse_payloads: offset 48 payload TRANSFORM
173307.572180 Mesg 50 Transform 1's attributes
173307.572965 Mesg 50 Attribute ENCRYPTION_ALGORITHM value 5
173307.573733 Mesg 50 Attribute HASH_ALGORITHM value 2
173307.574508 Mesg 50 Attribute AUTHENTICATION_METHOD value 1
173307.575286 Mesg 50 Attribute GROUP_DESCRIPTION value 2
173307.576066 Mesg 50 Attribute LIFE_TYPE value 1
173307.576967 Mesg 50 Attribute LIFE_DURATION value 86400
173307.577715 Mesg 60 message_validate_payloads: payload PROPOSAL at
0x83151328 of message 0x83151280
173307.578680 Mesg 70 NO: 1
173307.579317 Mesg 70 PROTO: ISAKMP
173307.580124 Mesg 70 SPI_SZ: 0
173307.580923 Mesg 70 NTRANSFORMS: 1
173307.581695 Mesg 70 SPI:
173307.582492 Mesg 60 message_validate_payloads: payload TRANSFORM at
0x83151330 of message 0x83151280
173307.583461 Mesg 70 NO: 1
173307.584108 Mesg 70 ID: 1
173307.584860 Mesg 70 SA_ATTRS:
173307.585645 Mesg 60 message_validate_payloads: payload VENDOR at
0x83151354 of message 0x83151280
173307.586462 Mesg 70 ID:
173307.587267 Exch 10 dpd_check_vendor_payload: DPD capable peer 

Re: Site-to-site IPSec VPN between OpenBSD and Cisco PIX 515E

[Shohrukh Shoyoqubov]

Finally I have managed that VPN tunnel to work. Actually, everything was 
fine with VPN connection settings, the problem was with the firewall 
(Cisco ASA) residing behind the PIX that I've never known about :)
[ A.B.C.B ] - [ OpenBSD 4.1 (M.N.O.P) ] -- Internet -- [ ( I.J.K.L) 
Cisco PIX 515E ] -- [ CISCO ASA ] -- [ E.F.G.H ]


Now, I have another problem, VPN tunnel dies and I get INVALID_COOKIE 
messages in /var/log/messages. This usually means that one of the 
endpoints is using SA that is not available anymore. I guess it is 
caused by lifetime values mismatch. On OpenBSD side I see SAs, but on 
Cisco side there are no SAs related with OpenBSD peer. Where can I set 
SA lifetimes on OpenBSD? What are the default values for them?


/var/log/messages
Nov 29 13:55:43 app isakmpd[24775]: message_recv: invalid cookie(s) 
f7ed5cd26d071117 bbfcbff3ba3d4fee
Nov 29 13:55:43 app isakmpd[24775]: dropped message from I.J.K.L port 
500 due to notification type INVALID_COOKIE
Nov 29 13:55:45 app isakmpd[24775]: message_recv: invalid cookie(s) 
f7ed5cd26d071117 bbfcbff3ba3d4fee
Nov 29 13:55:45 app isakmpd[24775]: dropped message from I.J.K.L port 
500 due to notification type INVALID_COOKIE
Nov 29 13:55:47 app isakmpd[24775]: message_recv: invalid cookie(s) 
f7ed5cd26d071117 bbfcbff3ba3d4fee
Nov 29 13:55:47 app isakmpd[24775]: dropped message from I.J.K.L port 
500 due to notification type INVALID_COOKIE
Nov 29 13:55:49 app isakmpd[24775]: message_recv: invalid cookie(s) 
f7ed5cd26d071117 bbfcbff3ba3d4fee
Nov 29 13:55:49 app isakmpd[24775]: dropped message from I.J.K.L port 
500 due to notification type INVALID_COOKIE
Nov 29 13:55:49 app isakmpd[24775]: message_recv: invalid cookie(s) 
f7ed5cd26d071117 bbfcbff3ba3d4fee
Nov 29 13:55:49 app isakmpd[24775]: dropped message from I.J.K.L port 
500 due to notification type INVALID_COOKIE


Shohrukh

Shohrukh Shoyoqubov wrote:

# netstat -rn -f encap
Routing tables

Encap:
Source PortDestinationPort  Proto 
SA(Address/Proto/Type/Direction)
E.F.G.H/32  0A.B.C.B/32   0  0
I.J.K.L/esp/use/in
A.B.C.B/32  0E.F.G.H/32   0  0
I.J.K.L/esp/require/out

#


Brian A. Seklecki wrote:

On Thu, 22 Nov 2007, Shohrukh Shoyoqubov wrote:


Date: Thu, 22 Nov 2007 09:46:54 +0500
From: Shohrukh Shoyoqubov [EMAIL PROTECTED]
To: misc@openbsd.org
Subject: Re: Site-to-site IPSec VPN between OpenBSD and Cisco PIX 515E

From which machine do I have to do ping -I A.B.C.D  E.F.G.H

pf has default config and allows everything

forwarding is enabled


What does netstat -rn -f encap look like?

~bas



Christoph Leser wrote:

you could try

ping -I A.B.C.D  E.F.G.H

ipsec vpn netgear DG834 : openbsd 4.2 (SOLVED !)

[jcr]

So by the way .. the problem was link with pf.conf..

In fact there is something i did not put on my last mail, it is the fact 
i'am using
TWO adsl pppoe link on the same PC. i'm doing load balancing for the web 
access


it's working like a charm 

So there is TWO tun interfaces : tun0 link with rl0 an rl1 link with tun1...

But ONLY ONE enc0 ... and here is the problem, i try to connect my VPN 
through the tun1 interface


But enc0 is linked with tun0 ! (bad luck .. bad choice.. but then i 
learn something new . :-) )


So thanks to the tcpdump output (thanks Christoph Leser ..) i see that 
the inbound traffic came on tun1
but the outside one go through tun0 !!! and that's enough to blow away 
all the process..



So i just change my ipsec  pf settings to listen on tun0 and then the 
VPN came up !
 


so thanks every one out there for your help.

PS : is it possbile to start another enc interface on the other tun 
interface ? like enc1 i mean ?


thanks

jc

ipsec vpn netgear DG834 : openbsd 4.2 (new thread)

[jcr]

New thread .. after some new test..

And stiill the same ... shit !

Here is the LAn/WAn network


192.168.0/24(lan)--Netgear DG 834 (adsl + NAT + ipsec +ip fix A)
|
---WEB---
 |
Openbsd 4.2 
(ipsec.conf+isakmpd.policy+ip fix B+ NAT) -- 10.7.22.0/24(lan)  



Here are the conf :

netgear :

local lan : 192.168.0.0/24
remote lan : 10.7.22.0/24
IKE :
direction : initiator  respond
mode : main
diffie-Hellman : Groupe 2 (1024)
local id : IP wan
remote id: IP

Params
Crypto algo : 3DES
Algo auth : SHA-1
pre shared key : 123456789
SA life time : 36000


Openbsd :
ipsec.conf

ike passive esp tunnel from IP_A to IP_B \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des  psk 123456789

ike dynamic esp tunnel from 192.168.0.0/24 to 10.7.22.0/24 peer IP_A \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des psk 123456789

  i have tried passive  dynamic for ike esp .. it's the same

isakmpd.policy

KeyNote-Version: 2
Authorizer: POLICY

pf.conf

pass in on $ext_if1 proto udp from $IP_A to $IP_B port {500,4500}
pass out on $ext_if1 proto udp from $IP_B to $IP_A port {500,4500}

pass in  on $IP_B proto esp from $IP_A to $IP_B
pass out on $IP_B proto esp from $IP_B to $IP_A

pass in on enc0 proto ipencap from $IP_A to $IP_B keep state (if-bound)
pass out on enc0 proto ipencap from $IP_B to $IP_A keep state (if-bound)

pass in on enc0 from 192.168.0.0/24 to 10.7.22.0/24 keep state (if-bound)
pass out on enc0 from 10.7.22.0/24 to 192.168.0.0/24 keep state (if-bound)

i have a rule for nat on $IP_B


enc0 is up and running

i start my vpn with

isakmpd -dv -D 8=99


And Finally here is the Trouble , i got this on isakmpd console

151330.400513 Negt 30 message_negotiate_sa: transform 0 proto 1 proposal 
0 ok

151330.400933 Negt 20 ike_phase_1_validate_prop: success
151330.401046 Negt 30 message_negotiate_sa: proposal 0 succeeded
151357.435134 Default transport_send_messages: giving up on exchange 
peer-IP_A, no response from peer IP_A:500


And this on the DG834

Fri, 2007-11-23 14:13:30 - [idle] initiating Main Mode
Fri, 2007-11-23 14:13:40 - [idle] STATE_MAIN_I1: retransmission; will 
wait 20s for response
Fri, 2007-11-23 14:14:00 - [idle] STATE_MAIN_I1: retransmission; will 
wait 40s for response
Fri, 2007-11-23 14:14:40 - [idle] max number of retransmissions reached 
STATE_MAIN_I1.  No acceptable response to our first IKE message



and finally ( As wanted for those who try to help me .. thanks)

echo p on  /var/run/isakmpd.fif and tcpdump -r /var/run/isakmpd.pcap 
-vvn



tcpdump: WARNING: snaplen raised from 96 to 65536
11:40:31.600710 IP_A.500  IP_B.500: [udp sum ok] isakmp v1.0 exchange 
ID_PROT

   cookie: cb79617a4b409a8f- msgid:  len: 100
   payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
   payload: PROPOSAL len: 40 proposal: 0 proto: ISAKMP spisz: 0 
xforms: 1

   payload: TRANSFORM len: 32
   transform: 0 ID: ISAKMP
   attribute LIFE_TYPE = SECONDS
   attribute LIFE_DURATION = 3600
   attribute ENCRYPTION_ALGORITHM = 3DES_CBC
   attribute HASH_ALGORITHM = SHA
   attribute AUTHENTICATION_METHOD = PRE_SHARED
   attribute GROUP_DESCRIPTION = MODP_1024
   payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 128)
11:40:31.601712 IP_B.500  IP_A.500: [udp sum ok] isakmp v1.0 exchange 
ID_PROT

   cookie: cb79617a4b409a8f-76316a628a99ce2b msgid:  len: 180
   payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
   payload: PROPOSAL len: 40 proposal: 0 proto: ISAKMP spisz: 0 
xforms: 1

   payload: TRANSFORM len: 32
   transform: 0 ID: ISAKMP
   attribute LIFE_TYPE = SECONDS
   attribute LIFE_DURATION = 3600
   attribute ENCRYPTION_ALGORITHM = 3DES_CBC
   attribute HASH_ALGORITHM = SHA
   attribute AUTHENTICATION_METHOD = PRE_SHARED
   attribute GROUP_DESCRIPTION = MODP_1024
   payload: VENDOR len: 20 (supports OpenBSD-4.0)
   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 NAT-T, RFC 3947)
   payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 208)



And then nothing 

it is not related to my FAI i have tried with 2 different.. it is the same


For me it is around pf.conf .. but i can't find where

jc

Re: ipsec vpn netgear DG834 : openbsd 4.2 (new thread)

[Christoph Leser]

Hi,

here my 50 cent:

tcpdump looks good, obsd maschine receives first message of phase 1 exchange
and sends a suitable response.

your netgear log says, that no response to first message is received.

this means, response from isakmpd gets lost, either in local pf or in netgear
( dont know if they have some sort packet filter ) or somewhere in between .

you could distinguish there two possibilities by either

tcpdump -lenvvi pflog0 # watch out for packets to if_A that are blocked

or

tcpdump -lenvvi external if ip host if_A   ( you should see exactly one
message in and one message out )

Once we know whether the packets really leave openBSD, we can do further
analysis.



 -Urspr|ngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag
 von jcr
 Gesendet: Dienstag, 27. November 2007 12:10
 An: misc@openbsd.org
 Betreff: ipsec vpn netgear DG834 : openbsd 4.2 (new thread)


 New thread .. after some new test..

 And stiill the same ... shit !

 Here is the LAn/WAn network


 192.168.0/24(lan)--Netgear DG 834 (adsl + NAT + ipsec +ip fix A)
  |
  ---WEB---
   |
  Openbsd 4.2
 (ipsec.conf+isakmpd.policy+ip fix B+ NAT) -- 10.7.22.0/24(lan)


 Here are the conf :

 netgear :

 local lan : 192.168.0.0/24
 remote lan : 10.7.22.0/24
 IKE :
 direction : initiator  respond
 mode : main
 diffie-Hellman : Groupe 2 (1024)
 local id : IP wan
 remote id: IP

 Params
 Crypto algo : 3DES
 Algo auth : SHA-1
 pre shared key : 123456789
 SA life time : 36000


 Openbsd :
 ipsec.conf

 ike passive esp tunnel from IP_A to IP_B \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des  psk 123456789

 ike dynamic esp tunnel from 192.168.0.0/24 to 10.7.22.0/24 peer IP_A \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des psk 123456789

i have tried passive  dynamic for ike esp .. it's the same

 isakmpd.policy

 KeyNote-Version: 2
 Authorizer: POLICY

 pf.conf

 pass in on $ext_if1 proto udp from $IP_A to $IP_B port {500,4500}
 pass out on $ext_if1 proto udp from $IP_B to $IP_A port {500,4500}

 pass in  on $IP_B proto esp from $IP_A to $IP_B
 pass out on $IP_B proto esp from $IP_B to $IP_A

 pass in on enc0 proto ipencap from $IP_A to $IP_B keep state
 (if-bound)
 pass out on enc0 proto ipencap from $IP_B to $IP_A keep state
 (if-bound)

 pass in on enc0 from 192.168.0.0/24 to 10.7.22.0/24 keep
 state (if-bound)
 pass out on enc0 from 10.7.22.0/24 to 192.168.0.0/24 keep
 state (if-bound)

 i have a rule for nat on $IP_B


 enc0 is up and running

 i start my vpn with

 isakmpd -dv -D 8=99


 And Finally here is the Trouble , i got this on isakmpd console

 151330.400513 Negt 30 message_negotiate_sa: transform 0 proto
 1 proposal
 0 ok
 151330.400933 Negt 20 ike_phase_1_validate_prop: success
 151330.401046 Negt 30 message_negotiate_sa: proposal 0 succeeded
 151357.435134 Default transport_send_messages: giving up on exchange
 peer-IP_A, no response from peer IP_A:500

 And this on the DG834

 Fri, 2007-11-23 14:13:30 - [idle] initiating Main Mode
 Fri, 2007-11-23 14:13:40 - [idle] STATE_MAIN_I1: retransmission; will
 wait 20s for response
 Fri, 2007-11-23 14:14:00 - [idle] STATE_MAIN_I1: retransmission; will
 wait 40s for response
 Fri, 2007-11-23 14:14:40 - [idle] max number of
 retransmissions reached
 STATE_MAIN_I1.  No acceptable response to our first IKE message


 and finally ( As wanted for those who try to help me .. thanks)

 echo p on  /var/run/isakmpd.fif and tcpdump -r
 /var/run/isakmpd.pcap
 -vvn


 tcpdump: WARNING: snaplen raised from 96 to 65536
 11:40:31.600710 IP_A.500  IP_B.500: [udp sum ok] isakmp v1.0
 exchange
 ID_PROT
 cookie: cb79617a4b409a8f- msgid:
  len: 100
 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
 payload: PROPOSAL len: 40 proposal: 0 proto:
 ISAKMP spisz: 0
 xforms: 1
 payload: TRANSFORM len: 32
 transform: 0 ID: ISAKMP
 attribute LIFE_TYPE = SECONDS
 attribute LIFE_DURATION = 3600
 attribute ENCRYPTION_ALGORITHM = 3DES_CBC
 attribute HASH_ALGORITHM = SHA
 attribute AUTHENTICATION_METHOD = PRE_SHARED
 attribute GROUP_DESCRIPTION = MODP_1024
 payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0]
 (id 1, len 128)
 11:40:31.601712 IP_B.500  IP_A.500: [udp sum ok] isakmp v1.0
 exchange
 ID_PROT
 cookie: cb79617a4b409a8f-76316a628a99ce2b msgid:
  len: 180
 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
 payload: PROPOSAL len: 40 proposal: 0 proto:
 ISAKMP spisz: 0
 xforms: 1
 payload: TRANSFORM len: 32

Re: ipsec vpn netgear DG834 : openbsd 4.2 (new thread)

[Christoph Leser]

I forgot to ask:

what are the NAT statements in your pf.conf, that you mention. the ipsec
packets should not be NAT'ed inyour configuration ( although ipsec can go
through NAT in general ).

 -Urspr|ngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag
 von jcr
 Gesendet: Dienstag, 27. November 2007 12:10
 An: misc@openbsd.org
 Betreff: ipsec vpn netgear DG834 : openbsd 4.2 (new thread)


 New thread .. after some new test..

 And stiill the same ... shit !

 Here is the LAn/WAn network


 192.168.0/24(lan)--Netgear DG 834 (adsl + NAT + ipsec +ip fix A)
  |
  ---WEB---
   |
  Openbsd 4.2
 (ipsec.conf+isakmpd.policy+ip fix B+ NAT) -- 10.7.22.0/24(lan)


 Here are the conf :

 netgear :

 local lan : 192.168.0.0/24
 remote lan : 10.7.22.0/24
 IKE :
 direction : initiator  respond
 mode : main
 diffie-Hellman : Groupe 2 (1024)
 local id : IP wan
 remote id: IP

 Params
 Crypto algo : 3DES
 Algo auth : SHA-1
 pre shared key : 123456789
 SA life time : 36000


 Openbsd :
 ipsec.conf

 ike passive esp tunnel from IP_A to IP_B \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des  psk 123456789

 ike dynamic esp tunnel from 192.168.0.0/24 to 10.7.22.0/24 peer IP_A \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des psk 123456789

i have tried passive  dynamic for ike esp .. it's the same

 isakmpd.policy

 KeyNote-Version: 2
 Authorizer: POLICY

 pf.conf

 pass in on $ext_if1 proto udp from $IP_A to $IP_B port {500,4500}
 pass out on $ext_if1 proto udp from $IP_B to $IP_A port {500,4500}

 pass in  on $IP_B proto esp from $IP_A to $IP_B
 pass out on $IP_B proto esp from $IP_B to $IP_A

 pass in on enc0 proto ipencap from $IP_A to $IP_B keep state
 (if-bound)
 pass out on enc0 proto ipencap from $IP_B to $IP_A keep state
 (if-bound)

 pass in on enc0 from 192.168.0.0/24 to 10.7.22.0/24 keep
 state (if-bound)
 pass out on enc0 from 10.7.22.0/24 to 192.168.0.0/24 keep
 state (if-bound)

 i have a rule for nat on $IP_B


 enc0 is up and running

 i start my vpn with

 isakmpd -dv -D 8=99


 And Finally here is the Trouble , i got this on isakmpd console

 151330.400513 Negt 30 message_negotiate_sa: transform 0 proto
 1 proposal
 0 ok
 151330.400933 Negt 20 ike_phase_1_validate_prop: success
 151330.401046 Negt 30 message_negotiate_sa: proposal 0 succeeded
 151357.435134 Default transport_send_messages: giving up on exchange
 peer-IP_A, no response from peer IP_A:500

 And this on the DG834

 Fri, 2007-11-23 14:13:30 - [idle] initiating Main Mode
 Fri, 2007-11-23 14:13:40 - [idle] STATE_MAIN_I1: retransmission; will
 wait 20s for response
 Fri, 2007-11-23 14:14:00 - [idle] STATE_MAIN_I1: retransmission; will
 wait 40s for response
 Fri, 2007-11-23 14:14:40 - [idle] max number of
 retransmissions reached
 STATE_MAIN_I1.  No acceptable response to our first IKE message


 and finally ( As wanted for those who try to help me .. thanks)

 echo p on  /var/run/isakmpd.fif and tcpdump -r
 /var/run/isakmpd.pcap
 -vvn


 tcpdump: WARNING: snaplen raised from 96 to 65536
 11:40:31.600710 IP_A.500  IP_B.500: [udp sum ok] isakmp v1.0
 exchange
 ID_PROT
 cookie: cb79617a4b409a8f- msgid:
  len: 100
 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
 payload: PROPOSAL len: 40 proposal: 0 proto:
 ISAKMP spisz: 0
 xforms: 1
 payload: TRANSFORM len: 32
 transform: 0 ID: ISAKMP
 attribute LIFE_TYPE = SECONDS
 attribute LIFE_DURATION = 3600
 attribute ENCRYPTION_ALGORITHM = 3DES_CBC
 attribute HASH_ALGORITHM = SHA
 attribute AUTHENTICATION_METHOD = PRE_SHARED
 attribute GROUP_DESCRIPTION = MODP_1024
 payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0]
 (id 1, len 128)
 11:40:31.601712 IP_B.500  IP_A.500: [udp sum ok] isakmp v1.0
 exchange
 ID_PROT
 cookie: cb79617a4b409a8f-76316a628a99ce2b msgid:
  len: 180
 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY
 payload: PROPOSAL len: 40 proposal: 0 proto:
 ISAKMP spisz: 0
 xforms: 1
 payload: TRANSFORM len: 32
 transform: 0 ID: ISAKMP
 attribute LIFE_TYPE = SECONDS
 attribute LIFE_DURATION = 3600
 attribute ENCRYPTION_ALGORITHM = 3DES_CBC
 attribute HASH_ALGORITHM = SHA
 attribute AUTHENTICATION_METHOD = PRE_SHARED
 attribute GROUP_DESCRIPTION = MODP_1024
 payload: VENDOR len: 20 (supports OpenBSD-4.0)
 payload: VENDOR len: 20 (supports

ipsec vpn openbsd 4.2 / netgear DG834

[jcr]

Ok .
here i go

i have red the misc list upside/down and right to left , but i can't 
find a solution to my problhme


Here is the LAn/WAn network


192.168.0/24(lan)--Netgear DG 834 (adsl + NAT + ipsec +ip fix A)
  |
  ---WEB---
   |
  Openbsd 4.2 
(ipsec.conf+isakmpd.policy+ip fix B+ NAT) -- 10.7.22.0/24(lan)
  
   


Very simple : lan to lan VPN between 2 GW (DH834  Obsd)


Here are the conf :

netgear :

local lan : 192.168.0.0/24
remote lan : 10.7.22.0/24
IKE :
direction : initiator  respond
mode : main
diffie-Hellman : Groupe 2 (1024)
local id : IP wan
remote id: IP

Params
Crypto algo : 3DES
Algo auth : SHA-1
pre shared key : 123456789
SA life time : 36000
active PFS


Openbsd :
ipsec.conf

ike dynamic esp tunnel from IP_B to IP_A \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group modp1024 \
  psk 123456789
ike dynamic esp tunnel from 10.7.22.0/24 to 192.168.0.0/24 peer IP_A \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group modp1024 \
  psk 123456789

i have tried passive  dynamic for ike esp .. it's the same

isakmpd.policy

KeyNote-Version: 2
Authorizer: POLICY

pf.conf

pass in quick on $ext_if1 proto udp from $IP_A to $IP_B port {500,4500}
pass out quick on $ext_if1 proto udp from $IP_B to $IP_A port {500,4500}

pass in quick on $IP_B proto esp from $IP_A to $IP_B
pass out quick on $IP_B proto esp from $IP_B to $IP_A

pass in quick on enc0 proto ipencap from $IP_A to $IP_B keep state 
(if-bound)
pass out quick on enc0 proto ipencap from $IP_B to $IP_A keep state 
(if-bound)


pass in quick on enc0 from 192.168.0.0/24 to 10.7.22.0/24 keep state 
(if-bound)
pass out quick on enc0 from 10.7.22.0/24 to 192.168.0.0/24 keep state 
(if-bound)



i have a rule for nat on $IP_B


enc0 is up and running

i start my vpn with

isakmpd -dv -D 8=99


And Finally here is the Trouble , i got this on isakmpd console

151330.400513 Negt 30 message_negotiate_sa: transform 0 proto 1 proposal 
0 ok

151330.400933 Negt 20 ike_phase_1_validate_prop: success
151330.401046 Negt 30 message_negotiate_sa: proposal 0 succeeded
151357.435134 Default transport_send_messages: giving up on exchange 
peer-IP_A, no response from peer IP_A:500


And this on the DG834

Fri, 2007-11-23 14:13:30 - [idle] initiating Main Mode
Fri, 2007-11-23 14:13:40 - [idle] STATE_MAIN_I1: retransmission; will 
wait 20s for response
Fri, 2007-11-23 14:14:00 - [idle] STATE_MAIN_I1: retransmission; will 
wait 40s for response
Fri, 2007-11-23 14:14:40 - [idle] max number of retransmissions reached 
STATE_MAIN_I1.  No acceptable response to our first IKE message



and then i have this sequence always and always


I can't find where is the trouble 

i have tried with tcpdump... with : echo p on  /var/run/isakmpd.fif 
and tcpdump -r /var/run/isakmpd.pcap -vvn


But i find nothing revelant...


HELP would be welcome !

I can give the TCPdump ouput ... but this mail is long enough for the 
moment 


JC