Re: ipsec vpn?
If I am interpreting the logs correctly then I have partial success using ike dynamic esp tunnel from any to 192.168.1.0/24 \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha2-256 enc 3des \ psk abc123 I am confident that the first two lines are correct. The dynamic variable should be correct if the incoming IP address is different for every user. Line two should be OK since it appears I have a successful Phase 1. I've SSH'd into the endpoint and run tcpdump against my external interface and enc0. I have also used "ipssectl -m". So far I have not picked up any new clues to help resolve the remainder of the problem. Man ipsec.conf says the default authentication for phase 2 is hmac-sha2-256 so I am reasonably confident that is correct. I suspect it is the remainder of my config where I am having trouble. Log out put from Greenbow: 20070813 181803 Default (SA Home_Network-P1) SEND phase 1 Main Mode [SA] [VID] [VID] [VID] [VID] 20070813 181803 Default (SA Home_Network-P1) RECV phase 1 Main Mode [SA] [VID] [VID] [VID] [VID] [VID] 20070813 181803 Default (SA Home_Network-P1) SEND phase 1 Main Mode [KEY_EXCH] [NONCE] [NAT_D] [NAT_D] 20070813 181803 Default (SA Home_Network-P1) RECV phase 1 Main Mode [KEY_EXCH] [NONCE] [NAT_D] [NAT_D] 20070813 181804 Default (SA Home_Network-P1) SEND phase 1 Main Mode [HASH] [ID] [NOTIFY] 20070813 181804 Default (SA Home_Network-P1) RECV phase 1 Main Mode [HASH] [ID] 20070813 181804 Default phase 1 done: initiator id 192.168.11.151, responder id gateway.home.lan 20070813 181804 Default (SA Home_Network-Home_Network-P2) SEND phase 2 Quick Mode [HASH] [SA] [NONCE] [ID] [ID] 20070813 181804 Default (SA Home_Network-P1) RECV Informational [HASH] [NOTIFY] with NO_PROPOSAL_CHOSEN error 20070813 181804 Default (SA ) RECV phase 2 Quick Mode [HASH] [SA] [KEY_EXCH] [NONCE] [ID] [ID] 20070813 181804 Default message_negotiate_incoming_sa: no compatible proposal found Log out put from "ipsecctl -m" # ipsecctl -m (full IP partial obscured for security. A/B for source and X/Y for dest) sadb_getspi: satype esp vers 2 len 10 seq 5 pid 29253 address_src: 64.119.aa.bbb address_dst: 64.119.xx.yy spirange: min 0x0100 max 0x sadb_getspi: satype esp vers 2 len 10 seq 5 pid 29253 sa: spi 0xc1fe759d auth none enc none state mature replay 0 flags 0 address_src: 64.119.aa.bbb address_dst: 64.119.xx.yy The line "sa: spi 0xc1fe759d auth none enc none" is not very encouraging. Output of tcpdump on the external interface: Aug 13 18:04:38.881175 64.119.aa.bbb.500 > 64.119.xx.yy.500: isakmp v1.0exchange ID_PROT cookie: 46e4aa106358ddb5-> msgid: len: 160 Aug 13 18:04:38.901502 64.119.xx.yy.500 > 64.119.aa.bbb.500: isakmp v1.0exchange ID_PROT cookie: 46e4aa106358ddb5->26193c745679a129 msgid: len: 180 Aug 13 18:04:39.027590 64.119.aa.bbb.500 > 64.119.xx.yy.500: isakmp v1.0exchange ID_PROT cookie: 46e4aa106358ddb5->26193c745679a129 msgid: len: 228 Aug 13 18:04:39.082435 64.119.xx.yy.500 > 64.119.aa.bbb.500: isakmp v1.0exchange ID_PROT cookie: 46e4aa106358ddb5->26193c745679a129 msgid: len: 228 Aug 13 18:04:39.216764 64.119.aa.bbb.4500 > 64.119.xx.yy.4500:udpencap:isakmp v1.0 exchange ID_PROT encrypted cookie: 46e4aa106358ddb5->26193c745679a129 msgid: len: 92 Aug 13 18:04:39.219939 64.119.xx.yy.4500 > 64.119.aa.bbb.4500:udpencap:isakmp v1.0 exchange ID_PROT encrypted cookie: 46e4aa106358ddb5->26193c745679a129 msgid: len: 108 Aug 13 18:04:39.281029 64.119.aa.bbb.4500 > 64.119.xx.yy.4500:udpencap:isakmp v1.0 exchange QUICK_MODE encrypted cookie: 46e4aa106358ddb5->26193c745679a129 msgid: 0ad31636 len: 148 Aug 13 18:04:39.283292 64.119.xx.yy.4500 > 64.119.aa.bbb.4500:udpencap:isakmp v1.0 exchange INFO encrypted cookie: 46e4aa106358ddb5->26193c745679a129 msgid: 8e806e2e len: 68 Aug 13 18:04:40.546782 64.119.xx.yy.29337 > 213.41.245.21.123: v4 client strat 0 poll 0 prec 0 [tos 0x10] Aug 13 18:04:40.767452 213.41.245.21.123 > 64.119.xx.yy.29337: v4 server strat 2 poll 0 prec -20 (DF) Aug 13 18:04:42.084865 64.119.33.178 > 224.0.0.5: OSPFv2-hello 56: [len 44] [tos 0xc0] [ttl 1] Aug 13 18:04:44.012876 64.119.40.173.5060 > 64.119.xx.yy.60719: udp 490 (DF) [tos 0xb8] Aug 13 18:04:44.048339 64.119.xx.yy.60719 > 64.119.40.173.5060: udp 488 [tos 0xb0] Aug 13 18:04:44.227369 64.119.xx.yy.4500 > 64.119.aa.bbb.4500:udpencap:isakmp v1.0 exchange INFO encrypted cookie: 46e4aa106358ddb5->26193c745679a129 msgid: 14800c89 len: 84 Aug 13 18:04:44.288706 64.119.aa.bbb.4500 > 64.119.xx.yy.4500:udpencap:isakmp v1.0 exchange INFO encrypted cookie: 46e4aa106358ddb5->26193c745679a129 msgid: 894489f9 len: 84 Aug 13 18:04:45.068700 64.119.xx.yy.60719 > 64.119.40.173.5060: udp 680 [tos 0xb0] Aug 13 18:04:45.135503 64.119.40.173.5060 > 64.119.xx.yy.60719: udp
Re: ipsec vpn?
On 2007/08/13 21:00, Steve B wrote: > If I am interpreting the logs correctly then I have partial success using > > ike dynamic esp tunnel from any to 192.168.1.0/24 \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha2-256 enc 3des \ > psk abc123 > > I am confident that the first two lines are correct. The dynamic variable > should be correct if the incoming IP address is different for every user. > Line two should be OK since it appears I have a successful Phase 1. I've > SSH'd into the endpoint and run tcpdump against my external interface and > enc0. I have also used "ipssectl -m". So far I have not picked up any new > clues to help resolve the remainder of the problem. turn on packet tracing; # echo "p on" > /var/run/isakmpd.fifo try and make a connection, then turn tracing back off: # echo "p off" > /var/run/isakmpd.fifo see isakmpd(8) for more FIFO commands. Then you can look at the capture file with tcpdump: # tcpdump -r /var/run/isakmpd.pcap -vvn this should give some clues about how the peer is configured. You may well find it's using SHA1 not SHA2, but go through the pcap/tcpdump thing anyway, it's the easiest way to debug the peer connection. In the tcpdump you posted I think you didn't increase snaplen (e.g. -s 2000) to see the actual exchange (otherwise you would have seen more details for phase 1). Not necessary for the -r used here since isakmpd writes the pcap file with larger packet sizes.
Re: ipsec vpn?
On Mon, Aug 13, 2007 at 01:30:11AM +0300, Sergey Prysiazhnyi wrote: > ike dynamic from any to any \ > main auth hmac-sha1 enc aes group modp1024 \ > quick auth hmac-sha1 enc aes psk secret > > ; ike passive, ike passive esp, ike esp, etc - no results. On the openbsd gateway you need something like this ike passive from any to 10.1.1.0/24 \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des psk secret The default transform of the greenbowclient for phase 1 is 3des/sha1/modp1024, for phase 1 3des/sha1.
Re: ipsec vpn?
And I should mention, that in the "any to any" case you can not use -K and you have to specify an isakmpd.policy file. On Wed, Aug 15, 2007 at 10:37:59PM +0200, Hans-Joerg Hoexer wrote: > On Mon, Aug 13, 2007 at 01:30:11AM +0300, Sergey Prysiazhnyi wrote: > > ike dynamic from any to any \ > > main auth hmac-sha1 enc aes group modp1024 \ > > quick auth hmac-sha1 enc aes psk secret > > > > ; ike passive, ike passive esp, ike esp, etc - no results. > > On the openbsd gateway you need something like this > > ike passive from any to 10.1.1.0/24 \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha1 enc 3des psk secret > > The default transform of the greenbowclient for phase 1 is > 3des/sha1/modp1024, for phase 1 3des/sha1.
Re: ipsec vpn?
On Wed, Aug 15, 2007 at 10:37:59PM +0200, Hans-Joerg Hoexer wrote:
> On Mon, Aug 13, 2007 at 01:30:11AM +0300, Sergey Prysiazhnyi wrote:
> > ike dynamic from any to any \
> > main auth hmac-sha1 enc aes group modp1024 \
> > quick auth hmac-sha1 enc aes psk secret
> >
> > ; ike passive, ike passive esp, ike esp, etc - no results.
>
> On the openbsd gateway you need something like this
>
> ike passive from any to 10.1.1.0/24 \
> main auth hmac-sha1 enc 3des group modp1024 \
> quick auth hmac-sha1 enc 3des psk secret
>
> The default transform of the greenbowclient for phase 1 is
> 3des/sha1/modp1024, for phase 1 3des/sha1.
Thank you Hans-Joerg, but it is still useless for me: :(
sudo cat /etc/ipsec.conf
ike passive from any to 10.1.1.0/24 \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des psk secret
pf.conf rules relative to ipsec:
set skip on { lo enc0 }
pass in on $ext_if proto udp to ($ext_if) port { 500, 4500 }
pass out on $ext_if proto udp from ($ext_if) to port { 500, 4500 }
pass in on $ext_if proto esp to ($ext_if)
pass out on $ext_if proto esp from ($ext_if)
pass in on enc0 proto ipencap to ($ext_if) keep state (if-bound)
pass out on enc0 proto ipencap from ($ext_if) keep state (if-bound)
further:
isakmpd -dKv &
ipsecctl -F
ipsecctl -f /etc/ipsec.conf
greenbowclient: all parameters are in accordance with ipsec.conf on gateway
side:
logs on gw -
023255.538907 Default isakmpd: phase 1 done: initiator id c0a80321:
192.168.3.33, responder id 5851eaa2: 88.81.XX.XX, src: 88.81.XX.XX dst:
77.123.XX.XX
023255.558498 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase
2 IDs: initiator id c0a80321: 192.168.3.33, responder id 0a010100/ff00:
10.1.1.0/255.255.255.0
023255.558643 Default dropped message from 77.123.XX.XX port 60056 due to
notification type NO_PROPOSAL_CHOSEN
023302.570472 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase
2 IDs: initiator id c0a80321: 192.168.3.33, responder id 0a010100/ff00:
10.1.1.0/255.255.255.0
023302.570660 Default dropped message from 77.123.XX.XX port 60056 due to
notification type NO_PROPOSAL_CHOSEN
greenbowclient logs -
20070816 023245 Default IKE daemon is removing SAs...
20070816 023250 Default Reinitializing IKE daemon
20070816 023250 Default IKE daemon reinitialized
20070816 023258 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode [SA] [VID]
[VID] [VID] [VID]
20070816 023258 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode [SA] [VID]
[VID] [VID] [VID] [VID]
20070816 023258 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode [KEY_EXCH]
[NONCE] [NAT_D] [NAT_D]
20070816 023258 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode [KEY_EXCH]
[NONCE] [NAT_D] [NAT_D]
20070816 023258 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode [HASH] [ID]
20070816 023258 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode [HASH] [ID]
[NOTIFY]
20070816 023258 Default phase 1 done: initiator id 192.168.3.33, responder id
88.81.234.162
20070816 023258 Default (SA CnxVpn1-CnxVpn1-P2) SEND phase 2 Quick Mode [HASH]
[SA] [NONCE] [ID] [ID]
20070816 023258 Default (SA CnxVpn1-P1) RECV Informational [HASH] [NOTIFY]
with NO_PROPOSAL_CHOSEN error
20070816 023305 Default (SA CnxVpn1-CnxVpn1-P2) SEND phase 2 Quick Mode [HASH]
[SA] [NONCE] [ID] [ID]
20070816 023305 Default (SA CnxVpn1-P1) RECV Informational [HASH] [NOTIFY]
with NO_PROPOSAL_CHOSEN error
20070816 023328 Default (SA CnxVpn1-P1) SEND Informational [HASH] [NOTIFY]
type DPD_R_U_THERE
20070816 023328 Default (SA CnxVpn1-P1) RECV Informational [HASH] [NOTIFY]
type DPD_R_U_THERE_ACK
PS: gw on 4.1-stable, roaming users behind OpenBSD box on 4.2.
My continued thanks,
--
Sergey Prysiazhnyi
Re: ipsec vpn?
Can you try to run isakmpd without "-K" and use a 2 line isakmpd.policy
like this:
KeyNote-Version: 2
Authorizer: "POLICY"
This policy accepts anything, so this should be done only for testing.
On Thu, Aug 16, 2007 at 02:53:44AM +0300, Sergey Prysiazhnyi wrote:
> On Wed, Aug 15, 2007 at 10:37:59PM +0200, Hans-Joerg Hoexer wrote:
> > On Mon, Aug 13, 2007 at 01:30:11AM +0300, Sergey Prysiazhnyi wrote:
> > > ike dynamic from any to any \
> > > main auth hmac-sha1 enc aes group modp1024 \
> > > quick auth hmac-sha1 enc aes psk secret
> > >
> > > ; ike passive, ike passive esp, ike esp, etc - no results.
> >
> > On the openbsd gateway you need something like this
> >
> > ike passive from any to 10.1.1.0/24 \
> > main auth hmac-sha1 enc 3des group modp1024 \
> > quick auth hmac-sha1 enc 3des psk secret
> >
> > The default transform of the greenbowclient for phase 1 is
> > 3des/sha1/modp1024, for phase 1 3des/sha1.
>
> Thank you Hans-Joerg, but it is still useless for me: :(
>
> sudo cat /etc/ipsec.conf
> ike passive from any to 10.1.1.0/24 \
> main auth hmac-sha1 enc 3des group modp1024 \
> quick auth hmac-sha1 enc 3des psk secret
>
> pf.conf rules relative to ipsec:
>
> set skip on { lo enc0 }
>
> pass in on $ext_if proto udp to ($ext_if) port { 500, 4500 }
> pass out on $ext_if proto udp from ($ext_if) to port { 500, 4500 }
> pass in on $ext_if proto esp to ($ext_if)
> pass out on $ext_if proto esp from ($ext_if)
> pass in on enc0 proto ipencap to ($ext_if) keep state (if-bound)
> pass out on enc0 proto ipencap from ($ext_if) keep state (if-bound)
>
> further:
>
> isakmpd -dKv &
> ipsecctl -F
> ipsecctl -f /etc/ipsec.conf
>
> greenbowclient: all parameters are in accordance with ipsec.conf on gateway
> side:
>
> logs on gw -
>
> 023255.538907 Default isakmpd: phase 1 done: initiator id c0a80321:
> 192.168.3.33, responder id 5851eaa2: 88.81.XX.XX, src: 88.81.XX.XX dst:
> 77.123.XX.XX
> 023255.558498 Default responder_recv_HASH_SA_NONCE: peer proposed invalid
> phase 2 IDs: initiator id c0a80321: 192.168.3.33, responder id
> 0a010100/ff00: 10.1.1.0/255.255.255.0
> 023255.558643 Default dropped message from 77.123.XX.XX port 60056 due to
> notification type NO_PROPOSAL_CHOSEN
> 023302.570472 Default responder_recv_HASH_SA_NONCE: peer proposed invalid
> phase 2 IDs: initiator id c0a80321: 192.168.3.33, responder id
> 0a010100/ff00: 10.1.1.0/255.255.255.0
> 023302.570660 Default dropped message from 77.123.XX.XX port 60056 due to
> notification type NO_PROPOSAL_CHOSEN
>
> greenbowclient logs -
>
> 20070816 023245 Default IKE daemon is removing SAs...
> 20070816 023250 Default Reinitializing IKE daemon
> 20070816 023250 Default IKE daemon reinitialized
> 20070816 023258 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode [SA] [VID]
> [VID] [VID] [VID]
> 20070816 023258 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode [SA] [VID]
> [VID] [VID] [VID] [VID]
> 20070816 023258 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode [KEY_EXCH]
> [NONCE] [NAT_D] [NAT_D]
> 20070816 023258 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode [KEY_EXCH]
> [NONCE] [NAT_D] [NAT_D]
> 20070816 023258 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode [HASH] [ID]
> 20070816 023258 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode [HASH] [ID]
> [NOTIFY]
> 20070816 023258 Default phase 1 done: initiator id 192.168.3.33, responder id
> 88.81.234.162
> 20070816 023258 Default (SA CnxVpn1-CnxVpn1-P2) SEND phase 2 Quick Mode
> [HASH] [SA] [NONCE] [ID] [ID]
> 20070816 023258 Default (SA CnxVpn1-P1) RECV Informational [HASH] [NOTIFY]
> with NO_PROPOSAL_CHOSEN error
> 20070816 023305 Default (SA CnxVpn1-CnxVpn1-P2) SEND phase 2 Quick Mode
> [HASH] [SA] [NONCE] [ID] [ID]
> 20070816 023305 Default (SA CnxVpn1-P1) RECV Informational [HASH] [NOTIFY]
> with NO_PROPOSAL_CHOSEN error
> 20070816 023328 Default (SA CnxVpn1-P1) SEND Informational [HASH] [NOTIFY]
> type DPD_R_U_THERE
> 20070816 023328 Default (SA CnxVpn1-P1) RECV Informational [HASH] [NOTIFY]
> type DPD_R_U_THERE_ACK
>
> PS: gw on 4.1-stable, roaming users behind OpenBSD box on 4.2.
>
> My continued thanks,
>
> --
> Sergey Prysiazhnyi
Re: ipsec vpn?
I made a few changes and did some more testing this evening. 1. I changed the /etc/ipsec.conf to bring it in line with the Greenbow default transforms that Hans-Joerg recommened. # cat /etc/ipsec.conf ike dynamic esp tunnel from any to 192.168.1.0/24 \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des \ psk abc123 2. I created the basic polciy file: # cat /etc/isakmpd/isakmpd.policy KeyNote-Version: 2 Authorizer: "POLICY" 3. Being lazy I rebooted the server and tried starting isakmpd manually without the "-K". It would not start. When I tried starting it with "-dLv" I got the message: 180252.969043 Default check_file_secrecy_fd: not loading /etc/isakmpd/isakmpd.policy - too open permissions 180252.970281 Default policy_init: cannot read /etc/isakmpd/isakmpd.policy: Operation not permitted So I went back and started it with "-K". 4. I then turned on packet tracing as Stuart suggested, tried logging in, turned packet tracing off and ran tcpdump on the file: # echo "p on" > /var/run/isakmpd.fifo # echo "p off" > /var/run/isakmpd.fifo # tcpdump -r /var/run/isakmpd.pcap -vvn tcpdump: WARNING: snaplen raised from 96 to 65536 18:08:57.938430 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: ed67c89ed96545fb-> msgid: len: 160 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports v1 NAT-T, draft-ietf-ipsec-nat-t-ike-00) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 188) 18:08:57.944015 64.119.37.74.500 > 64.119.40.170.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: cfef30980a709fe2-> msgid: len: 40 payload: NOTIFICATION len: 12 notification: NO PROPOSAL CHOSEN [ttl 0] (id 1, len 68) 5. OK, no good. Nothing jumped out at me in the tcpdump so I changed from dynamic to passive, and tried again: # cat /etc/ipsec.conf ike passive esp tunnel from any to 192.168.1.0/24 \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des \ psk abc123 # ipsecctl -f /etc/ipsec.conf killed the isakmpd daemon and restarted it with -K", turned packet tracing back on and tried everything again. Got more detail but nothing jumps out at me. # tcpdump -r /var/run/isakmpd.pcap -vvn tcpdump: WARNING: snaplen raised from 96 to 65536 18:08:57.938430 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: ed67c89ed96545fb-> msgid: len: 160 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports v1 NAT-T, draft-ietf-ipsec-nat-t-ike-00) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 188) 18:08:57.944015 64.119.37.74.500 > 64.119.40.170.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: cfef30980a709fe2-> msgid: len: 40 payload: NOTIFICATION len: 12 notification: NO PROPOSAL CHOSEN [ttl 0] (id 1, len 68) 18:24:12.441476 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 7c923ecb8d9a90f0-> msgid: len: 160 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM =
Re: ipsec vpn?
On Thu, Aug 16, 2007 at 06:43:34PM -0700, Steve B wrote: > I made a few changes and did some more testing this evening. > > 1. I changed the /etc/ipsec.conf to bring it in line with the Greenbow > default transforms that Hans-Joerg recommened. > > # cat /etc/ipsec.conf > ike dynamic esp tunnel from any to 192.168.1.0/24 \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha1 enc 3des \ > psk abc123 > > 2. I created the basic polciy file: > > # cat /etc/isakmpd/isakmpd.policy > KeyNote-Version: 2 > Authorizer: "POLICY" > > 3. Being lazy I rebooted the server and tried starting isakmpd manually > without the "-K". It would not start. When I tried starting it with "-dLv" I > got the message: > > 180252.969043 Default check_file_secrecy_fd: not loading > /etc/isakmpd/isakmpd.policy - too open permissions > 180252.970281 Default policy_init: cannot read /etc/isakmpd/isakmpd.policy: > Operation not permitted > > So I went back and started it with "-K". please go back to step 2, however this time set the permissions of /etc/isakmpd/isakmpd.policy to 600. > 4. I then turned on packet tracing as Stuart suggested, tried logging in, > turned packet tracing off and ran tcpdump on the file: > > # echo "p on" > /var/run/isakmpd.fifo > > # echo "p off" > /var/run/isakmpd.fifo > > # tcpdump -r /var/run/isakmpd.pcap -vvn > tcpdump: WARNING: snaplen raised from 96 to 65536 > 18:08:57.938430 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp > v1.0 exchange ID_PROT > cookie: ed67c89ed96545fb-> msgid: len: 160 > payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY > payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 > xforms: 1 > payload: TRANSFORM len: 32 > transform: 0 ID: ISAKMP > attribute ENCRYPTION_ALGORITHM = 3DES_CBC > attribute HASH_ALGORITHM = SHA > attribute AUTHENTICATION_METHOD = PRE_SHARED > attribute GROUP_DESCRIPTION = MODP_1024 > attribute LIFE_TYPE = SECONDS > attribute LIFE_DURATION = 3600 > payload: VENDOR len: 20 (supports v1 NAT-T, > draft-ietf-ipsec-nat-t-ike-00) > payload: VENDOR len: 20 (supports v2 NAT-T, > draft-ietf-ipsec-nat-t-ike-02) > payload: VENDOR len: 20 (supports v3 NAT-T, > draft-ietf-ipsec-nat-t-ike-03) > payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 188) > 18:08:57.944015 64.119.37.74.500 > 64.119.40.170.500: [udp sum ok] isakmp > v1.0 exchange INFO > cookie: cfef30980a709fe2-> msgid: len: 40 > payload: NOTIFICATION len: 12 > notification: NO PROPOSAL CHOSEN [ttl 0] (id 1, len 68) > > 5. OK, no good. Nothing jumped out at me in the tcpdump so I changed from > dynamic to passive, and tried again: > > # cat /etc/ipsec.conf > ike passive esp tunnel from any to 192.168.1.0/24 \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha1 enc 3des \ > psk abc123 > > # ipsecctl -f /etc/ipsec.conf > > killed the isakmpd daemon and restarted it with -K", turned packet tracing > back on and tried everything again. Got more detail but nothing jumps out at > me. > > # tcpdump -r /var/run/isakmpd.pcap -vvn > tcpdump: WARNING: snaplen raised from 96 to 65536 > 18:08:57.938430 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp > v1.0 exchange ID_PROT > cookie: ed67c89ed96545fb-> msgid: len: 160 > payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY > payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 > xforms: 1 > payload: TRANSFORM len: 32 > transform: 0 ID: ISAKMP > attribute ENCRYPTION_ALGORITHM = 3DES_CBC > attribute HASH_ALGORITHM = SHA > attribute AUTHENTICATION_METHOD = PRE_SHARED > attribute GROUP_DESCRIPTION = MODP_1024 > attribute LIFE_TYPE = SECONDS > attribute LIFE_DURATION = 3600 > payload: VENDOR len: 20 (supports v1 NAT-T, > draft-ietf-ipsec-nat-t-ike-00) > payload: VENDOR len: 20 (supports v2 NAT-T, > draft-ietf-ipsec-nat-t-ike-02) > payload: VENDOR len: 20 (supports v3 NAT-T, > draft-ietf-ipsec-nat-t-ike-03) > payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 188) > 18:08:57.944015 64.119.37.74.500 > 64.119.40.170.500: [udp sum ok] isakmp > v1.0 exchange INFO > cookie: cfef30980a709fe2-> msgid: len: 40 > payload: NOTIFICATION len: 12 > notification: NO PROPOSAL CHOSEN [ttl 0] (id 1, len 68) > 18:24:12.441476 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp > v1.0 exchange ID_PROT > cookie: 7c923ecb8d9a90f0->
Re: ipsec vpn?
On Thu, Aug 16, 2007 at 06:43:34PM -0700, Steve B wrote: > I made a few changes and did some more testing this evening. > > 1. I changed the /etc/ipsec.conf to bring it in line with the Greenbow > default transforms that Hans-Joerg recommened. > > # cat /etc/ipsec.conf > ike dynamic esp tunnel from any to 192.168.1.0/24 \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha1 enc 3des \ > psk abc123 > > 2. I created the basic polciy file: > > # cat /etc/isakmpd/isakmpd.policy > KeyNote-Version: 2 > Authorizer: "POLICY" > > 3. Being lazy I rebooted the server and tried starting isakmpd manually > without the "-K". It would not start. When I tried starting it with "-dLv" I > got the message: > > 180252.969043 Default check_file_secrecy_fd: not loading > /etc/isakmpd/isakmpd.policy - too open permissions > 180252.970281 Default policy_init: cannot read /etc/isakmpd/isakmpd.policy: > Operation not permitted > > So I went back and started it with "-K". wrong. just fix the permissions of the policy file: chmod 600 /etc/isakmpd/isakmpd.policy
Re: ipsec vpn?
Following the advice from Hans-Joerg and Markus I changed the ipsec.con file back to the default transforms sent by Greenbow, ran ipsecctl -f /eetc/ipsec.conf, changed the permissions on the policy file and started isakmpd without the "-K". Greenbow logging shows I did not even get past the Phase 1 negotiation # cat /etc/ipsec.conf ike dynamic esp tunnel from any to 192.168.1.0/24 \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des \ psk abc123 # ipsecctl -f /etc/ipsec.conf # chmod 600 /etc/isakmpd/isakmpd.policy # ls -al /etc/isakmpd/isakmpd.policy -rw--- 1 root wheel 40 Aug 16 12:20 /etc/isakmpd/isakmpd.policy # ps ax |grep isakmpd 17575 ?? Is 0:00.02 isakmpd: monitor [priv] (isakmpd) 12021 ?? I 0:00.60 isakmpd # echo "p on" > /var/run/isakmpd.fifo # echo "p off" > /var/run/isakmpd.fifo # tcpdump -r /var/run/isakmpd.pcap -vvn tcpdump: WARNING: snaplen raised from 96 to 65536 13:18:38.973099 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 8c3f9c08dbcbb765-> msgid: len: 160 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports v1 NAT-T, draft-ietf-ipsec-nat-t-ike-00) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 188) 13:18:38.974019 64.119.37.74.500 > 64.119.40.170.500: [udp sum ok] isakmp v1.0 exchange INFO cookie: 39af4dec2463f320-> msgid: len: 40 payload: NOTIFICATION len: 12 notification: NO PROPOSAL CHOSEN [ttl 0] (id 1, len 68) Greenbow log: [VPNCONF] TGBIKESTART received 20070818 131838 Default (SA Home_Network-P1) SEND phase 1 Main Mode [SA] [VID] [VID] [VID] [VID] 20070818 131838 Default (SA ) RECV Informational [NOTIFY] with NO_PROPOSAL_CHOSEN error 20070818 131845 Default (SA Home_Network-P1) SEND phase 1 Main Mode [SA] [VID] [VID] [VID] [VID]
Re: ipsec vpn?
I finally have some SUCCESS to report! I changed the ipsec.con file back to the one that I got to work on Phase 1, but appeared to be hanging on Phase 2, ran ipsecctl -f /etc/ipsec.conf and started isakmpd without the "-K". Greenbow now reports both Phases worked and I had a tunnel. When I tested from the command line I was able to ping from one location to the other!! The only question that remains is, how can I determine traffic is passing over the IPSEC VPN instead of whatever connection it got to establish the VPN? # cat /etc/ipsec.conf ike dynamic esp tunnel from any to 192.168.1.0/24 \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha2-256 enc 3des \ psk abc123 # ipsecctl -f /etc/ipsec.conf # ps ax |grep isakmpd 17023 ?? Is 0:00.02 isakmpd: monitor [priv] (isakmpd) 19046 ?? I 0:00.79 isakmpd # echo "p on" > /var/run/isakmpd.fifo # echo "p off" > /var/run/isakmpd.fifo # tcpdump -r /var/run/isakmpd.pcap -vvn 13:29:04.815727 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 14a9d793fabd9a1b-> msgid: len: 160 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports v1 NAT-T, draft-ietf-ipsec-nat-t-ike-00) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len 188) 13:29:04.826775 64.119.37.74.500 > 64.119.40.170.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: len: 180 payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 xforms: 1 payload: TRANSFORM len: 32 transform: 0 ID: ISAKMP attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute HASH_ALGORITHM = SHA attribute AUTHENTICATION_METHOD = PRE_SHARED attribute GROUP_DESCRIPTION = MODP_1024 attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 3600 payload: VENDOR len: 20 (supports 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) 13:29:04.959737 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: len: 228 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D-DRAFT len: 24 payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256) 13:29:05.06 64.119.37.74.4500 > 64.119.40.170.4500: [udp sum ok] udpencap: isakmp v1.0 exchange ID_PROT cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: len: 228 payload: KEY_EXCH len: 132 payload: NONCE len: 20 payload: NAT-D-DRAFT len: 24 payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 260) 13:29:05.196922 64.119.40.170.4500 > 64.119.37.74.4500: [bad udp cksum a274!] udpencap: isakmp v1.0 exchange ID_PROT cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: len: 92 payload: ID len: 12 type: IPV4_ADDR = 192.168.11.109 payload: HASH len: 24 payload: NOTIFICATION len: 28 notification: INITIAL CONTACT (14a9d793fabd9a1b->40a39c778bcbd5eb) [ttl 0] (id 1, len 124) 13:29:05.197530 64.119.37.74.4500 > 64.119.40.170.4500: [bad udp cksum 4d5e!] udpencap: isakmp v1.0 exchange ID_PROT cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: len: 104 payload: ID len: 24 type: FQDN = "gateway.home.lan" payload: HASH len: 24 payload: NOTIFICATION len: 28 notification: INITIAL CONTACT (14a9d793fabd9a1b->40a39c778bcbd5eb) [ttl 0] (id 1, len 136) 13:29:05.252842 64.119.40.170.4500 > 64.119.37.74.500: [bad udp cksum 978e!] udpencap: isakmp v1.0 exchange QUICK_MODE cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: a36e0ba2 len: 148 payload: HASH len: 24 payload: SA len: 48 DOI: 1(IPSEC) situation:
Re: ipsec vpn?
Hans-Joerg, Markus - Thanks for the advice and the help. I sat down and did some more testing at work. I definitely have an IPSEC tunnel from one point to the other. Any suggestions on how I can now have my users route all of their traffic through our end? I'd like them to be able to safely browse sites from Internet cafes and such. On 8/18/07, Steve B <[EMAIL PROTECTED]> wrote: > > I finally have some SUCCESS to report! I changed the ipsec.con file > back to the one that I got to work on Phase 1, but appeared to be hanging on > Phase 2, ran ipsecctl -f /etc/ipsec.conf and started isakmpd without the > "-K". Greenbow now reports both Phases worked and I had a tunnel. When I > tested from the command line I was able to ping from one location to the > other!! The only question that remains is, how can I determine traffic is > passing over the IPSEC VPN instead of whatever connection it got to > establish the VPN? > > # cat /etc/ipsec.conf > ike dynamic esp tunnel from any to 192.168.1.0/24 \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha2-256 enc 3des \ > psk abc123 > > # ipsecctl -f /etc/ipsec.conf > > # ps ax |grep isakmpd > 17023 ?? Is 0:00.02 isakmpd: monitor [priv] (isakmpd) > 19046 ?? I 0:00.79 isakmpd > > # echo "p on" > /var/run/isakmpd.fifo > # echo "p off" > /var/run/isakmpd.fifo > # tcpdump -r /var/run/isakmpd.pcap -vvn > > 13:29:04.815727 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp > v1.0 exchange ID_PROT > cookie: 14a9d793fabd9a1b-> msgid: len: > 160 > payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY > payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 > xforms: 1 > payload: TRANSFORM len: 32 > transform: 0 ID: ISAKMP > attribute ENCRYPTION_ALGORITHM = 3DES_CBC > attribute HASH_ALGORITHM = SHA > attribute AUTHENTICATION_METHOD = PRE_SHARED > attribute GROUP_DESCRIPTION = MODP_1024 > attribute LIFE_TYPE = SECONDS > attribute LIFE_DURATION = 3600 > payload: VENDOR len: 20 (supports v1 NAT-T, > draft-ietf-ipsec-nat-t-ike-00) > payload: VENDOR len: 20 (supports v2 NAT-T, > draft-ietf-ipsec-nat-t-ike-02) > payload: VENDOR len: 20 (supports v3 NAT-T, > draft-ietf-ipsec-nat-t-ike-03) > payload: VENDOR len: 20 (supports DPD v1.0) [ttl 0] (id 1, len > 188) > 13:29:04.826775 64.119.37.74.500 > 64.119.40.170.500 : [udp sum ok] isakmp > v1.0 exchange ID_PROT > cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: len: > 180 > payload: SA len: 52 DOI: 1(IPSEC) situation: IDENTITY_ONLY > payload: PROPOSAL len: 40 proposal: 1 proto: ISAKMP spisz: 0 > xforms: 1 > payload: TRANSFORM len: 32 > transform: 0 ID: ISAKMP > attribute ENCRYPTION_ALGORITHM = 3DES_CBC > attribute HASH_ALGORITHM = SHA > attribute AUTHENTICATION_METHOD = PRE_SHARED > attribute GROUP_DESCRIPTION = MODP_1024 > attribute LIFE_TYPE = SECONDS > attribute LIFE_DURATION = 3600 > payload: VENDOR len: 20 (supports 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) > 13:29:04.959737 64.119.40.170.500 > 64.119.37.74.500: [udp sum ok] isakmp > v1.0 exchange ID_PROT > cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: len: > 228 > payload: KEY_EXCH len: 132 > payload: NONCE len: 20 > payload: NAT-D-DRAFT len: 24 > payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 256) > 13:29:05.06 64.119.37.74.4500 > 64.119.40.170.4500: [udp sum ok] > udpencap: isakmp v1.0 exchange ID_PROT > cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: len: > 228 > payload: KEY_EXCH len: 132 > payload: NONCE len: 20 > payload: NAT-D-DRAFT len: 24 > payload: NAT-D-DRAFT len: 24 [ttl 0] (id 1, len 260) > 13:29:05.196922 64.119.40.170.4500 > 64.119.37.74.4500: [bad udp cksum > a274!] udpencap: isakmp v1.0 exchange ID_PROT > cookie: 14a9d793fabd9a1b->40a39c778bcbd5eb msgid: len: 92 > payload: ID len: 12 type: IPV4_ADDR = 192.168.11.109 > payload: HASH len: 24 > payload: NOTIFICATION len: 28 > notification: INITIAL CONTACT > (14a9d793fabd9a1b->40a39c778bcbd5eb) [ttl 0] (id 1, len 124) > 13:29:05.197530 64.119.37.74.4500 > 64.119.40.170.4500: [bad udp cksum > 4d5e!] udpencap: isakmp v1.0 exchange ID_PROT >
Re: ipsec vpn?
On Thu, Aug 16, 2007 at 09:56:05AM +0200, Hans-Joerg Hoexer wrote: > Can you try to run isakmpd without "-K" and use a 2 line isakmpd.policy > like this: > > KeyNote-Version: 2 > Authorizer: "POLICY" > > This policy accepts anything, so this should be done only for testing. Well done this such policy Hans: 1. ps ax | g isa 914 ?? Is 0:00.02 isakmpd: monitor [priv] (isakmpd) 24931 ?? I 0:00.70 isakmpd ; ls -la /etc/isakmpd/isakmpd.policy ; -rw--- 1 root wheel 40 Aug 23 01:25 /etc/isakmpd/isakmpd.policy 2. cat /etc/ipsec.conf ike passive from any to 10.1.1.0/24 \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des psk q1w2e3 3. ipsecctl -F -f /etc/ipsec.conf 4. NO any problems from GreenBow VPN Client side: 20070823 014500 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode [SA] [VID] [VID] [VID] [VID] 20070823 014500 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode [SA] [VID] [VID] [VID] [VID] [VID] 20070823 014500 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode [KEY_EXCH] [NONCE] [NAT_D] [NAT_D] 20070823 014500 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode [KEY_EXCH] [NONCE] [NAT_D] [NAT_D] 20070823 014500 Default (SA CnxVpn1-P1) SEND phase 1 Main Mode [HASH] [ID] 20070823 014500 Default (SA CnxVpn1-P1) RECV phase 1 Main Mode [HASH] [ID] [NOTIFY] 20070823 014500 Default phase 1 done: initiator id 192.168.3.33, responder id 88.81.234.162 20070823 014500 Default (SA CnxVpn1-CnxVpn1-P2) SEND phase 2 Quick Mode [HASH] [SA] [NONCE] [ID] [ID] 20070823 014500 Default (SA CnxVpn1-CnxVpn1-P2) RECV phase 2 Quick Mode [HASH] [SA] [NONCE] [ID] [ID] 20070823 014500 Default (SA CnxVpn1-CnxVpn1-P2) SEND phase 2 Quick Mode [HASH] 20070823 014530 Default (SA CnxVpn1-P1) SEND Informational [HASH] [NOTIFY] type DPD_R_U_THERE 20070823 014530 Default (SA CnxVpn1-P1) RECV Informational [HASH] [NOTIFY] type DPD_R_U_THERE_ACK 20070823 014600 Default (SA CnxVpn1-P1) SEND Informational [HASH] [NOTIFY] type DPD_R_U_THERE 20070823 014600 Default (SA CnxVpn1-P1) RECV Informational [HASH] [NOTIFY] type DPD_R_U_THERE_ACK ; But, still not working for me without isakmpd.policies. ??? Thank you very much, -- Sergey Prysiazhnyi
Re: ipsec vpn
On 11/2/06, Joachim Schipper <[EMAIL PROTECTED]> wrote: On Wed, Nov 01, 2006 at 05:49:18PM -0800, Bryan Irvine wrote: > I'm going to upgrading a couple of our firewalls soon and as part of > the upgrade I will be implementing VPN between a couple of our sites. > > Does this page still apply: http://www.securityfocus.com/infocus/1859 Yes, although some additions have been made since (notably, AH works too). > Any pitfalls or changes I should watch out for? Filtering IPsec traffic might take some experimentation to get right. > These firewall are running CARP. Don't forget sasyncd; it has gotten *much* better in 4.0. Now that's a nice touch :-) Also[1], there may be the need for an occasional connection from users just using the windows vpn client. Anybody doing this? I rarely even see windows so I'm not sure what to look for there. Do I need to import a key of some sort, or set authentication somehow?
Re: ipsec vpn
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] ("Bryan Irvine") writes:
> Also[1], there may be the need for an occasional connection from users
> just using the windows vpn client. Anybody doing this? I rarely even
> see windows so I'm not sure what to look for there.
> Do I need to import a key of some sort, or set authentication somehow?
My understanding is, if you want to support the simple connection
of Windows clients, using the built-in VPN connector (eg. control
panel -> network -> make new connection -> VPN -> L2TP), the
server side needs:
1. IPSec VPN transport mode, most likely with dynamic IP endpoint
2. L2TP tunneling daemon
3. PPP daemon
You will also need NAT traversal in the server and client IPSec
implementation, if the client is connecting from behind a NAT
firewall/device.
2000 and XP will support NAT traversal with the right service
packs, OpenBSD 4.0, according to my checking of man pages this
evening, should support NAT-T too.
2000 and XP will support authentication using X.509 (ie. SSL
like) certificates, only XP will support PSK (pre-shared-key).
This is from my recent research of trying to get this working
with Debian, but I gave up because the server versions of s/w
I was using didn't support NAT-T, AFAICS. I've not tried it
with OpenBSD, yet.
All AIUI, some of that could be wrong as I've not had it
working yet.
-Paul-
Re: ipsec vpn
On Thu, Nov 02, 2006 at 03:51:04PM -0800, Bryan Irvine wrote: > On 11/2/06, Joachim Schipper <[EMAIL PROTECTED]> wrote: > >On Wed, Nov 01, 2006 at 05:49:18PM -0800, Bryan Irvine wrote: > >> I'm going to upgrading a couple of our firewalls soon and as part of > >> the upgrade I will be implementing VPN between a couple of our sites. > >> > >> Does this page still apply: http://www.securityfocus.com/infocus/1859 > > > >Yes, although some additions have been made since (notably, AH works > >too). > > > >> Any pitfalls or changes I should watch out for? > > > >Filtering IPsec traffic might take some experimentation to get right. > > > >> These firewall are running CARP. > > > >Don't forget sasyncd; it has gotten *much* better in 4.0. > > Now that's a nice touch :-) > > > Also[1], there may be the need for an occasional connection from users > just using the windows vpn client. Anybody doing this? I rarely even > see windows so I'm not sure what to look for there. > > Do I need to import a key of some sort, or set authentication somehow? There is some stuff in the archives about Windows clients; the consensus seems to be that the built-in Windows stuff sucks, and that better third-party clients can be had for free (as in beer). I remember hearing Greenbow somewhere. In such a case, there's no more need to use keys than with another OpenBSD box (as in, you probably should use them, but it's not required). Joachim [1] Footnote not found. Not mine, anyway.
Re: ipsec vpn
On Fri, Nov 03, 2006 at 12:35:55AM +, Paul Civati wrote: > My understanding is, if you want to support the simple connection > of Windows clients, using the built-in VPN connector (eg. control > panel -> network -> make new connection -> VPN -> L2TP), the > server side needs: > > > 1. IPSec VPN transport mode, most likely with dynamic IP endpoint > 2. L2TP tunneling daemon > 3. PPP daemon > no. you don't need l2tp + ppp. you're not talking about the built-in ipsec support, you're talking about a stupid wizard... starting with windows 2000, it is possible to use the built-in ipsec support. it is a bit hidden and the configuration is painful, but it actually works... you can configure it from the system management console or by executing "system32\secpol.msc". you can find some details on the openbsd-support.com website about mtu's approach to connect windows clients to openbsd ipsec gateways: http://www.openbsd-support.com/jp/en/htm/mgp/pacsec05/index.html reyk
Re: ipsec vpn
On Fri, Nov 03, 2006 at 12:35:55AM +, Paul Civati wrote: > 2000 and XP will support authentication using X.509 (ie. SSL > like) certificates, only XP will support PSK (pre-shared-key). > i won't necessarily defeat windows, but 2000 and xp do support kerberos 5, x.509 _and_ pre-shared key authentication by default. > > This is from my recent research of trying to get this working > with Debian, but I gave up because the server versions of s/w > I was using didn't support NAT-T, AFAICS. I've not tried it > with OpenBSD, yet. > openbsd's NAT-T works fine and is enabled by default. reyk
Re: ipsec vpn
Reyk Floeter wrote: On Fri, Nov 03, 2006 at 12:35:55AM +, Paul Civati wrote: My understanding is, if you want to support the simple connection of Windows clients, using the built-in VPN connector (eg. control panel -> network -> make new connection -> VPN -> L2TP), the server side needs: 1. IPSec VPN transport mode, most likely with dynamic IP endpoint 2. L2TP tunneling daemon 3. PPP daemon no. you don't need l2tp + ppp. you're not talking about the built-in ipsec support, you're talking about a stupid wizard... starting with windows 2000, it is possible to use the built-in ipsec support. it is a bit hidden and the configuration is painful, but it actually works... you can configure it from the system management console or by executing "system32\secpol.msc". you can find some details on the openbsd-support.com website about mtu's approach to connect windows clients to openbsd ipsec gateways: http://www.openbsd-support.com/jp/en/htm/mgp/pacsec05/index.html reyk I use the following little script to startup ipsec on my w2k and xp clients. Preshared key is in a file c:\vpn\key. Running with certs is also fairly simple. This link http://vpn.ebootis.de/ will show you how to configure the windowze side. Configure the OBSD side as per the manpage. I have clients using the preshared method to AIX boxen, and others using x509 to a OBSD gateway mordred:root:/home/drichard # cat ipseccmds.bat @ECHO OFF if exist "c:\vpn\key" ( for /f "tokens=1" %%a in ( 'type c:\vpn\key') do ( set prekey=%%a) ) ELSE ( echo "No Key no encrypty! EXITING" GOTO END ) for /f "tokens=1" %%a in ( 'hostname') do ( set hostname=%%a) if EXIST "C:\Program Files\Support Tools\ipseccmd.exe" ( REM this is an XP machine then SET PATH=%PATH%;C:\Program Files\Support Tools ipseccmd -w REG -p BobSwan -r Host-arthur -t cqaddr -f %hostname%/255.255.255.255=cqaddr/255.255.255.255 -n ESP[MD5,3DES] -a PRESHARE:""1234"" -lan ipseccmd -w REG -p BobSwan -r arthur-Host -t %hostname% -f cqaddr/255.255.255.255=%hostname%/255.255.255.255 -n ESP[MD5,3DES] -a PRESHARE:""1234"" -lan ipseccmd -w REG -p BobSwan -x GOTO END ) ELSE ( IF EXIST "C:\Program Files\Resource Kit\ipsecpol.exe" ( SET PATH=%PATH%;C:\Program Files\Resource Kit ipsecpol -w REG -p BobSwan -r Host-arthur -t cqaddr -f %hostname%/255.255.255.255=cqaddr/255.255.255.255 -n ESP[MD5,3DES] -a PRESHARE:""1234"" -lan ipsecpol -w REG -p BobSwan -r arthur-Host -t %hostname% -f cqaddr/255.255.255.255=%hostname%/255.255.255.255 -n ESP[MD5,3DES] -a PRESHARE:""1234"" -lan ipsecpol -w REG -p BobSwan -x ) ELSE ( ECHO "Don't know what you are running no ipsec tools installed" ) ) :END
Re: ipsec vpn
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Reyk Floeter) writes: >> 2000 and XP will support authentication using X.509 (ie. SSL >> like) certificates, only XP will support PSK (pre-shared-key). > > i won't necessarily defeat windows, but 2000 and xp do support > kerberos 5, x.509 _and_ pre-shared key authentication by default. Please don't quoute out of context, I was talking about the "stupid wizard" VPN connector not straight IPSec. -Paul-
Re: ipsec vpn
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Reyk Floeter) writes: >> My understanding is, if you want to support the simple connection >> of Windows clients, using the built-in VPN connector (eg. control >> panel -> network -> make new connection -> VPN -> L2TP), the >> server side needs: >> >> 1. IPSec VPN transport mode, most likely with dynamic IP endpoint >> 2. L2TP tunneling daemon >> 3. PPP daemon > > no. you don't need l2tp + ppp. you're not talking about the built-in > ipsec support, you're talking about a stupid wizard... Correct, I wasn't talking about plain IPSec, I was talking about "the simple connection of Windows clients, using the built-in VPN connector" exactly as I wrote. Can we drop the condescending "everyone without an openbsd.org mail address is an idiot" attitude please. I didn't say there was no other possible way to use IPSec on Windows, and my post was quite clear about the method I was talking about. > starting with windows 2000, it is possible to use the built-in ipsec > support. it is a bit hidden and the configuration is painful, but it > actually works... you can configure it from the system management > console or by executing "system32\secpol.msc". Exactly, this is not simple, the "stupid wizard" you refer to is what average joe without in depth IP stack knowledge will want to use, and what some people who have to support client VPN connections may want to use, because it will greatly reduce their support headache - providing server side works smoothly of course. -Paul-
Re: ipsec vpn
Original message >Date: Tue, 07 Nov 2006 19:26:19 + >From: [EMAIL PROTECTED] (Paul Civati) >Subject: Re: ipsec vpn >To: misc@openbsd.org >Cc: [EMAIL PROTECTED] > >> starting with windows 2000, it is possible to use the built-in ipsec >> support. it is a bit hidden and the configuration is painful, but it >> actually works... you can configure it from the system management >> console or by executing "system32\secpol.msc". > >Exactly, this is not simple, the "stupid wizard" you refer to is >what average joe without in depth IP stack knowledge will want >to use, and what some people who have to support client VPN >connections may want to use, because it will greatly reduce >their support headache - providing server side works smoothly >of course. > well, i've setup and gotten the "stupid wizard" version working and it is indeed just that, stupid. AFAICR, there is no good L2TP daemon available. i spent a substantial amount of time getting this to work and the config i ended up with was not at all stable. in addition to having wasted a large amount of time and energy on this, i ended up with a crazed german guy (nobody on list ;) ) yelling at me, claiming that openbsd was a "hobby show" OS and that i was idiot. M$ is notoriously crappy when it comes to VPN software, IMO. openvpn is probably your best shot if you're going cross-platform and the native ipsec client is ok, but can be irritating to work with. oh yeah, and search the archives, there quite a few posts on this topic. >-Paul-
Re: ipsec vpn
On Tue, Nov 07, 2006 at 07:26:19PM +, Paul Civati wrote:
> Correct, I wasn't talking about plain IPSec, I was talking about
> "the simple connection of Windows clients, using the built-in VPN
> connector" exactly as I wrote.
>
> Can we drop the condescending "everyone without an openbsd.org mail
> address is an idiot" attitude please.
>
can you drop the "poor misunderstood user on misc@" attitude please?
talking about "stupid wizards" shouldn't be condescending to you and
it's not an attitude by me.
> I didn't say there was no other possible way to use IPSec on Windows,
> and my post was quite clear about the method I was talking about.
>
> > starting with windows 2000, it is possible to use the built-in ipsec
> > support. it is a bit hidden and the configuration is painful, but it
> > actually works... you can configure it from the system management
> > console or by executing "system32\secpol.msc".
>
> Exactly, this is not simple, the "stupid wizard" you refer to is
> what average joe without in depth IP stack knowledge will want
> to use, and what some people who have to support client VPN
> connections may want to use, because it will greatly reduce
> their support headache - providing server side works smoothly
> of course.
>
"i was talking about [something else]". ok, ok, i got it. but if
you're administrating a network with windows clients you can even
provide tools and software to make their and your life easy. did you
look at the link to mark uemura's slides? he's running a very smart
setup which is secure, redundant (i think he even extended it with
sasyncd) and easy. the only thing his joe average users have to do is
to click a little icon and to type in a password...
my personal oppinion is that depending on a castrated functionality
provided by a such wizards can be stupid. and sometimes it is even
much more difficult to click through these stupid wizards than typing
in a command or editing a human-readble configuration file. it is even
a stupid wizard problem, that users get used to their stupid wizards
and stupidly become to think that stupid wizards are easier to use...
and that is wrong. i know joe average users who started using
computers by running openbsd and they get heavilly scared when they
get in touch with a windows box ("oh, it's so complicated...").
> -Paul-
>
cheers,
reyk
Re: ipsec vpn
> M$ is notoriously crappy when it comes to VPN software, IMO. openvpn is > probably I really wish people would stop advocating this garbage on our mailing lists. -- Mathieu Sauve-Frankel
Re: ipsec vpn
Original message >Date: Wed, 8 Nov 2006 10:05:14 +0900 >From: [EMAIL PROTECTED] (Mathieu Sauve-Frankel) >Subject: Re: ipsec vpn >To: Jacob Yocom-Piatt <[EMAIL PROTECTED]> >Cc: misc@openbsd.org > >> M$ is notoriously crappy when it comes to VPN software, IMO. openvpn is >> probably > >I really wish people would stop advocating this garbage on our mailing lists. > i really wish people wouldn't be such pricks on misc@ ... given a completely free hand, i would NEVER use windows machines for anything remotely important. however, i have been forced to interoperate with M$ users who could not get the "native" IPsec to work to their satisfaction and openvpn is a viable solution in this case. a solution involving M$, is IMO no solution at all, merely another example of turd polishing. since many peoples' brains are too limited in their flexibility, turd polishing is a painful reality when dealing with diverse computer users. >-- >Mathieu Sauve-Frankel
Re: ipsec vpn
Jacob Yocom-Piatt <[EMAIL PROTECTED]> wrote: > > > >> M$ is notoriously crappy when it comes to VPN software, IMO. openvpn is > >> probably > > > >I really wish people would stop advocating this garbage on our mailing lists. > > > > i really wish people wouldn't be such pricks on misc@ ... So stop then. > given a completely free hand, i would NEVER use windows machines for anything > remotely important. however, i have been forced to interoperate with M$ users > who could not get the "native" IPsec to work to their satisfaction and openvpn > is a viable solution in this case. No, its avoiding the problem, not solving it. If you like openvpn that's up to you. But its not a solution to getting ipsec between openbsd and windows, and it is annoying to see it constantly offered here. > a solution involving M$, is IMO no solution at all, merely another example of > turd polishing. since many peoples' brains are too limited in their > flexibility, > turd polishing is a painful reality when dealing with diverse computer users. The problem involves microsoft, not the solution. Adding a non-standard and frankly rather crappy VPN is not going to magically take the dreaded microsoft away. Nice work with the "M$" nonsense though, I'm sure all of slashdot is proud of you. Adam
Re: ipsec vpn
Original message >Date: Tue, 7 Nov 2006 22:57:23 -0500 >From: Adam <[EMAIL PROTECTED]> >Subject: Re: ipsec vpn >To: [EMAIL PROTECTED] >Cc: misc@openbsd.org > >Jacob Yocom-Piatt <[EMAIL PROTECTED]> wrote: > >> > >> >> M$ is notoriously crappy when it comes to VPN software, IMO. openvpn is probably >> > >> >I really wish people would stop advocating this garbage on our mailing >> >lists. >> > >> >> i really wish people wouldn't be such pricks on misc@ ... > >So stop then. > <-A--> The Ouroboros of Adam Montague the trollmaster has emerged from under his pathetic bridge to again extort his toll with senseless passive aggression. "what is it this time?" asks the usually reasonable traveller of the wretched viaduct lurker. "it's like the time i flipped out about ruby on rails, when i couldn't STFU because it's unacceptable to me that anybody could possibly use solution X when solution Y works best for me. that means it is the best!" howled the troll. the traveller was confused for a moment then continued "different people find different solutions to the same problem, like schwinger and feynman, but to deny that they are both solutions is absurd". >> given a completely free hand, i would NEVER use windows machines for anything >> remotely important. however, i have been forced to interoperate with M$ users >> who could not get the "native" IPsec to work to their satisfaction and >> openvpn >> is a viable solution in this case. > >No, its avoiding the problem, not solving it. If you like openvpn that's >up to you. But its not a solution to getting ipsec between openbsd and >windows, and it is annoying to see it constantly offered here. > the fetid garbage-eating beast paused in thought for a moment and the traveller knew this was his moment to escape before the troll would tear him limb from limb for his insolence. he screamed and pointed behind the troll "oh my god, is that ruby on rails?!?" driving the beast into a rage. immediately thereafter the wayfarer slipped by sans toll. >> a solution involving M$, is IMO no solution at all, merely another example of >> turd polishing. since many peoples' brains are too limited in their >> flexibility, >> turd polishing is a painful reality when dealing with diverse computer users. > >The problem involves microsoft, not the solution. Adding a non-standard >and frankly rather crappy VPN is not going to magically take the dreaded >microsoft away. Nice work with the "M$" nonsense though, I'm sure all >of slashdot is proud of you. > the traveller thought he had escaped and made camp well away from where he had evaded the trollmaster. exhausted from the day's journey, he drifted to sleep after a few puffs from his pipe in front of the fire. he awoke in a panic and heard the leaves rustling entirely too close to his head. a roar accompanied the sensation of something gripping his face, one slimy hand squeezing his mouth open, the other pulling something out of the troll's purple velvet evening handbag. the traveller went into shock, felt small flat objects enter his mouth and the beast laughed heartily. "how do you like that, eh?" asked the troll. the traveller spat and he saw those little magnetic words that people have on their refrigerators come out of his mouth. "you put words in my mouth?" queried the man and the monster replied "you betcha!". once he safely arrived in a nearby town after this harrowing experience the wayfarer whipped up a posse to chase down and kill the twisted extortionist. in no time they found the unapologetic ignorant troll and cut him limb from limb with their sharp blades. the monster was reduced to a twitching mess of body parts, but those of us who played D&D know that trolls regenerate and will likely be really annoying all over again. >Adam feel free to cut this out, making sure to paste or tape the <--A--> sections together. do NOT make a twist since that could possibly imply that there is indeed only one side to this story. <-A-->
Re: ipsec vpn
Jacob Yocom-Piatt <[EMAIL PROTECTED]> wrote: -snip the high school creative writing assignment- Let's see, you show up to answer an ipsec question by advocating openvpn instead. Then you decide to tell openbsd developers how they should be acting on their mailing list. You even use 'M$' and dismiss anyone who disagrees with you as a troll since you can't actually argue a point. Who exactly is the troll again? Adam
Re: ipsec vpn
On 11/8/06, Adam <[EMAIL PROTECTED]> wrote: Jacob Yocom-Piatt <[EMAIL PROTECTED]> wrote: -snip the high school creative writing assignment- Let's see, you show up to answer an ipsec question by advocating openvpn instead. Then you decide to tell openbsd developers how they should be acting on their mailing list. You even use 'M$' and dismiss anyone who disagrees with you as a troll since you can't actually argue a point. Who exactly is the troll again? Adam Sniip Can we try to get back on track with the thread please. I think there are quite a few people out there who would benefit from some useful information on a typical vpn configuration with windows clients. Does anyone have an ipsec.conf example with correct transform set to allow dynamic windows clients to connect to an OpenBSD vpn gateway using pre-shared key? The old way works fine but the ipsec.conf appears alot cleaner to configure. Thanks. -mb
Re: ipsec vpn
Matt Bettinger wrote: On 11/8/06, Adam <[EMAIL PROTECTED]> wrote: Jacob Yocom-Piatt <[EMAIL PROTECTED]> wrote: -snip the high school creative writing assignment- Let's see, you show up to answer an ipsec question by advocating openvpn instead. Then you decide to tell openbsd developers how they should be acting on their mailing list. You even use 'M$' and dismiss anyone who disagrees with you as a troll since you can't actually argue a point. Who exactly is the troll again? Adam Sniip Can we try to get back on track with the thread please. I think there are quite a few people out there who would benefit from some useful information on a typical vpn configuration with windows clients. Does anyone have an ipsec.conf example with correct transform set to allow dynamic windows clients to connect to an OpenBSD vpn gateway using pre-shared key? The old way works fine but the ipsec.conf appears alot cleaner to configure. Thanks. -mb I'm using the following in ipsec.conf (test-enviroment): ike passive esp tunnel from any to any \ main auth hmac-md5 enc des group modp768 \ quick auth hmac-md5 enc des group modp768 \ psk 01234 Maybe this will work for you...
Re: ipsec vpn
On Wed, Nov 01, 2006 at 05:49:18PM -0800, Bryan Irvine wrote: > I'm going to upgrading a couple of our firewalls soon and as part of > the upgrade I will be implementing VPN between a couple of our sites. > > Does this page still apply: http://www.securityfocus.com/infocus/1859 Yes, although some additions have been made since (notably, AH works too). > Any pitfalls or changes I should watch out for? Filtering IPsec traffic might take some experimentation to get right. > These firewall are running CARP. Don't forget sasyncd; it has gotten *much* better in 4.0. Joachim
Re: ipsec vpn problem
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? Thanks, Claus Larsen http://www.b1d.dk/ 164658.880563 Misc 30 ipsec_responder: phase 2 exchange 32 step 0 164658.881355 Negt 90 responder_recv_HASH_SA_NONCE: SKEYID_a: 164658.882267 Negt 90 fecb16b4 55016a69 95160d35 590ae43d eaecf61d 164658.883141 Cryp 60 hash_get: requested algorithm 1 164658.883965 Negt 90 responder_recv_HASH_SA_NONCE: message_id: 164658.884696 Negt 90 641b5b02 164658.885452 Negt 90 responder_recv_HASH_SA_NONCE: message after HASH: 164658.886559 Negt 90 0a34 0001 0001 0028 01030401 348b8f08 001c 010c 164658.887588 Negt 90 80010001 80020e10 80040001 80050002 80060080 0514 f18a9d3e a98adb02 164658.888617 Negt 90 4d48e019 d94e78b7 050c 0100 d5ade2e5 000c 0100 c0a80102 164658.889523 Negt 90 responder_recv_HASH_SA_NONCE: computed HASH(1): 164658.890440 Negt 90 1db4eb09 c20acc1d 9ff7f66f bce87d93 dc00b62b 164658.891233 Negt 90 responder_recv_HASH_SA_NONCE: IDci: 164658.892172 Negt 90 0100 d5ade2e5 164658.892842 Negt 90 responder_recv_HASH_SA_NONCE: IDcr: 164658.893657 Negt 90 0100 c0a80102 164658.894437 Negt 30 message_negotiate_sa: transform 1 proto 3 proposal 1 ok 164658.895376 SA 80 sa_add_transform: proto 0x83b5e6c0 no 1 proto 3 chosen 0x7fb51300 sa 0x80ac0b00 id 12 164658.896080 Negt 30 message_negotiate_sa: proposal 1 succeeded 164658.896865 Misc 20 ipsec_decode_transform: transform 1 chosen 164658.897674 Exch 80 exchange_nonce: NONCE_i: 164658.898662 Exch 80 f18a9d3e a98adb02 4d48e019 d94e78b7 164658.899367 Misc 60 connection_passive_lookup_by_ids: no match 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 164658.902191 Misc 95 conf_get_str: [General]:Exchange-max-time->120 164658.903025 Timr 10 timer_add_event: event exchange_free_aux(0x80ac0c00) added before sa_soft_expire(0x8a788200), expiration in 120s 164658.903887 Exch 10 exchange_establish_p2: 0x80ac0c00 policy initiator phase 2 doi 1 exchange 5 step 0 164658.904750 Exch 10 exchange_establish_p2: icookie 2dbf0119d00d6f5f rcookie 7a1f5aefc435e4d8 164658.905560 Exch 10 exchange_establish_p2: msgid 8c6588fb sa_list 164658.906355 Trpt 95 transport_reference: transport 0x83b5e140 now has 4 references 164658.907188 Mesg 90 message_alloc: allocated 0x7ea80700 164658.907983 SA 80 sa_reference: SA 0x8a788200 now has 7 references 164658.908918 Cryp 60 hash_get: requested algorithm 1 164658.909617 Cryp 60 hash_get: requested algorithm 1 164658.910390 Misc 90 ipsec_fill_in_hash: SKEYID_a: 164658.911301 Misc 90 fecb16b4 55016a69 95160d35 590ae43d eaecf61d 164658.912076 Cryp 60 hash_get: requested algorithm 1 164658.912890 Misc 90 ipsec_fill_in_hash: message_id: 164658.913682 Misc 90 8c6588fb 164658.914450 Misc 90 ipsec_fill_in_hash: payload 1 after HASH(1): 164658.915433 Misc 90 000c 0001 010e 164658.916208 Misc 80 ipsec_fill_in_hash: HASH(1): 164658.917241 Misc 80 44bd700e c8f21689 4ed4cbc4 dd3d8b6d 1e90b35f 164658.917905 Exch 90 exchange_validate: checking for required INFO 164658.919294 Cryp 60 hash_get: requested algorithm 1 164658.919988 Cryp 80 ipsec_get_keystate: final phase 1 IV: 164658.920958 Cryp 80 360a61e7 3cb364b9 b04826a0 8e0e7e8a 164658.921607 Cryp 80 ipsec_get_keystate: message ID: 164658.922385 Cryp 80 8c6588fb On Thu, Aug 21, 2008 at 4:17 PM, Claus Larsen <[EMAIL PROTECTED]> wrote: > 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
Re: ipsec vpn problem
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
Re: ipsec vpn 'colouring'
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
Re: IPSEC VPN performance
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 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
On Thu, Sep 27, 2012 at 11:30 PM, 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 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
On Fri, Sep 28, 2012 at 11:45 AM, Otto Moerbeek 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 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
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
Sorry I was stingy on the dmesg output. Here's the full dump. I will
test with other AES modes now.
-Jim
OpenBSD 5.1 (GENERIC.MP) #188: Sun Feb 12 09:55:11 MST 2012
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
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
real mem = 2119032832 (2020MB)
avail mem = 2074247168 (1978MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/22/11, SMBIOS rev. 2.7 @
0xeb4c0 (54 entries)
bios0: vendor American Megatrends Inc. version "2.00" date 05/08/2012
bios0: Supermicro X9SCI/X9SCA
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG PRAD HPET SSDT SPMI SSDT SSDT
SPCR EINJ ERST HEST BERT
acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) P0P1(S4)
USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4)
RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4)
RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4)
PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S4) EHC2(S4) HDEF(S4)
PWRB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz ("GenuineIntel" 686-class)
3.10 GHz
cpu1:
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
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz ("GenuineIntel" 686-class)
3.10 GHz
cpu2:
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
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz ("GenuineIntel" 686-class)
3.10 GHz
cpu3:
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
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 6 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpiprt6 at acpi0: bus 2 (RP05)
acpiprt7 at acpi0: bus 3 (RP06)
acpiprt8 at acpi0: bus 4 (RP07)
acpiprt9 at acpi0: bus 5 (RP08)
acpiprt10 at acpi0: bus -1 (PEG0)
acpiprt11 at acpi0: bus -1 (PEG1)
acpiprt12 at acpi0: bus -1 (PEG2)
acpiprt13 at acpi0: bus -1 (PEG3)
acpiec0 at acpi0: Failed to read resource settings
acpicpu0 at acpi0: C3, C1, PSS
acpicpu1 at acpi0: C3, C1, PSS
acpicpu2 at acpi0: C3, C1, PSS
acpicpu3 at acpi0: C3, C1, PSS
acpipwrres0 at acpi0: FN00
acpipwrres1 at acpi0: FN01
acpipwrres2 at acpi0: FN02
acpipwrres3 at acpi0: FN03
acpipwrres4 at acpi0: FN04
acpitz0 at acpi0: critical temperature is 95 degC
acpitz1 at acpi0: critical temperature is 95 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xc9000/0x1000
0xca000/0x1000 0xcb000/0x1000
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 3093 MHz: speeds: 3101, 3100, 3000, 2900, 2800,
2700, 2600, 2500, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 Host" rev 0x09
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
vendor "Intel", unknown product 0x1c3b (class communications subclass
miscellaneous, rev 0x04) at pci0 dev 22 function 1 not configured
ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 2 int 16
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5: apic 2 int 16
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 "Intel 6 Series PCIE" rev 0xb5: apic 2 int 16
pci2 at ppb1 bus 2
em0 at pci2 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 p
Re: IPSEC VPN performance
On Fri, Sep 28, 2012 at 08:38:37AM -0400, Jim Miller wrote:
> Sorry I was stingy on the dmesg output. Here's the full dump. I will
> test with other AES modes now.
And then install amd64 ;-)
-Otto
>
> -Jim
>
>
> OpenBSD 5.1 (GENERIC.MP) #188: Sun Feb 12 09:55:11 MST 2012
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> 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
> real mem = 2119032832 (2020MB)
> avail mem = 2074247168 (1978MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 12/22/11, SMBIOS rev. 2.7 @
> 0xeb4c0 (54 entries)
> bios0: vendor American Megatrends Inc. version "2.00" date 05/08/2012
> bios0: Supermicro X9SCI/X9SCA
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S1 S4 S5
> acpi0: tables DSDT FACP APIC FPDT MCFG PRAD HPET SSDT SPMI SSDT SSDT
> SPCR EINJ ERST HEST BERT
> acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) P0P1(S4)
> USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4)
> RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4)
> RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4)
> PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S4) EHC2(S4) HDEF(S4)
> PWRB(S4)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: apic clock running at 99MHz
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz ("GenuineIntel" 686-class)
> 3.10 GHz
> cpu1:
> 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
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz ("GenuineIntel" 686-class)
> 3.10 GHz
> cpu2:
> 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
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz ("GenuineIntel" 686-class)
> 3.10 GHz
> cpu3:
> 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
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
> acpimcfg0 at acpi0 addr 0xf800, bus 0-63
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 6 (P0P1)
> acpiprt2 at acpi0: bus 1 (RP01)
> acpiprt3 at acpi0: bus -1 (RP02)
> acpiprt4 at acpi0: bus -1 (RP03)
> acpiprt5 at acpi0: bus -1 (RP04)
> acpiprt6 at acpi0: bus 2 (RP05)
> acpiprt7 at acpi0: bus 3 (RP06)
> acpiprt8 at acpi0: bus 4 (RP07)
> acpiprt9 at acpi0: bus 5 (RP08)
> acpiprt10 at acpi0: bus -1 (PEG0)
> acpiprt11 at acpi0: bus -1 (PEG1)
> acpiprt12 at acpi0: bus -1 (PEG2)
> acpiprt13 at acpi0: bus -1 (PEG3)
> acpiec0 at acpi0: Failed to read resource settings
> acpicpu0 at acpi0: C3, C1, PSS
> acpicpu1 at acpi0: C3, C1, PSS
> acpicpu2 at acpi0: C3, C1, PSS
> acpicpu3 at acpi0: C3, C1, PSS
> acpipwrres0 at acpi0: FN00
> acpipwrres1 at acpi0: FN01
> acpipwrres2 at acpi0: FN02
> acpipwrres3 at acpi0: FN03
> acpipwrres4 at acpi0: FN04
> acpitz0 at acpi0: critical temperature is 95 degC
> acpitz1 at acpi0: critical temperature is 95 degC
> acpibat0 at acpi0: BAT0 not present
> acpibat1 at acpi0: BAT1 not present
> acpibat2 at acpi0: BAT2 not present
> acpibtn0 at acpi0: PWRB
> acpibtn1 at acpi0: LID0
> acpivideo0 at acpi0: GFX0
> acpivout0 at acpivideo0: DD02
> bios0: ROM list: 0xc/0x8000 0xc8000/0x1000 0xc9000/0x1000
> 0xca000/0x1000 0xcb000/0x1000
> ipmi at mainbus0 not configured
> cpu0: Enhanced SpeedStep 3093 MHz: speeds: 3101, 3100, 3000, 2900, 2800,
> 2700, 2600, 2500, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600 MHz
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 Host" rev 0x09
> "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
> vendor "Intel", unknown product 0x1c3b (class communications subclass
> miscellaneous, rev 0x04) at pci0 dev 22 function 1 not configured
> ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 2 int 16
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5: apic 2 int 16
> pci1 at
Re: IPSEC VPN performance
Good catch. I've since upgraded to the amd64 kernel. See the below dmesg. The performance jumped from 40mbps to approx. 70mbps. This is obviously a significant jump. I've tried switching the childsa from aes-256-gmac, aes-256-gcm, aes-128 and the times are fairly constant. I assume the AES-NI instructions are being used by the processor but I don't know for sure. Ideally I'd like to see if I could get performance up on par with a Cisco ASA 5505. I've had those devices with the same test hit 90mbps. Any ideas? Thanks everyone Jim OpenBSD 5.1 (GENERIC.MP) #207: Sun Feb 12 09:42:14 MST 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2118471680 (2020MB) avail mem = 2047971328 (1953MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb4c0 (54 entries) bios0: vendor American Megatrends Inc. version "2.00" date 05/08/2012 bios0: Supermicro X9SCI/X9SCA acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG PRAD HPET SSDT SPMI SSDT SSDT SPCR EINJ ERST HEST BERT acpi0: wakeup devices PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) P0P1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) RP08(S4) PEGP(S4) PEG0(S4) PEG1(S4) PEG2(S4) PEG3(S4) GLAN(S4) EHC1(S4) EHC2(S4) HDEF(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz, 3093.40 MHz cpu0: FPU,VME,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,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz, 3092.98 MHz cpu1: FPU,VME,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,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz, 3092.98 MHz cpu2: FPU,VME,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,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E31220 @ 3.10GHz, 3092.98 MHz cpu3: FPU,VME,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,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF cpu3: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 6 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus 2 (RP05) acpiprt7 at acpi0: bus 3 (RP06) acpiprt8 at acpi0: bus 4 (RP07) acpiprt9 at acpi0: bus 5 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0: Failed to read resource settings acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: FN00 acpipwrres1 at acpi0: FN01 acpipwrres2 at acpi0: FN02 acpipwrres3 at acpi0: FN03 acpipwrres4 at acpi0: FN04 acpitz0 at acpi0: critical temperature is 95 degC acpitz1 at acpi0: critical temperature is 95 degC acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID0 acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD02 ipmi at mainbus0 not configured cpu0: Enhanced SpeedStep 3092 MHz: speeds: 3101, 3100, 3000, 2900, 2800, 2700, 2600, 2500, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Xeon E3-1200 Host" rev 0x09 "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured vendor "Intel", unknown product 0x1c3b (class communications subclass miscellaneous, rev 0x04) at pci0 dev 22 function 1 not configured ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE"
Re: IPSEC VPN performance
Jim Miller 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 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
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 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 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
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
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
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-misc&m=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
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-misc&m=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
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-misc&m=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
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" : > 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-misc&m=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
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
On Mon, Oct 1, 2012 at 5:55 PM, Russell Garrison 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
On 2 October 2012 08:57, David Coppa wrote: > On Mon, Oct 1, 2012 at 5:55 PM, Russell Garrison > 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
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-misc&m=134033767126930, I tested with tcpbench -B 262144 -S 262144 -n 10
Re: IPSEC VPN performance
On Tue, Oct 2, 2012 at 9:59 AM, 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, 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 configuration issues
On 04/05/06, Nathan Johnson <[EMAIL PROTECTED]> wrote: > > I have two OpenBSD nat / router machines and I am trying to > successfully get a vpn going between the two. OpenBSD box A is > OpenBSD 3.9 , with internal network 192.168.0.0/24 and external > address 1.2.3.4 (or something like that). OpenBSD box B is OpenBSD > 3.8, with internal network 192.168.51.0/24 and external address > 4.3.2.1 . So far I have followed the instructions in man vpn(8) , and > have partially succeeded in configuring a vpn between the two using > manual keys / ipsecctl / ipsec.conf method. My ipsec.conf from > gateway A is: > > flow esp from 192.168.0.0/24 to 192.168.51.0/24 peer 4.3.2.1 > esp from 1.2.3.4 to 4.3.2.1 spi 0x80081355:0x13558008 auth > hmac-sha2-512 enc 3des-cbc authkey file > "/etc/ipsec/auth_key.puffy:/etc/ipsec/auth_key.uptowns" enckey file > "/etc/ipsec/enc_key.puffy:/etc/ipsec/enc_key.uptowns" > > > and my ipsec.conf from gateway B is: > > flow esp from 192.168.51.0/24 to 192.168.0.0/24 peer 1.2.3.4 > esp from 4.3.2.1 to 1.2.3.4 spi 0x13558008:0x80081355 auth > hmac-sha2-512 enc 3des-cbc authkey file > "/etc/ipsec/auth_key.uptowns:/etc/ipsec/auth_key.puffy" enckey file > "/etc/ipsec/enc_key.uptowns:/etc/ipsec/enc_key.puffy" > > my pf.conf on both boxes is configured in a manner similar to the > described scenario in the vpn man page. > > when I issue the following from gateway A: > > ping -I 192.168.0.1 192.168.51.1 > > pings are successful, and when I do a tcpdump on the esp interface it > does indeed appear to be traversing the esp interface. > > The problem is when I try to ping any machine from network A to > 192.168.51.0/24 (gateway B's internal network) besides the gateway > itsself (192.168.51.1), ping doesn't work. Same is true for pinging > from network B to 192.168.0.0/24 , excepting gateway A itsself, and > only then from the gateway B machine. So basically, ipsec / vpn > appears to be working, but for some reason traffic from other hosts > behinds these gateways isn't being forwarded. Where should I begin to > look for the problems? I have pf set to log anything blocked , and > looking at pflog doesn't show any relevant traffic being blocked. NAT > is being used on both of these gateways, and all boxes inside each > respective gateway are able to reach the internet without problems. > > Thanks in advance > Nathan Johnson > > Did you enable ip forwarding, Nate ? /Tony -- Tony Sarendal - [EMAIL PROTECTED] IP/Unix -= The scorpion replied, "I couldn't help it, it's my nature" =-
Re: IPsec / vpn configuration issues
On Thu, May 04, 2006 at 12:31:28PM -0500, Nathan Johnson wrote: ... > The problem is when I try to ping any machine from network A to > 192.168.51.0/24 (gateway B's internal network) besides the gateway > itsself (192.168.51.1), ping doesn't work. what does "doesn't" work mean? Do you see the icmp-echo-request on the target machine? Like: ping from 192.168.0.2 to 192.168.51.2, does the ping show up at 192.168.51.2? Does 192.168.51.2 send the reply? etc.
Re: Ipsec VPN and NAT
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 MuE>eniD
/ 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) :
>>
Re: ipsec vpn unexpected flow
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 wrote: From: Andrea Parazzini 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
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 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 > wrote: > > From: Andrea Parazzini > 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
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 > 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 > > wrote: > > > > From: Andrea Parazzini > > 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
Re: ipsec vpn unexpected flow
On Fri, 26 Nov 2010 10:32:59 +0330, Bahador NazariFard 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 >> 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 >> > wrote: >> > >> > From: Andrea Parazzini >> > 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
On 2010-11-25, Andrea Parazzini 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
On Fri, 26 Nov 2010 12:58:09 + (UTC), Stuart Henderson wrote: > On 2010-11-25, Andrea Parazzini 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
Re: ipsec vpn unexpected flow
On Thu, 11/25/10, Andrea Parazzini 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> 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
On 2010/11/27 23:47, Andrea Parazzini wrote: > On Fri, 26 Nov 2010 12:58:09 + (UTC), Stuart Henderson> > 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: freebsd and openbsd
"ipsec between freebsd and openbsd" didn't turn up anything on Google directly related to what you seem to want to do (at least for me), so I guess you'll have to look at the FreeBSD side of things: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html http://www.onlamp.com/pub/a/bsd/2002/12/26/FreeBSD_Basics.html They seem to mention the use of the gif(4) interface a lot for VPNs between two FreeBSD machines, but I believe you can still make a FreeBSD VPN without it, so I think you'll want to forgo its use if you'll be connecting to an OpenBSD box. I've done FreeBSD <--> FreeBSD and OpenBSD <--> OpenBSD VPNs in the past, but I don't recall ever doing FreeBSD <--> OpenBSD. After seeing how easy it seems to be to make an IPsec VPN using OpenBSD's 'ipsecctl' from the article you mention, I'm guessing the harder part will be the configuration of the FreeBSD side with Racoon, setkey and such. Good luck, -Martin On 10/2/06, kintaro oe <[EMAIL PROTECTED]> wrote: Hi guys, I'm setting up ipsec/vpn on freebsd and openbsd. I try to read this how to http://www.securityfocus.com/infocus/1859 but this applies to 2 openbsd systems. could anyone help me on how to setup between two systems? -- "What the world needs is more geniuses with humility; there are so few of us left." -- Oscar Levant
Re: ipsec vpn: freebsd and openbsd
kintaro oe wrote: > I'm setting up ipsec/vpn on freebsd and openbsd. I try to read > this how to http://www.securityfocus.com/infocus/1859 but this > applies to 2 openbsd systems. could anyone help me on how to > setup between two systems? Perhaps OpenVPN is a good alternative? I wrote a setupscript for OpenVPN: http://www.xs4all.nl/~hanb/software/braindead-rsa/ # Han
Re: ipsec vpn: freebsd and openbsd
I agree with you Han. If Kintaro finds that configuring an IPsec VPN between a FreeBSD and an OpenBSD machine is too complicated, OpenVPN installed on both machines may offer an easier alternative. -Martin On 10/2/06, Han Boetes <[EMAIL PROTECTED]> wrote: kintaro oe wrote: > I'm setting up ipsec/vpn on freebsd and openbsd. I try to read > this how to http://www.securityfocus.com/infocus/1859 but this > applies to 2 openbsd systems. could anyone help me on how to > setup between two systems? Perhaps OpenVPN is a good alternative? I wrote a setupscript for OpenVPN: http://www.xs4all.nl/~hanb/software/braindead-rsa/ -- "What the world needs is more geniuses with humility; there are so few of us left." -- Oscar Levant
Re: ipsec vpn: freebsd and openbsd
hey guys, thanks a lot of the advice. hh..It seems the alternative is openvpn..but whats the difference between them (openvpn and ipsec)?both are secure..but dont know the reliability and stability. any advice then? thanks! cheers, kintaro0e - Original Message From: Martin Gignac <[EMAIL PROTECTED]> To: misc@openbsd.org Sent: Tuesday, October 3, 2006 12:26:39 PM Subject: Re: ipsec vpn: freebsd and openbsd I agree with you Han. If Kintaro finds that configuring an IPsec VPN between a FreeBSD and an OpenBSD machine is too complicated, OpenVPN installed on both machines may offer an easier alternative. -Martin On 10/2/06, Han Boetes <[EMAIL PROTECTED]> wrote: > kintaro oe wrote: > > I'm setting up ipsec/vpn on freebsd and openbsd. I try to read > > this how to http://www.securityfocus.com/infocus/1859 but this > > applies to 2 openbsd systems. could anyone help me on how to > > setup between two systems? > > Perhaps OpenVPN is a good alternative? > > I wrote a setupscript for OpenVPN: > http://www.xs4all.nl/~hanb/software/braindead-rsa/ -- "What the world needs is more geniuses with humility; there are so few of us left." -- Oscar Levant
Re: ipsec vpn: freebsd and openbsd
IPsec is based on standards (RFCs) while OpenVPN is not (it is based on "standard" SSL, though). I guess the best way to make your mind up is to actually go to the OpenVPN web site (http://openvpn.net/) and read up on it. There's some good info there. Also, a visit on Google with keywords "openvpn ipsec comparison" or "openvpn vs ipsec" should return some good info. Both approaches achieve the same goal (a secure, tunneled VPN) in quite different ways. In the past I have found OpenVPN to be quite easy to use when setting up machines with different OSes at both ends (I've done Linux <--> FreeBSD and Windows <--> FreeBSD VPNs with OpenVPN). I would say that one of the advantages of OpenVPN over IPsec when using different OSes is that configuration is pretty much identical (or at least close to it) independent of the OS you're using, so if you're planning to make many VPNs between all kinds of OSes it could be a good alternative. Read up on it and decide for yourself. I find it to be quite an interesting product. On 10/3/06, kintaro oe <[EMAIL PROTECTED]> wrote: hey guys, thanks a lot of the advice. hh..It seems the alternative is openvpn..but whats the difference between them (openvpn and ipsec)?both are secure..but dont know the reliability and stability. any advice then? thanks! cheers, -Martin -- "Suburbia is where the developer bulldozes out the trees, then names the streets after them." --Bill Vaughan
Re: ipsec vpn: freebsd and openbsd
hi martin, thanks a lot for your advice..maybe this is the best alternative at all. cool! bsd rocks! cheers, kintaro0e - Original Message From: Martin Gignac <[EMAIL PROTECTED]> To: kintaro oe <[EMAIL PROTECTED]> Cc: misc@openbsd.org Sent: Tuesday, October 3, 2006 9:18:34 PM Subject: Re: ipsec vpn: freebsd and openbsd IPsec is based on standards (RFCs) while OpenVPN is not (it is based on "standard" SSL, though). I guess the best way to make your mind up is to actually go to the OpenVPN web site (http://openvpn.net/) and read up on it. There's some good info there. Also, a visit on Google with keywords "openvpn ipsec comparison" or "openvpn vs ipsec" should return some good info. Both approaches achieve the same goal (a secure, tunneled VPN) in quite different ways. In the past I have found OpenVPN to be quite easy to use when setting up machines with different OSes at both ends (I've done Linux <--> FreeBSD and Windows <--> FreeBSD VPNs with OpenVPN). I would say that one of the advantages of OpenVPN over IPsec when using different OSes is that configuration is pretty much identical (or at least close to it) independent of the OS you're using, so if you're planning to make many VPNs between all kinds of OSes it could be a good alternative. Read up on it and decide for yourself. I find it to be quite an interesting product. On 10/3/06, kintaro oe <[EMAIL PROTECTED]> wrote: > hey guys, > > thanks a lot of the advice. hh..It seems the alternative is > openvpn..but whats the difference between them (openvpn and ipsec)?both are > secure..but dont know the reliability and stability. any advice then? thanks! > cheers, -Martin -- "Suburbia is where the developer bulldozes out the trees, then names the streets after them." --Bill Vaughan
Re: ipsec vpn: freebsd and openbsd
On Wed, Oct 04, 2006 at 11:04:55PM -0700, Stephen J. Bevan wrote: > > Type "man vpn" on your OpenBSD box and read the section on > "Configuring the Keying Daemon [automated keying]". That explains the > gory details that ipsecctl and ipsec.conf deliberately hide from you. > (sorry for taking your post slightly out of context...) vpn.8 is no longer around...i urge people to read ipsec.conf(5) and isakmpd(8) for setting up their ipsec stuff. if there's problems in the docs, it's these pages that need feedback on, not vpn(8). jmc
Re: ipsec vpn: freebsd and openbsd
As always, make sure to subscribe to the 'ports-security' mailing list, follow the stable ports tress, or at least visit http://www.openbsd.org/pkg-stable.html once in a while to make sure you've got the latest version (i.e. version with the most security issues fixed) of the OpenVPN package installed. For example, OpenBSD 3.9 shipped with OpenVPN 2.0.5, but later version 2.0.6 came out to address security issues, so a new OpenBSD package for OpenVPN was created and released. By the way, you may see on the OpenVPN website that version 2.0.8 is now out, but bear in mind that 2.0.7 and 2.0.8 only address Windows-centric security issues, so there was no need to release these versions as OpenBSD packages. -Martin -- "Suburbia is where the developer bulldozes out the trees, then names the streets after them." --Bill Vaughan
Re: ipsec vpn: freebsd and openbsd
2006/10/4, Martin Gignac <[EMAIL PROTECTED]>: As always, make sure to subscribe to the 'ports-security' mailing list, follow the stable ports tress, or at least visit Should I take the silence of the list as evidence that all ports are secure or is the list simply ignored by the developers? Or is it only used in dire emergencies (like security-announce)? Best Martin
Re: ipsec vpn: freebsd and openbsd
On Thu, Oct 05, 2006 at 03:47:07PM +0200, Martin Schr"oder wrote:
> Should I take the silence of the list as evidence that all ports
> are secure or is the list simply ignored by the developers? Or is
> it only used in dire emergencies (like security-announce)?
The list just hasn't been used in a while. It could be seen as
redundant effort, since ports-changes@ receives messages for each
commit to the ports tree (including security-related commits), and
pkg-stable.html is updated rather frequently.
This issue has come up on #OpenBSD on freenode a few times recently,
too. Would it be a good idea to update the FAQ to point to
pkg-stable.html and [EMAIL PROTECTED] Or would it be preferable to
make use of that list again (in conjunction, perhaps, with updates
to the VuXML)?
--
o--{ Will Maier }--o
| web:...http://www.lfod.us/ | [EMAIL PROTECTED] |
*--[ BSD Unix: Live Free or Die ]--*
Re: ipsec vpn: freebsd and openbsd
2006/10/5, Will Maier <[EMAIL PROTECTED]>: This issue has come up on #OpenBSD on freenode a few times recently, too. Would it be a good idea to update the FAQ to point to pkg-stable.html and [EMAIL PROTECTED] Or would it be preferable to make use of that list again (in conjunction, perhaps, with updates to the VuXML)? Use the list. security fixes on ports-changes get lost in the noise. Otherwise remove the list. Best Martin
Re: ipsec vpn: freebsd and openbsd
Jason McIntyre wrote: On Wed, Oct 04, 2006 at 11:04:55PM -0700, Stephen J. Bevan wrote: Type "man vpn" on your OpenBSD box and read the section on "Configuring the Keying Daemon [automated keying]". That explains the gory details that ipsecctl and ipsec.conf deliberately hide from you. (sorry for taking your post slightly out of context...) vpn.8 is no longer around...i urge people to read ipsec.conf(5) and isakmpd(8) for setting up their ipsec stuff. if there's problems in the docs, it's these pages that need feedback on, not vpn(8). jmc Good to know. I too have been using vpn(8) for reference. It's still in my 3.9-STABLE.
Re: IPSec VPN with iked (8)
On 2013-11-25, Benjamin Epitech 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=displayarticle&id=67
Re: IPSec VPN with iked (8)
On Mon, Nov 25, 2013 at 1:21 PM, Stuart Henderson wrote: > 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.
Re: IPSec VPN with iked (8)
There is a post of my findings in the archives. Android 2.3 worked fine with iked and npppd
Re: ipsec vpn with os x clients
Hi,
On Thu, Jul 12, 2007 at 05:38:47PM -0800, eric wrote:
> I have an OpenBSD 4.1 (OpenBSD 4.1 GENERIC#1435 i386) acting
> as a PPPoE NAT router & firewall to my ISP. I'd like to replace my OS
> X 10.4 Server IPSEC VPN with the OpenBSD system. My "road warrior"
> clients are all OS X 10.4.10. I read that 10.4 supports AES
> encryption but advertises 3DES by default. I'm happy to use 3DES for
> now, as isakmpd reported proposal errors when i configured for AES.
>
> Much of the (excellent) IPsec documentation refers either to site-to-
> site configuration and not road warrior clients or is outdated and
> refers to isakmpd.conf
>
> # cat ipsec.conf
> ike dynamic from any to any \
> main auth hmac-sha1 enc 3des group modp1024 \
> quick auth hmac-sha1 enc 3des psk TheSecret
>
this should be "ike passive from ..."
> I start isakmpd with 'isakmpd -K4dv'
>
> I load ipsec.conf with 'ipsecctl -f /etc/ipsec.conf'
>
> I then monitor key exchanges with 'ipsecctl -m'
>
> Once i load ipsec.conf I get the following from isakmpd, repeating
> every 25secs or so:
> 171653.48 Default udp_create: no address configured for "peer-
> default"
> 171653.422357 Default exchange_establish: transport "udp" for peer
> "peer-default" could not be created
>
> I'm testing this entirely from my internal subnet. PF is configured
> to 'pass quick on { $int_if enc0 }'
>
> My OS X VPN client setup includes the OpenBSD server's IP, my OpenBSD
> username and password, and the PSK. I click Connect.
>
> isakmpd reports:
> 172358.016652 Default isakmpd: phase 1 done: initiator id ac1e0114:
> 172.30.1.20, responder id , src: 172.30.1.1 dst:
> 172.30.1.20
> 172430.679924 Default message_recv: invalid cookie(s)
> bacca5c8db12e3b9 78c4c4508b02cbe4
> 172430.680286 Default dropped message from 172.30.1.20 port 500 due
> to notification type INVALID_COOKIE
> 172430.680826 Default message_recv: invalid cookie(s)
> bacca5c8db12e3b9 a162b17df4ce9921
> 172430.681041 Default dropped message from 172.30.1.20 port 500 due
> to notification type INVALID_COOKIE
>
> The INVALID_COOKIE messages repeat until the Mac gives up or I
> cancel. Then I get:
>
> 172450.699914 Default transport_send_messages: giving up on exchange
> IPsec-0.0.0.0/0-0.0.0.0/0, no response from peer 172.30.1.20:500
> 172450.700387 Default transport_send_messages: giving up on exchange
> IPsec-::/0-::/0, no response from peer 172.30.1.20:500
>
> ipsecctl -m reports this:
>
> sadb_getspi: satype esp vers 2 len 10 seq 1 pid 15108
> address_src: 172.30.1.20
> address_dst: 172.30.1.1
> spirange: min 0x0100 max 0x
> sadb_getspi: satype esp vers 2 len 10 seq 1 pid 15108
> sa: spi 0x272f2a24 auth none enc none
> state mature replay 0 flags 0
> address_src: 172.30.1.20
> address_dst: 172.30.1.1
> sadb_getspi: satype esp vers 2 len 10 seq 2 pid 15108
> address_src: 172.30.1.20
> address_dst: 172.30.1.1
> spirange: min 0x0100 max 0x
> sadb_getspi: satype esp vers 2 len 10 seq 2 pid 15108
> sa: spi 0xee7e7297 auth none enc none
> state mature replay 0 flags 0
> address_src: 172.30.1.20
> address_dst: 172.30.1.1
>
> Does anybody have any documentation on using Mac clients with IPSEC?
>
> I sincerely appreciate any assistance and am willing to provide any
> additional requested information. Thank you.
Re: ipsec vpn with os x clients
> # cat ipsec.conf > ike dynamic from any to any \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha1 enc 3des psk TheSecret > this should be "ike passive from ..." roger that... # cat ipsec.conf ike passive from any to any \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des psk TheSecret The INVALID_COOKIE messages have been replaced with this: # isakmpd -K4dv 092755.013577 Default isakmpd: phase 1 done: initiator id ac1e0114: 172.30.1.20, responder id ac1e0101: 172.30.1.1, src: 172.30.1.1 dst: 172.30.1.20 092755.017234 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id ac1e0114: 172.30.1.20, responder id ac1e0101: 172.30.1.1 092755.017569 Default dropped message from 172.30.1.20 port 500 due to notification type NO_PROPOSAL_CHOSEN 092758.020965 Default responder_recv_HASH_SA_NONCE: peer proposed invalid phase 2 IDs: initiator id ac1e0114: 172.30.1.20, responder id ac1e0101: 172.30.1.1 The proposal messages repeat until Mac timeout or I cancel. ipsecctl - m shows nothing. I had a similar proposal error when 'main auth' was set to 'enc aes'. I increased the reporting level of isakmpd and noticed a message that said something to the effect of "client proposed 3DES, expected AES". That was when i changed my encryption type to 3DES. I see no such hints from isakmpd during the invalid phase 2 exchange. I tried altering my ipsec.conf to try different encryption algorithms for phase 2. 3des, aes, aesctr, and blowfish all report the same proposal error. I shall try changing the authentication method. If i change anything in the phase 1 section 'main', phase 1 fails. My continued thanks for any assistance
Re: ipsec vpn and intermittent session timeouts...
Sounds a little like: http://marc.info/?l=openbsd-misc&m=117915053113185&w=2 I was privately requested to try an upgrade to 4.1-stable. I have not had the opportunity to do so and I seem to be having a little trouble building 4.1-stable at the moment... -Steve S.
Re: ipsec vpn and intermittent session timeouts...
* Add support for ESP+NULL encryption for ipsec. Useful for traversing NAT where AH can't be used. * Fixes for ipsec in IPv6. * In ipsecctl(8), allow rule if there is at least one matching address family combination. * Added better support for IPv6 hostname/numeric representation in the ipsecctl(8) parser. * Make ipsecctl(8) handle multiple SAs with same src/dst but different port. * Add support in pf(4) to tag ipsec traffic belonging to specific IKE-initiated phase 2 traffic. Allows policy-based filtering of encrypted and unencrypted ipsec traffic. * In ipsecctl(8), do not delete sections that might be shared with other connections. This workaround might leak isakmpd(8) entries, but is ok for now. * Make ipsecctl(8) handle rules with addresses from mismatched address families correctly. * Make ipsecctl(8) check both source and destination when grouping SAs. * Fix grouping for SAs in ipsecctl(8), now all combinations of SAs are possible, not only ESP+AH. * Make sure ipsecctl(8) does not count sa, ike and tcpmd5 rules twice. * Add support in ipsecctl(8) for aggressive mode. * Have bgpd(8) store copies of everything needed to remove SAs and flows later. Allows for migration from tcp md5sig to ipsec esp ike with just bgpctl reload on both sides and bgpctl neighbor $foo clear on one side. On 5/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > yes it does..., im actually running 4.1 on one side. havent had a chance > to upgrade the other side yet. privately requested to upgrade by whom? is > this a known issue... maybe i should run through the change log once > again... > > On 5/24/07, Steven Surdock <[EMAIL PROTECTED]> wrote: > > > > Sounds a little like: > > http://marc.info/?l=openbsd-misc&m=117915053113185&w=2 > > > > I was privately requested to try an upgrade to 4.1-stable . I have not > > had the opportunity to do so and I seem to be having a little trouble > > building 4.1-stable at the moment... > > > > -Steve S.
Re: ipsec vpn openbsd 4.2 / netgear DG834
Hello jcr,
Friday, November 23, 2007, 5:36:30 PM, you wrote:
> k .
> 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
And what about your firewall ? Maybe it blocks incoming packets?
Another idea - maybe your provider block IKE messages?
Check this first :)
--
Best regards,
Evgeniymailto:[EMAIL PROTECTED]
Re: IPSec VPN and tunnel mode routing
> 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
On 2010-03-30, Girish Venkatachalam 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
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 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 ifco
Re: IPSec VPN gateway with only one interface
For the record: The problem was not with with the single interface, but with my misreading the documentation. The error was in specifying the tunnel twice. The working ipsec directives are of course: ipsec.conf on A: ike esp from to peer srcid dstid ipsec.conf on B: ike passive esp tunnel from any to srcid Markus Wernig wrote: Hi all I'v looked through what documentation I could find, but didn't find this case mentioned, so I assumed it would work (which it doesn't): I have an OBSD 4.1 vpn gateway (A) with only one interface, over which the default route points out and over which the packets to forward through the tunnel arrive. The other gateway is a "regular" 2-interface OBSD 4.1 gateway (B). Here's the layout: Internal Net -- -- VPN gateway A & Internet & & VPN gateway B & Destination Net The tunnel seemingly does get created without any errors, but when packets pass through the tunnel, the remote gateway sends them right back. Also, on both gateways, 4 flows and 4 SADs get created, instead of 2 each, as I'd expect: # ipsecctl -s all FLOWS: flow esp in from to peer B> srcid dstid type use flow esp out from to peer B> srcid dstid type require flow esp in from to peer B> srcid dstid type use flow esp out from to peer B> srcid dstid type require SAD: esp tunnel from to spi 0xADEADBEEF auth hmac-sha2-256 enc aes esp tunnel from to spi 0xBDEADBEEF auth hmac-sha2-256 enc aes esp tunnel from to spi 0xCDEADBEEF auth hmac-sha2-256 enc aes esp tunnel from to spi 0xDDEADBEEF auth hmac-sha2-256 enc aes Thus, contradicting routes get added to the kernel routing tables: gateway B: Encap: Source Port DestinationPort Proto SA(Address/Proto/Type/Direction) 0 0 0 NAT router A/esp/use/in 0 0 0 NAT router A/esp/require/out 0 0 0 NAT router A/esp/use/in 0 0 0 NAT router A/esp/require/out ipsec.conf on A: ike esp from to peer srcid ike esp from to peer srcid ipsec.conf on B: ike passive esp tunnel from any to srcid ike passive esp tunnel from to any srcid A tcpdump on enc0 of both gateways shows the packets looping between the two gateways until ttl == 1. Can anybody tell me if this is supposed to work at all? Does anyone see an obvious flaw? I'm really lost at why the gateways add flows and routes in both directions... thx /markus
Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)
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)
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)
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)
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)
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 between OpenBSD and Linux (OpenSwan)
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 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 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 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 isakmpd[11393]: message_parse_payloads: invalid
next payload type in payload of type 5
Aug 27 10:24:56 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
port 500 due to notification type INVALID_PAYLOAD_TYPE
Aug 27 10:25:05 fw-001 isakmpd[11393]: message_parse_payloads: invalid
next payload type in payload of type 5
Aug 27 10:25:05 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
port 500 due to notification type INVALID_PAYLOAD_TYPE
Aug 27 10:25:26 fw-001 isakmpd[11393]: message_parse_payloads: invalid
next payload type in payload of type 5
Aug 27 10:25:26 fw-001 isakmpd[11393]: dropped message from PUBLIC_LINUX
port 500 due to notification type INVALID_PAYLOAD_TYPE
Aug 27 10:27:16 fw-001 isakmpd[11393]: message_parse_payloads: reserved
field non-zero: b0
Aug 27 10:27:16 fw-001 isakmpd
Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)
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=b allb
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 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 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 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 mess
Re: IPSEC VPN between OpenBSD and Linux (OpenSwan)
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=b allb 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)
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=b allb >> 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)
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
Re: ipsec vpn netgear DG834 : openbsd 4.2 (new thread)
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 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
>
