Re: IKEv2 (iked) VPN with Windows 10 clients
Thanks for the suggestions guys problem solved.
It appears there was a static route on the test machine that was causing the
issue. Once removed traffic started flowing to the destination.
Kind regards,
Roberto Katalinic
07460663373
kliker IT
www.kliker.it<http://www.kliker.it>
08455442033
From: Bobby Johnson [mailto:bo...@plexuscomp.com]
Sent: 15 March 2017 02:08
To: Roberto Katalinic <robe...@klikerit.com>
Cc: misc <misc@openbsd.org>
Subject: Re: IKEv2 (iked) VPN with Windows 10 clients
Your configuration looks reasonable. You should upgrade to 6.0. You could
replace the local network range with 0.0.0.0/0<http://0.0.0.0/0> to limit the
flow less. I've found that config address with a range doesn't work as
expected with multiple clients. Below is an example of a working config using
machine certs for windows clients, including Windows 10.
ikev2 passive esp \
from 0.0.0.0/0<http://0.0.0.0/0> to 192.168.40.2 local 1.2.3.4 peer any \
srcid "asn1_dn of server cert"
dstid "asn1_dn of client cert" \
config address 192.168.40.2 \
config name-server 10.0.0.4
On Mar 10, 2017 7:58 AM, "Roberto Katalinic"
<robe...@klikerit.com<mailto:robe...@klikerit.com>> wrote:
I have a few remote workers with Windows 10 and would like to move them to
IKEv2 VPN.
On my gateway (OpenBSD 5.7) the iked.conf file is:
ikev2 "IKEv2 DIAL-IN" passive esp \
from 192.168.10.0/24<http://192.168.10.0/24> to
192.168.40.0/24<http://192.168.40.0/24> \
local 1.2.3.4 peer 0.0.0.0/0<http://0.0.0.0/0> \
srcid 1.2.3.4 \
config access-server 192.168.10.10 \
config name-server 192.168.10.21 \
config address 192.168.40.0/24<http://192.168.40.0/24>
My remote client is configured like this:
VPN Type: IKEv2
Data encryption: Optional
Authentication: Use machine Certificates (no EAP)
My PF rules contain the following lines which are definitely not overruled by
any rules further down the line:
set skip on {lo,enc0}
pass in on egress proto udp from any to any port {500,4500}
pass in on egress proto {ah,esp}
When the client attempts connection, the SA is configured and Windows reports
the connection as established. It also acquires an IP address and the DNS
server as specified in the iked.conf file:
PPP adapter EDGE:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : EDGE
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.40.87(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 192.168.10.21
NetBIOS over Tcpip. . . . . . . . : Enabled
My gateway also reports the connection as established and the SA is shown by
ipsecctl -sa:
FLOWS:
flow esp in from 192.168.40.87 to 192.168.10.0/24<http://192.168.10.0/24> peer
5.6.7.8 srcid
IPV4/1.2.3.4<http://1.2.3.4> type use
flow esp out from 192.168.10.0/24<http://192.168.10.0/24> to 192.168.40.87 peer
5.6.7.8 srcid
IPV4/1.2.3.4<http://1.2.3.4> type require
flow esp out from ::/0 to ::/0 type deny
SAD:
esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x7a8197f6 auth hmac-sha1 enc aes-256
esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x926fb219 auth hmac-sha1 enc aes-256
Output from iked -dvvv:
ikev2_pld_cp: INTERNAL_IP4_SERVER 0x5ba0 length 4
ikev2_pld_cp: INTERNAL_IP4_DNS 0x0003 length 4
ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4
ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length
44
ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4
xforms 3 spi 0xe7ce691f
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96
ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE
ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length
24
ikev2_pld_ts: count 1 length 16
ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport
65535
ikev2_pld_ts: start 192.168.40.34 end 192.168.40.34
ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00
length 24
ikev2_pld_ts: count 1 length 16
ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport
65535
ikev2_pld_ts: start 192.168.10.0 end 192.168.10.255
ikev2_msg_send: IKE_AUTH response from 1.2.3.4:4500<http://1.2.3.4:4500> to
5.6.7.8:15573<http://5.6.7.8:15573> msgid 1,
1452 bytes, NAT-T
pfkey_sa_add: update spi 0xe7ce691f
pfkey_sa: udpencap port 15573
ikev2_childsa_enable: loaded CHILD SA spi 0xe7ce691f
pfkey_sa_add: add spi 0xabf256a4
pfkey_sa: udpencap port 15573
ikev2_childsa_enable: loaded CHILD SA spi 0xabf256a4
ikev2_childsa_enable: loaded flow 0x1166a0b99800
ikev2_childsa_e
IKEv2 (iked) VPN with Windows 10 clients
I have a few remote workers with Windows 10 and would like to move them to
IKEv2 VPN.
On my gateway (OpenBSD 5.7) the iked.conf file is:
ikev2 "IKEv2 DIAL-IN" passive esp \
from 192.168.10.0/24 to 192.168.40.0/24 \
local 1.2.3.4 peer 0.0.0.0/0 \
srcid 1.2.3.4 \
config access-server 192.168.10.10 \
config name-server 192.168.10.21 \
config address 192.168.40.0/24
My remote client is configured like this:
VPN Type: IKEv2
Data encryption: Optional
Authentication: Use machine Certificates (no EAP)
My PF rules contain the following lines which are definitely not overruled by
any rules further down the line:
set skip on {lo,enc0}
pass in on egress proto udp from any to any port {500,4500}
pass in on egress proto {ah,esp}
When the client attempts connection, the SA is configured and Windows reports
the connection as established. It also acquires an IP address and the DNS
server as specified in the iked.conf file:
PPP adapter EDGE:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : EDGE
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.40.87(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . :
DNS Servers . . . . . . . . . . . : 192.168.10.21
NetBIOS over Tcpip. . . . . . . . : Enabled
My gateway also reports the connection as established and the SA is shown by
ipsecctl -sa:
FLOWS:
flow esp in from 192.168.40.87 to 192.168.10.0/24 peer 5.6.7.8 srcid
IPV4/1.2.3.4 type use
flow esp out from 192.168.10.0/24 to 192.168.40.87 peer 5.6.7.8 srcid
IPV4/1.2.3.4 type require
flow esp out from ::/0 to ::/0 type deny
SAD:
esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x7a8197f6 auth hmac-sha1 enc aes-256
esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x926fb219 auth hmac-sha1 enc aes-256
Output from iked -dvvv:
ikev2_pld_cp: INTERNAL_IP4_SERVER 0x5ba0 length 4
ikev2_pld_cp: INTERNAL_IP4_DNS 0x0003 length 4
ikev2_pld_cp: INTERNAL_IP4_ADDRESS 0x0001 length 4
ikev2_pld_payloads: decrypted payload SA nextpayload TSi critical 0x00 length
44
ikev2_pld_sa: more 0 reserved 0 length 40 proposal #1 protoid ESP spisize 4
xforms 3 spi 0xe7ce691f
ikev2_pld_xform: more 3 reserved 0 length 12 type ENCR id AES_CBC
ikev2_pld_attr: attribute type KEY_LENGTH length 256 total 4
ikev2_pld_xform: more 3 reserved 0 length 8 type INTEGR id HMAC_SHA1_96
ikev2_pld_xform: more 0 reserved 0 length 8 type ESN id NONE
ikev2_pld_payloads: decrypted payload TSi nextpayload TSr critical 0x00 length
24
ikev2_pld_ts: count 1 length 16
ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport
65535
ikev2_pld_ts: start 192.168.40.34 end 192.168.40.34
ikev2_pld_payloads: decrypted payload TSr nextpayload NONE critical 0x00
length 24
ikev2_pld_ts: count 1 length 16
ikev2_pld_ts: type IPV4_ADDR_RANGE protoid 0 length 16 startport 0 endport
65535
ikev2_pld_ts: start 192.168.10.0 end 192.168.10.255
ikev2_msg_send: IKE_AUTH response from 1.2.3.4:4500 to 5.6.7.8:15573 msgid 1,
1452 bytes, NAT-T
pfkey_sa_add: update spi 0xe7ce691f
pfkey_sa: udpencap port 15573
ikev2_childsa_enable: loaded CHILD SA spi 0xe7ce691f
pfkey_sa_add: add spi 0xabf256a4
pfkey_sa: udpencap port 15573
ikev2_childsa_enable: loaded CHILD SA spi 0xabf256a4
ikev2_childsa_enable: loaded flow 0x1166a0b99800
ikev2_childsa_enable: loaded flow 0x1166a0b99400
sa_state: VALID -> ESTABLISHED from 5.6.7.8:15573 to 1.2.3.4:4500 policy
'IKEv2 DIAL-IN'
The problem is, from the remote worker, I cannot connect to any resources on
the remote network. Pinging the remote gateway's internal IP address or the
DNS server produces no replies.
Equally, the gateway cannot ping the remote worker's IP address.
tcpdump on the enc0 and pflog0 interfaces produces no results at all when
creating traffic between the two.
What am I missing?
Kind regards,
Roberto Katalinic
07460663373
kliker IT
www.kliker.it<http://www.kliker.it>
08455442033
Information contained in this e-mail is intended for the use of the addressee
only, and is confidential and may be the subject of Legal Professional
Privilege. Any dissemination, distribution, copying or use of this
communication without prior permission of the addressee is strictly
prohibited. The contents of an attachment to this e-mail may contain software
viruses which could damage your own computer system. While Kliker IT Services
Ltd. has taken every reasonable precaution to minimise this risk, we cannot
accept liability for any damage which you sustain as a result of software
viruses. You should carry out your own virus checks before opening the
attachment. Registered Office: New House, South Grove, Petworth, GU280ED.
Company Number: 8206089.Company Registered in England and Wales.
Re: OpenBSD octeon on DSR-1000n
Diana Eichert wrench.com> writes: > > Posting capture of all boot message would be useful. > > There may only be one DSR-500N running OpenBSD, Paul's. I cc'd > him, 'cause I'm not sure if he reads misc . > > diana > > On Sat, 5 Sep 2015, Roberto Katalinic wrote: > > > I have a Dlink DSR-1000N and want to install OpenBSD on it. > > > > I saw the DSR-500 as a supported device on the octeon list and was hoping > > the hoping the > > 1000n would be as well. > > I didn't get very far - "Error allocating memory for elf image!" when > > booting booting > > the kernel. > > > > Anyone knows if the 1000n is being worked on/supported? > > > > Regards, > > Roberto > > Hi Diana, Below is the complete output from device start up through to the error mess message. Hope it helps Paul. >>>>>>>>>>>>>>>>>>>>> U-Boot 1.1.1 (Development build, svnversion: exported) (Build time: Sep 1 2010 - 16:18:38) Warning: Board descriptor tuple not found in eeprom, using defaults CUST_DSR1000N board revision major:2, minor:0, serial #: unknown OCTEON CN5010-SCP pass 1.1, Core clock: 500 MHz, DDR clock: 200 MHz (400 Mhz Mhz data rate) DRAM: 256 MB Flash: 32 MB *** Warning - bad CRC, using default environment Clearing DRAM.. done BIST check passed. Starting PCI PCI Status: PCI 32-bit PCI BAR 0: 0x, PCI BAR 1: Memory 0x PCI 0xf800 Net: octeth0, octeth1, octeth2 Hit any key to stop autoboot: 0 D-Link DSR-1000N bootloader# dhcp Interface 0 has 3 ports (RGMII) BOOTP broadcast 1 octeth0: Up 1000 Mbps Full duplex (port 0) DHCP client bound to address 192.168.10.201 D-Link DSR-1000N bootloader# tftpboot 0 bsd.rd Using octeth0 device TFTP from server 192.168.10.60; our IP address is 192.168.10.201 Filename 'bsd.rd'. Load address: 0xaa0 Loading: # done Bytes transferred = 7548970 (73302a hex), 7514 Kbytes/sec D-Link DSR-1000N bootloader# bootoctlinux ELF file is 64 bit Attempting to allocate memory for ELF segment: addr: 0x8100 ( (adjusted to: 0x0100), size 0x764600 Allocated memory for ELF segment: addr: 0x8100, size 0x764600 Attempting to allocate memory for ELF segment: addr: 0x816ec790 (ad (adjusted to: 0x016ec790), size 0x2400 Error allocating memory for elf image! ## ERROR loading File! D-Link DSR-1000N bootloader#
OpenBSD octeon on DSR-1000n
I have a Dlink DSR-1000N and want to install OpenBSD on it. I saw the DSR-500 as a supported device on the octeon list and was hoping the 1000n would be as well. I didn't get very far - "Error allocating memory for elf image!" when booting the kernel. Anyone knows if the 1000n is being worked on/supported? Regards, Roberto Information contained in this e-mail is intended for the use of the addressee only, and is confidential and may be the subject of Legal Professional Privilege. Any dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited. The contents of an attachment to this e-mail may contain software viruses which could damage your own computer system. While Kliker IT Services Ltd. has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment. Registered Office: New House, South Grove, Petworth, GU280ED. Company Number: 8206089.Company Registered in England and Wales.
