Re: isakmpd does not tag packets
On Tue, Dec 12, 2023 at 07:38:30AM +0100, Sebastian John wrote: > Hello, > > I installed (not upgrade) OpenBSD 7.4 (amd64) on a brand new > machine. I put the isakmpd.conf from the old maschine (7.3) on the > new one. Also some other configurations (interfaces, pf...). All > works fine but the incomming IPSec packets are not tagged anymore. > > [.. isakmpd.conf ..] > PF-Tag= IPSEC_FOOBAR > [..] > > [.. pf.conf ..] > pass out quick on em0 inet tagged IPSEC_FOOBAR > [..] > > On the 7.3 maschine this works. Since OpenBSD 7.4 this does not work > anymore. I didn't find any information in the upgrade instructions. > There are a known bug? Or any other ideas? Thanks for the report. It looks like this was broken when we added sec(4) support in 7.4. I just committed a fix. > > Sebastian > > > > -- >
isakmpd does not tag packets
Hello, I installed (not upgrade) OpenBSD 7.4 (amd64) on a brand new machine. I put the isakmpd.conf from the old maschine (7.3) on the new one. Also some other configurations (interfaces, pf...). All works fine but the incomming IPSec packets are not tagged anymore. [.. isakmpd.conf ..] PF-Tag= IPSEC_FOOBAR [..] [.. pf.conf ..] pass out quick on em0 inet tagged IPSEC_FOOBAR [..] On the 7.3 maschine this works. Since OpenBSD 7.4 this does not work anymore. I didn't find any information in the upgrade instructions. There are a known bug? Or any other ideas? Sebastian --
Re: functional difference of isakmpd and iked
On 2022-03-11, Axel Rau wrote: > > >> Am 09.03.2022 um 11:44 schrieb Axel Rau : >> >> are both able to support the same network topologies with both IPv4 and IPv6? > Seems to be a difficult question. Nobody wants to decode the isakmpd.conf to work out what the existing configuration does :-)
Re: functional difference of isakmpd and iked
> Am 11.03.2022 um 14:32 schrieb Tobias Heider : > > looks like your setup should also work with iked. So I will try this in a few weeks and report back. Thanks for responding, Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius
Re: functional difference of isakmpd and iked
On Fri, Mar 11, 2022 at 11:27:59AM +0100, Axel Rau wrote: > > > > Am 09.03.2022 um 11:44 schrieb Axel Rau : > > > > are both able to support the same network topologies with both IPv4 and > > IPv6? > Seems to be a difficult question. > What can I do to get an answer / a comment of one of the experts? > > Axel Hey Axel, looks like your setup should also work with iked. Keep in mind however that running iked and isakmpd on the same machine does not work, so you will probably have to switch all machines at the same time without overlap. Feel free to reach out if you encounter any problems. - Tobias > --- > PGP-Key: CDE74120 ☀ computing @ chaos claudius >
Re: functional difference of isakmpd and iked
> Am 09.03.2022 um 11:44 schrieb Axel Rau : > > are both able to support the same network topologies with both IPv4 and IPv6? Seems to be a difficult question. What can I do to get an answer / a comment of one of the experts? Axel --- PGP-Key: CDE74120 ☀ computing @ chaos claudius
functional difference of isakmpd and iked
Hi all, are both able to support the same network topologies with both IPv4 and IPv6? The application uses 3 VPN gateways (all OpenBSD) and connects several public nets behind both gateways. Some private nets are served without NAT to other VPN members. One gateway uses a fixed IPv4 address, the other 2 are road warriors, where IP of others changes about once a month. As this is an operational setup, moving from isakmpd to iked seems to be a challenge. (-: Can the transition be done without loosing functionality? Axel PS: To illustrate further, I include the connections from isakmpd.conf gw with fixed address: [CON_2_2] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Local-ID= NET_IH4 Remote-ID= NET_M4_PRIVATE PF-Tag= FROM_VPN [CON_2_3] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Local-ID= NET_DEFAULT4 Remote-ID= NET_M4_LRAU PF-Tag= FROM_VPN [CON_2_4] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Local-ID= NET_N6_GLOBAL_UNICAST Remote-ID= NET_M6_LRAU PF-Tag= FROM_VPN [CON_2_5] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Local-ID= NET_N6_GLOBAL_UNICAST Remote-ID= NET_M6_WLAN_LRAU PF-Tag= FROM_VPN # -- [CON_3_1] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Local-ID= NET_IH4 Remote-ID= NET_N4_PRIVATE PF-Tag= FROM_VPN [CON_3_2] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Local-ID= NET_N6_GLOBAL_UNICAST Remote-ID= NET_N6_LRAU PF-Tag= FROM_VPN # -- [CON_23_1] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Local-ID= NET_M4_PRIVATE Remote-ID= NET_N4_PRIVATE PF-Tag= FROM_VPN [CON_23_2] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Local-ID= NET_N4_PRIVATE Remote-ID= NET_M4_PRIVATE PF-Tag= FROM_VPN One of 2 road warriors: - # --- [CON_2_2] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Flags= Active-only Remote-ID= NET_IH4 Local-ID= NET_M4_PRIVATE PF-Tag= FROM_VPN # --- [CON_2_3] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Flags= Active-only Remote-ID= NET_DEFAULT4 Local-ID= NET_M4_LRAU PF-Tag= FROM_VPN # --- [CON_2_4] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Flags= Active-only Remote-ID= NET_N6_GLOBAL_UNICAST Local-ID= NET_M6_LRAU PF-Tag= FROM_VPN # --- [CON_2_5] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Flags= Active-only Remote-ID= NET_N6_GLOBAL_UNICAST Local-ID= NET_M6_WLAN_LRAU PF-Tag= FROM_VPN # -- [CON_23_1] Phase= 2 ISAKMP-peer=CON_1 Configuration= quick-mode Local-ID= NET_M4_PRIVATE Remote-ID= NET_N4_PRIVATE PF-Tag= FROM_VPN --- PGP-Key: CDE74120 ☀ computing @ chaos claudius
Re: Ynt: howto separate isakmpd syslogs into another file
On 12/30/21 04:40, Hayri Can KAVAK wrote:
Thanks Martijn; it worked by creating these files.
Gönderen: Martijn van Duren adına
owner-m...@openbsd.org
Gönderildi: 30 Aralık 2021 Perşembe 12:46
Kime: Hayri Can KAVAK ; misc@openbsd.org
Konu: Re: howto separate isakmpd syslogs into another file
On Thu, 2021-12-30 at 08:59 +, Hayri Can KAVAK wrote:
Hello,
I'm trying to separate isakmpd/ipsec logs to another file instead of
/var/log/messages.
Here my config at the top of /etc/syslog.conf
!!isakmpd
daemon.info /var/log/ipsec_info.log
daemon.debug/var/log/ipsec_debug.log
!*
I restarted syslogd & isakmpd but nothing changed. It still logs to
/var/log/messages.
How can i achieve this?
Thanks in advance.
The files /var/log/ipsec_{info,debug}.log need to exist before logging
to them (and loaded in by sending SIGHUP to syslog(8)). syslogd(8) will
not try to create the files. From syslogd(8):
The logfiles already have to exist with the correct permissions.
The default syslog.conf doesn't write messages for DAEMON to
/var/log/messages, they should end up in /var/log/daemon. But without
seeing your full syslog.conf I can't say what's going on there.
Hope this helps.
martijn@
--
Boyd Stephens
Netelysis
tel:334.213.1128
email: bsteph...@netelysis.com
Ynt: howto separate isakmpd syslogs into another file
Thanks Martijn; it worked by creating these files.
Gönderen: Martijn van Duren adına
owner-m...@openbsd.org
Gönderildi: 30 Aralık 2021 Perşembe 12:46
Kime: Hayri Can KAVAK ; misc@openbsd.org
Konu: Re: howto separate isakmpd syslogs into another file
On Thu, 2021-12-30 at 08:59 +, Hayri Can KAVAK wrote:
> Hello,
>
> I'm trying to separate isakmpd/ipsec logs to another file instead of
> /var/log/messages.
> Here my config at the top of /etc/syslog.conf
> !!isakmpd
> daemon.info
> /var/log/ipsec_info.log
> daemon.debug
> /var/log/ipsec_debug.log
> !*
>
> I restarted syslogd & isakmpd but nothing changed. It still logs to
> /var/log/messages.
> How can i achieve this?
>
> Thanks in advance.
The files /var/log/ipsec_{info,debug}.log need to exist before logging
to them (and loaded in by sending SIGHUP to syslog(8)). syslogd(8) will
not try to create the files. From syslogd(8):
The logfiles already have to exist with the correct permissions.
The default syslog.conf doesn't write messages for DAEMON to
/var/log/messages, they should end up in /var/log/daemon. But without
seeing your full syslog.conf I can't say what's going on there.
Hope this helps.
martijn@
Re: howto separate isakmpd syslogs into another file
On Thu, 2021-12-30 at 08:59 +, Hayri Can KAVAK wrote:
> Hello,
>
> I'm trying to separate isakmpd/ipsec logs to another file instead of
> /var/log/messages.
> Here my config at the top of /etc/syslog.conf
> !!isakmpd
> daemon.info
> /var/log/ipsec_info.log
> daemon.debug
> /var/log/ipsec_debug.log
> !*
>
> I restarted syslogd & isakmpd but nothing changed. It still logs to
> /var/log/messages.
> How can i achieve this?
>
> Thanks in advance.
The files /var/log/ipsec_{info,debug}.log need to exist before logging
to them (and loaded in by sending SIGHUP to syslog(8)). syslogd(8) will
not try to create the files. From syslogd(8):
The logfiles already have to exist with the correct permissions.
The default syslog.conf doesn't write messages for DAEMON to
/var/log/messages, they should end up in /var/log/daemon. But without
seeing your full syslog.conf I can't say what's going on there.
Hope this helps.
martijn@
howto separate isakmpd syslogs into another file
Hello, I'm trying to separate isakmpd/ipsec logs to another file instead of /var/log/messages. Here my config at the top of /etc/syslog.conf !!isakmpd daemon.info /var/log/ipsec_info.log daemon.debug/var/log/ipsec_debug.log !* I restarted syslogd & isakmpd but nothing changed. It still logs to /var/log/messages. How can i achieve this? Thanks in advance.
Re: isakmpd ignoring authentication metod
Thanks Stuart for the answer the new flags don't change the log output. While with tcpdump I can see that the other endpoint is sending correct ipsec parameters: 12:49:08.025601 *.fastwebnet.it.isakmp > *.it.isakmp: [udp sum ok] isakmp v1.0 exchange ID_PROT cookie: db2bb04573305edb-> msgid: len: 200 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: 1 ID: ISAKMP attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCRYPTION_ALGORITHM = 3DES_CBC attribute AUTHENTICATION_METHOD = PRE_SHARED attribute HASH_ALGORITHM = SHA2_256 attribute GROUP_DESCRIPTION = MODP_1024 payload: VENDOR len: 20 (supports NAT-T, RFC 3947) payload: VENDOR len: 20 (supports v3 NAT-T, draft-ietf-ipsec-nat-t-ike-03) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02\n) payload: VENDOR len: 20 (supports v2 NAT-T, draft-ietf-ipsec-nat-t-ike-02) payload: VENDOR len: 20 (supports DPD v1.0) payload: VENDOR len: 20 (DF) (ttl 52, id 41086, len 228) ipsec -vnf /etc/ipsec.conf C add [phase1-peer-*]:Transforms=phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024 force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:AUTHENTICATION_METHOD=PRE_SHARED force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:HASH_ALGORITHM=SHA2_256 force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:ENCRYPTION_ALGORITHM=3DES_CBC force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:GROUP_DESCRIPTION=MODP_1024 force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024]:Life=phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024-life force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024-life]:LIFE_TYPE=SECONDS force C set [phase1-transform-peer-*-PRE_SHARED-SHA2_256-3DES-MODP_1024-life]:LIFE_DURATION=28800 force .. Giacomo > On 5 May 2021, at 14:33, Stuart Henderson wrote: > > On 2021-05-04, Giacomo Marconi wrote: >> Hi all >> >> I have some openbsd boxes as vpn endpoint to a Palo Alto Pa-820. >> >> In my last VPN config (unsing 6.8) I see in the logs that isakmpd is >> expexting RSA_SIG as authentication method, while in ipsec.conf I set the >> psk value. > > This usually means that the packets seen from the other side didn't > match your configuration (possibly a wrong IP or something) and > instead were matched by the implicit default phase 1 configuration > (which is 3DES-SHA-RSA_SIG) > > If that doesn't give any clues, bump up logging in isakmpd. This > set of debug levels (worked out by studying source code) enables > most logs that are possible to do without being so noisy that > they're useless. > > isakmpd_flags="-Kv -D0=29 -D1=49 -D2=10 -D3=30 -D5=20 -D6=30 -D8=30 -D9=30 > -D10=20" > > Sometimes looking at captured packets is useful too. For phase 1 > negotiation then just watching the network interface is usually > good > > tcpdump -vvs1500 -i $interface port 500 or 4500 > > (For problems with phase 2 nego you often need to enable isakmpd's > cleartext IKE packet capture via the isakmpd.fifo control socket > but you aren't that far). > > > > >
Re: isakmpd ignoring authentication metod
On 2021-05-04, Giacomo Marconi wrote: > Hi all > > I have some openbsd boxes as vpn endpoint to a Palo Alto Pa-820. > > In my last VPN config (unsing 6.8) I see in the logs that isakmpd is > expexting RSA_SIG as authentication method, while in ipsec.conf I set the psk > value. This usually means that the packets seen from the other side didn't match your configuration (possibly a wrong IP or something) and instead were matched by the implicit default phase 1 configuration (which is 3DES-SHA-RSA_SIG) If that doesn't give any clues, bump up logging in isakmpd. This set of debug levels (worked out by studying source code) enables most logs that are possible to do without being so noisy that they're useless. isakmpd_flags="-Kv -D0=29 -D1=49 -D2=10 -D3=30 -D5=20 -D6=30 -D8=30 -D9=30 -D10=20" Sometimes looking at captured packets is useful too. For phase 1 negotiation then just watching the network interface is usually good tcpdump -vvs1500 -i $interface port 500 or 4500 (For problems with phase 2 nego you often need to enable isakmpd's cleartext IKE packet capture via the isakmpd.fifo control socket but you aren't that far).
isakmpd ignoring authentication metod
Hi all I have some openbsd boxes as vpn endpoint to a Palo Alto Pa-820. In my last VPN config (unsing 6.8) I see in the logs that isakmpd is expexting RSA_SIG as authentication method, while in ipsec.conf I set the psk value. May 4 18:11:44 fw-donmilani isakmpd[37871]: attribute_unacceptable: AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG May 4 18:11:44 fw-donmilani isakmpd[37871]: message_negotiate_sa: no compatible proposal found May 4 18:11:44 fw-donmilani isakmpd[37871]: dropped message from 93.63.x.x port 500 due to notification type NO_PROPOSAL_CHOSEN fw-donmilani# uname -a OpenBSD fw-donmilani.comune.arezzo.it 6.8 GENERIC.MP#98 amd64 fw-donmilani# cat /etc/ipsec.conf ike esp from 172.16.146.0/24 to 172.16.0.0/16 peer 93.63.x.x \ main auth "hmac-sha2-256" enc "3des" group modp2048 \ quick auth "hmac-sha2-256" enc "3des" group modp2048 \ psk "hxxxI" fw-donmilani# fw-donmilani# ipsecctl -nvf /etc/ipsec.conf C set [Phase 1]:93.63.x.x=peer-93.63.x.x force C set [peer-93.63.x.x]:Phase=1 force C set [peer-93.63.x.x]:Address=93.63.x.x force C set [peer-93.63.x.x]:Authentication=hxxxI force C set [peer-93.63.x.x]:Configuration=phase1-peer-93.63.x.x force C set [phase1-peer-93.63.x.x]:EXCHANGE_TYPE=ID_PROT force C add [phase1-peer-93.63.x.x]:Transforms=phase1-transform-peer-93.63.x.x-PRE_SHARED-SHA2_256-3DES-MODP_2048 force C set [phase1-transform-peer-93.63.x.x-PRE_SHARED-SHA2_256-3DES-MODP_2048]:AUTHENTICATION_METHOD=PRE_SHARED force C set [phase1-transform-peer-93.63.x.x-PRE_SHARED-SHA2_256-3DES-MODP_2048]:HASH_ALGORITHM=SHA2_256 force C set [phase1-transform-peer-93.63.x.x-PRE_SHARED-SHA2_256-3DES-MODP_2048]:ENCRYPTION_ALGORITHM=3DES_CBC force C set [phase1-transform-peer-93.63.x.x-PRE_SHARED-SHA2_256-3DES-MODP_2048]:GROUP_DESCRIPTION=MODP_2048 force C set [phase1-transform-peer-93.63.x.x-PRE_SHARED-SHA2_256-3DES-MODP_2048]:Life=LIFE_MAIN_MODE force C set [from-172.16.146.0/24-to-172.16.0.0/16]:Phase=2 force C set [from-172.16.146.0/24-to-172.16.0.0/16]:ISAKMP-peer=peer-93.63.x.x force C set [from-172.16.146.0/24-to-172.16.0.0/16]:Configuration=phase2-from-172.16.146.0/24-to-172.16.0.0/16 force C set [from-172.16.146.0/24-to-172.16.0.0/16]:Local-ID=from-172.16.146.0/24 force C set [from-172.16.146.0/24-to-172.16.0.0/16]:Remote-ID=to-172.16.0.0/16 force C set [phase2-from-172.16.146.0/24-to-172.16.0.0/16]:EXCHANGE_TYPE=QUICK_MODE force C set [phase2-from-172.16.146.0/24-to-172.16.0.0/16]:Suites=phase2-suite-from-172.16.146.0/24-to-172.16.0.0/16 force C set [phase2-suite-from-172.16.146.0/24-to-172.16.0.0/16]:Protocols=phase2-protocol-from-172.16.146.0/24-to-172.16.0.0/16 force C set [phase2-protocol-from-172.16.146.0/24-to-172.16.0.0/16]:PROTOCOL_ID=IPSEC_ESP force C set [phase2-protocol-from-172.16.146.0/24-to-172.16.0.0/16]:Transforms=phase2-transform-from-172.16.146.0/24-to-172.16.0.0/16-3DES-SHA2_256-MODP_2048-TUNNEL force C set [phase2-transform-from-172.16.146.0/24-to-172.16.0.0/16-3DES-SHA2_256-MODP_2048-TUNNEL]:TRANSFORM_ID=3DES force C set [phase2-transform-from-172.16.146.0/24-to-172.16.0.0/16-3DES-SHA2_256-MODP_2048-TUNNEL]:ENCAPSULATION_MODE=TUNNEL force C set [phase2-transform-from-172.16.146.0/24-to-172.16.0.0/16-3DES-SHA2_256-MODP_2048-TUNNEL]:AUTHENTICATION_ALGORITHM=HMAC_SHA2_256 force C set [phase2-transform-from-172.16.146.0/24-to-172.16.0.0/16-3DES-SHA2_256-MODP_2048-TUNNEL]:GROUP_DESCRIPTION=MODP_2048 force C set [phase2-transform-from-172.16.146.0/24-to-172.16.0.0/16-3DES-SHA2_256-MODP_2048-TUNNEL]:Life=LIFE_QUICK_MODE force C set [from-172.16.146.0/24]:ID-type=IPV4_ADDR_SUBNET force C set [from-172.16.146.0/24]:Network=172.16.146.0 force C set [from-172.16.146.0/24]:Netmask=255.255.255.0 force C set [to-172.16.0.0/16]:ID-type=IPV4_ADDR_SUBNET force C set [to-172.16.0.0/16]:Network=172.16.0.0 force C set [to-172.16.0.0/16]:Netmask=255.255.0.0 force C add [Phase 2]:Connections=from-172.16.146.0/24-to-172.16.0.0/16 fw-donmilani# Giacomo Marconi - Ufficio Servizi Informativi Comune di Arezzo 0575 377790 345 0305792
Re: no pcap file from isakmpd in OBSD6.6
Christoph Leser wrote:
Hi,
after upgrading openbsd6.5 to oopenbsd6.6 using sysupgrade isakmpd
does no longer write pcap files in /var/run.
In /var/log/messages we see the following message:
isakmpd[7385]: log_packet_init: fopen ("/var/run/isakmpd.pcap", "w")
failed: Permission denied
On 2019-12-03 19:30, Theo de Raadt wrote:
m_priv_local_sanitize_path() contains some realpath() checks.
I think this is either exposing realpath() abuse( as a result of the
new in-kernel realpath to support unveil better), or it is hitting the
realpath() bug which was fixed post-release?
I get similar message when trying to report information about SAs to
isakmpd.results through isakmpd.fifo on 6.6.
echo "S" > /var/run/isakmpd.fifo
...(as root) doesn't return anything, doesn't create results file, and
gives error message in log:
Feb 6 21:20:16 kerber isakmpd[36105]: ui_open_result: fopen() failed:
Permission denied
If someone knows about some workaround for obtaining isakmpd.results
on 6.6 I'd be very grateful (or at least binary patch :D )
--
Before enlightenment - chop wood, draw water.
After enlightenment - chop wood, draw water.
Marko Cupać
https://www.mimar.rs/
Re: no pcap file from isakmpd in OBSD6.6
m_priv_local_sanitize_path() contains some realpath() checks.
I think this is either exposing realpath() abuse( as a result of the
new in-kernel realpath to support unveil better), or it is hitting the
realpath() bug which was fixed post-release?
Christoph Leser wrote:
> Hi,
>
> after upgrading openbsd6.5 to oopenbsd6.6 using sysupgrade isakmpd does no
> longer write pcap files in /var/run.
>
> In /var/log/messages we see the following message:
>
> isakmpd[7385]: log_packet_init: fopen ("/var/run/isakmpd.pcap", "w") failed:
> Permission denied
>
> Any ideas?
>
> Mit freundlichen GrüÃen / Best regards / Meilleures salutations
>
>
> Christoph Leser
> Systemtechnik
>
>
> S&P Computersysteme GmbH
> Systemhaus für Logistik
> Zettachring 4
> 70567Stuttgart
> www.sup-logistik.de
>
> T: +49 711 726 41-0
> F: +49 711 726 41-70
> christoph.le...@sup-logistik.de
>
>
> Â Â Â
>
> Amtsgericht Stuttgart HRB 11921
> Geschäftsführer: Horst Reichert, Rémy El Abd
>
> Informationspflicht zur Datenverarbeitung:
> Kunden:Â Hier >>Â
> Dienstleister / Lieferanten: Hier>>
>
no pcap file from isakmpd in OBSD6.6
Hi,
after upgrading openbsd6.5 to oopenbsd6.6 using sysupgrade isakmpd does no
longer write pcap files in /var/run.
In /var/log/messages we see the following message:
isakmpd[7385]: log_packet_init: fopen ("/var/run/isakmpd.pcap", "w") failed:
Permission denied
Any ideas?
Mit freundlichen Grüßen / Best regards / Meilleures salutations
Christoph Leser
Systemtechnik
S&P Computersysteme GmbH
Systemhaus für Logistik
Zettachring 4
70567Stuttgart
www.sup-logistik.de
T: +49 711 726 41-0
F: +49 711 726 41-70
christoph.le...@sup-logistik.de
Amtsgericht Stuttgart HRB 11921
Geschäftsführer: Horst Reichert, Rémy El Abd
Informationspflicht zur Datenverarbeitung:
Kunden: Hier >>
Dienstleister / Lieferanten: Hier>>
Re: isakmpd and iked on the same box
Tommy Nevtelen wrote on 31-8-2018 16:12: On 2018-08-31 10:44, Daniel Polak wrote: Tommy Nevtelen wrote on 30-8-2018 23:13: We use isakmpd to interconnect 30ish routers and I would like to switch to iked, but since there is no support to run both at the same time it makes it quite hard to migrate slowly. Will basically need to do it all at the same time and that is not very good for SLAs which complicates things. Or am I missing something? Would it work for you to add a separate VPN gateway with iked next to the VPN gateway running isakmpd? If you do that you can then set routes to direct traffic for networks that have migrated to ikev2 to the iked gateway. Sure, there are many solutions. But that is kind of a lot of work and investment in hardware compared to just running both at the same time right? Of course it is but if the work on and the investment in software has not been done for you by the OpenBSD developers (or sometimes their sponsors) then that's how it is. Needs must.
Re: isakmpd and iked on the same box
Hello Philipp, I use to (reliably) run from two to four parallel instances of isakmpd on same boxes (for years) - first using different ports, then different IPs. It seems like they've had to (peacefully) share the SADB. Did I just not have enough tunnels to trigger the problem? If this isn't the case, why can't iked be as "nice" as isakmpd? Just wondering. Thursday, August 30, 2018, 10:39:21 AM, you wrote: PB> Hi, PB> Am 30.08.2018 10:27 schrieb Sebastian Reitenbach: >> Hi, >> >> I'm wondering if it would be possible to add iked to my box already >> running isakmpd. >> I found this quite old thread: >> http://openbsd-archive.7691.n7.nabble.com/iked-isakmpd-on-the-same-machine-td246610.html PB> Why is it "always" my old threads in this area? :-) PB> I was not following development too closely, but I think that on the PB> kernel side PB> things have not changed. Which means iked and isakmpd will happily "toe PB> tap" PB> on each others SADB in the kernel (even if there is *some* PID PB> handling). PB> Would like to hear if kernel side has "improved" lately, but the overall PB> standpoint PB> looks like: IKEv1 is dead (e.g. see the removal of IKEv1 stubs in iked PB> some "months ago"). PB> [Still stuck with my ikev2 with strongswan on a different box solution] PB> HTH... wait, no: PB> ciao -- Best regards, Borismailto:psi...@prodigy.net
Re: isakmpd and iked on the same box
On 2018-08-31 10:44, Daniel Polak wrote: Tommy Nevtelen wrote on 30-8-2018 23:13: We use isakmpd to interconnect 30ish routers and I would like to switch to iked, but since there is no support to run both at the same time it makes it quite hard to migrate slowly. Will basically need to do it all at the same time and that is not very good for SLAs which complicates things. Or am I missing something? Would it work for you to add a separate VPN gateway with iked next to the VPN gateway running isakmpd? If you do that you can then set routes to direct traffic for networks that have migrated to ikev2 to the iked gateway. Sure, there are many solutions. But that is kind of a lot of work and investment in hardware compared to just running both at the same time right? -- Tommy
Re: isakmpd and iked on the same box
Am Donnerstag, August 30, 2018 17:39 CEST, Philipp Buehler schrieb: > Hi, > > Am 30.08.2018 10:27 schrieb Sebastian Reitenbach: > > Hi, > > > > I'm wondering if it would be possible to add iked to my box already > > running isakmpd. > > I found this quite old thread: > > http://openbsd-archive.7691.n7.nabble.com/iked-isakmpd-on-the-same-machine-td246610.html > > Why is it "always" my old threads in this area? :-) > > I was not following development too closely, but I think that on the > kernel side > things have not changed. Which means iked and isakmpd will happily "toe > tap" > on each others SADB in the kernel (even if there is *some* PID > handling). > > Would like to hear if kernel side has "improved" lately, but the overall > standpoint > looks like: IKEv1 is dead (e.g. see the removal of IKEv1 stubs in iked > some "months ago"). > > [Still stuck with my ikev2 with strongswan on a different box solution] isakmpd and iked on separate nodes still seems to be the way to go. thanks everyone. Sebastian > > HTH... wait, no: > ciao > -- > pb
Re: isakmpd and iked on the same box
Tommy Nevtelen wrote on 30-8-2018 23:13: We use isakmpd to interconnect 30ish routers and I would like to switch to iked, but since there is no support to run both at the same time it makes it quite hard to migrate slowly. Will basically need to do it all at the same time and that is not very good for SLAs which complicates things. Or am I missing something? Would it work for you to add a separate VPN gateway with iked next to the VPN gateway running isakmpd? If you do that you can then set routes to direct traffic for networks that have migrated to ikev2 to the iked gateway.
Re: isakmpd and iked on the same box
On 2018-08-30 22:06, Daniel Polak wrote: > On 30/08/2018 17:39, Philipp Buehler wrote: >> I was not following development too closely, but I think that on the >> kernel side >> things have not changed. Which means iked and isakmpd will happily >> "toe tap" >> on each others SADB in the kernel (even if there is *some* PID >> handling). >> >> Would like to hear if kernel side has "improved" lately, but the >> overall standpoint >> looks like: IKEv1 is dead (e.g. see the removal of IKEv1 stubs in >> iked some "months ago"). > Why would IKEv1 be dead if the stubs were removed from iked? There is > still isakmpd and that works pretty well. > > Also I see many companies that still use IKEv1 and it would be > unpleasant if there was no way to connect to them with OpenBSD. We use isakmpd to interconnect 30ish routers and I would like to switch to iked, but since there is no support to run both at the same time it makes it quite hard to migrate slowly. Will basically need to do it all at the same time and that is not very good for SLAs which complicates things. Or am I missing something? -- Tommy
Re: isakmpd and iked on the same box
On 30/08/2018 17:39, Philipp Buehler wrote: I was not following development too closely, but I think that on the kernel side things have not changed. Which means iked and isakmpd will happily "toe tap" on each others SADB in the kernel (even if there is *some* PID handling). Would like to hear if kernel side has "improved" lately, but the overall standpoint looks like: IKEv1 is dead (e.g. see the removal of IKEv1 stubs in iked some "months ago"). Why would IKEv1 be dead if the stubs were removed from iked? There is still isakmpd and that works pretty well. Also I see many companies that still use IKEv1 and it would be unpleasant if there was no way to connect to them with OpenBSD. Daniel
Re: isakmpd and iked on the same box
Hi, Am 30.08.2018 10:27 schrieb Sebastian Reitenbach: Hi, I'm wondering if it would be possible to add iked to my box already running isakmpd. I found this quite old thread: http://openbsd-archive.7691.n7.nabble.com/iked-isakmpd-on-the-same-machine-td246610.html Why is it "always" my old threads in this area? :-) I was not following development too closely, but I think that on the kernel side things have not changed. Which means iked and isakmpd will happily "toe tap" on each others SADB in the kernel (even if there is *some* PID handling). Would like to hear if kernel side has "improved" lately, but the overall standpoint looks like: IKEv1 is dead (e.g. see the removal of IKEv1 stubs in iked some "months ago"). [Still stuck with my ikev2 with strongswan on a different box solution] HTH... wait, no: ciao -- pb
isakmpd and iked on the same box
Hi, I'm wondering if it would be possible to add iked to my box already running isakmpd. I found this quite old thread: http://openbsd-archive.7691.n7.nabble.com/iked-isakmpd-on-the-same-machine-td246610.html just checking to see if things might have changed since then. Ive a vio0 interface with two IPs: 10.0.0.52 and 192.168.0.4: so I've isakmpd running, binding it to a specific IP like this: [General] Listen-on= 10.0.0.52 Default-phase-1-lifetime= 28800,60:86400 Default-phase-2-lifetime= 1200,60:86400 DPD-check-interval= 10 Policy-File= /etc/isakmpd/isakmpd.policy so with isakmpd, I'm used to use ipsecctl and have multiple /etc/ipsec.conf.tunnelXYZ files around, so that I can up/down etc. single tunnels without affecting the others. now adding iked with following config: ikev2 "just a test" \ esp proto tcp \ from 192.168.66.0/24 to 192.168.77.0/24 \ peer 172.16.0.3 local 192.166.0.4 starting up iked works. However, it binds to *:500 and *:4500 so care has to be taken to start it after isakmpd, otherwise isakmpd would refuse to start. I used the "local" keyword to see if iked would only bind to that specific address, but it doesn't. Looking at ikectl manpage, I only see the "load ". So I could specify alternate configuration files, but that would affect the overall iked configuration, I cannot add/remove single tunnel instances to iked? I've seen that in iked.conf, I can specify names for the flows, but I guess that's only for easier identification, I cannot use these names to trigger a start/stop/restart of a given flow? I haven't used iked before, so far, isakmpd was sufficient, so I'm a bit curious, and might miss something about iked it in general. Also isakmpd/iked, and ipsecctl/ikectl work on the same kernel resources, do they step onto each others toes? Also, if not possible to run iked and isakmpd together on the same node, no big deal, can easily run on separate nodes, just wanted to ensure I don't miss anything. thanks, Sebastian
isakmpd: dropped message from 192.168.1.1 port 500 due to notification type INVALID_FLAGS
Dear Friends, IPSEC+L2TP fails with the following messages on IPSEC router: isakmpd[76756]: message_recv: cleartext phase 2 isakmpd[76756]: dropped message from 192.168.1.1 port 500 due to notification type INVALID_FLAGS Aug 17 isakmpd[76756]: transport_send_messages: giving up on exchange peer-default, no response from peer 192.168.1.1:500 Aug 17 isakmpd[76756]: message_recv: cleartext phase 2 message My setup is as follows: Road-warrior client L2TP + IPSEC (Linux ou Mac) + Internet provider router (192.168.1.1 and a public IP) Redirected ports UPD 500 + 4500 to 192.168.1.2 + OpenBSD 6.3 Ipsec router (192.168.1.2) ipsec.conf configuration on 192.168.1.2 is : ike passive esp tunnel from 192.168.1.2 to any \ main group "modp2048" \ quick group "modp2048" \ psk "xx" L2TP connections from the local network 192.168.1.0 work very well using Linux or Mac OS X so my configuration with PPP authentication is OKay. It is only when I connect from a remote location that it does not work. Pf rules are working and allow incoming connections as I see no rejected packets from the logs. At some point during IPSEC phase 2 negociation, IPSEC queries 192.168.1.1:500 but this does not work as 192.168.1.1 is the private address from my Internet provider router and port 500 is not redirected on 192.168.1.1 only on public IP. Do you know how to fix this and make it work? Kind regards, -- Jean-Michel Pouré
ISAKMPD crashed on OpenBSD 6.2
Hello I have a very simple isakampd.conf configuration for a VPN to AWS. I'm able to bring up the VPN but it crashed 15 minutes later. When ISAKMP crashed, I unable to ping outside or ping the machine until I kill isakmp process. Any ideas? -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html
Re: OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
Hello Philipp, hello @misc I thought the problems were gone, but often deleting an unmamed phase 1 SA didn't work with the "cookie method" at least with 6.3/amd64. My way: 1.) # sh -c "echo S > /var/run/isakmpd.fifo" # less /var/run/isakmpd.result --> identify the dead phase 1 SA SA name: (Phase 1/Responder) src: dst: Lifetime: 28800 seconds Flags 0x icookie 7e0aab1278867246 rcookie f26398203e60007f 2.) try to delete the unnamed SA with your method: # sh -c "echo 'd 7e0aab1278867246f26398203e60007f -' \ > /var/run/isakmpd.fifo" results mostly in: ui_delete: command "d 7e0aab1278867246f26398203e60007f -" found no SA 3.) collateral problem: I'm not able to accept a new connection by the remote peer (with a new cookie) because isakmpd logs: transport_send_messages: giving up on exchange peer-, no response from peer . With tcpdump I can see that isakmpd refuses to answer peer requests 'till lifetime end or the crippled phase 1 is totally dropped... Resarting isakmpd is not advised 'cause of a lot of other active vpn sessions. The question: isakmpd bug or may brain incapabillities? Best regards Andre Am 15.05.18 um 05:15 schrieb Philipp Buehler: Hello Andre, Am 14.05.2018 13:38 schrieb Andre Ruppert: I got the tips from this 2013 undeadly.org article: Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway https://undeadly.org/cgi?action=article&sid=20131125041429 Apparently I wrote that article, and I feel your pain :-) 2.) less /var/run/isakmpd.result ... SA name: (Phase 1/Responder) src: dst: Flags 0x icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec ... Feeding the fifo with sh -c "echo 't ' > /var/run/isakmpd.fifo" only deletes phase 2. But I didn't have an SA name at this time... ?? The problem here is you only have an 'unnamed' SA, indeed; but you have cookies.. What you can do - found that a bit later after the undeadly article: echo 'd 9f5bf7497f0ebe108a6c7b1b1f5923ec -' > isakmpd.fifo which is "d $icookie$rcookie -" (no space between the cookie values). If I am changing a peer configuration, I also block 500/udp for the time being to avoid these 'Responder' SAs altogether. Think along pf.conf:pass in proto udp from to $myself port 500 pfctl -T delete -t vpn_peers $thatpeer pfctl -k $thatpeer ipsecctl -d -f $thatpeer.conf vi $thatpeer.conf ipsecctl -f $thatpeer.conf pfctl -T add -t vpn_peers $thatpeer HTH, smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
Hello Philipp, sorry for the late answer Thanks for the hint with the cookies. Works in my environment I'm much happier now ;-) Best regards Andre Am 15.05.18 um 05:15 schrieb Philipp Buehler: Hello Andre, Am 14.05.2018 13:38 schrieb Andre Ruppert: I got the tips from this 2013 undeadly.org article: Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway https://undeadly.org/cgi?action=article&sid=20131125041429 Apparently I wrote that article, and I feel your pain :-) 2.) less /var/run/isakmpd.result ... SA name: (Phase 1/Responder) src: dst: Flags 0x icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec ... Feeding the fifo with sh -c "echo 't ' > /var/run/isakmpd.fifo" only deletes phase 2. But I didn't have an SA name at this time... ?? The problem here is you only have an 'unnamed' SA, indeed; but you have cookies.. What you can do - found that a bit later after the undeadly article: echo 'd 9f5bf7497f0ebe108a6c7b1b1f5923ec -' > isakmpd.fifo which is "d $icookie$rcookie -" (no space between the cookie values). If I am changing a peer configuration, I also block 500/udp for the time being to avoid these 'Responder' SAs altogether. Think along pf.conf:pass in proto udp from to $myself port 500 pfctl -T delete -t vpn_peers $thatpeer pfctl -k $thatpeer ipsecctl -d -f $thatpeer.conf vi $thatpeer.conf ipsecctl -f $thatpeer.conf pfctl -T add -t vpn_peers $thatpeer HTH, smime.p7s Description: S/MIME Cryptographic Signature
Re: OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
Hello Andre, Am 14.05.2018 13:38 schrieb Andre Ruppert: I got the tips from this 2013 undeadly.org article: Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway https://undeadly.org/cgi?action=article&sid=20131125041429 Apparently I wrote that article, and I feel your pain :-) 2.) less /var/run/isakmpd.result ... SA name: (Phase 1/Responder) src: dst: Flags 0x icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec ... Feeding the fifo with sh -c "echo 't ' > /var/run/isakmpd.fifo" only deletes phase 2. But I didn't have an SA name at this time... ?? The problem here is you only have an 'unnamed' SA, indeed; but you have cookies.. What you can do - found that a bit later after the undeadly article: echo 'd 9f5bf7497f0ebe108a6c7b1b1f5923ec -' > isakmpd.fifo which is "d $icookie$rcookie -" (no space between the cookie values). If I am changing a peer configuration, I also block 500/udp for the time being to avoid these 'Responder' SAs altogether. Think along pf.conf:pass in proto udp from to $myself port 500 pfctl -T delete -t vpn_peers $thatpeer pfctl -k $thatpeer ipsecctl -d -f $thatpeer.conf vi $thatpeer.conf ipsecctl -f $thatpeer.conf pfctl -T add -t vpn_peers $thatpeer HTH, -- pb
Re: OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
Remark below... Am 14.05.18 um 13:38 schrieb Andre Ruppert: Hello @misc, I use a CARPed pair of 6.2 gateways as vpn access nodes, running "plain" ISAKMPD/ipsec. The peering vpn gateways have different brandings from OpenBSD, linux, cisco to watchguard appliances etc... Interoperability works most like a charm and is a no-brainer in most cases. I have only access to the OpenBSD peering gateways, but most other brands belong to partners / customers. Sometimes I first have problems with some of these peering boxes and only partial tunnels came up (only phase 1 or - more bad - phase 1 only partial). Then I check the logs and - if I got wrong credentials or parameters from the peering partner - I change the configs on my side. It needs mostly much less time than to discuss with the technicians from the peering partners - their problems have to te solved by them by clicking somewhere in a webinterface *sigh*. Ok, back to _my_ problem: If a ipsec tunnel is running with phase 1 and 2, I can stop it with "ipsecctl -d -f ". Works. If the ipsec tunnel is only partial working, I can delete it by using the fifo mechanism. Sometimes. ( I got the tips from this 2013 undeadly.org article: Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway https://undeadly.org/cgi?action=article&sid=20131125041429 ) But I have always problems if only a part of phase 1 came up. 1.) sh -c "echo S > /var/run/isakmpd.fifo" 2.) less /var/run/isakmpd.result ... SA name: (Phase 1/Responder) src: dst: Flags 0x icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec ... Feeding the fifo with sh -c "echo 't ' > /var/run/isakmpd.fifo" only deletes phase 2. But I didn't have an SA name at this time... ?? Question to the community: how is it possible to reliable stop partial tunnels without restarting isakmpd/ipsec (e.g. disturbing all other running tunnels)? I'm clueless Best regards Andre ...and sh -c "echo 't main ' > /var/run/isakmpd.fifo" doesn't work either ... /var/log/daemon reports "...ui_teardown: teardown connection "", phase 1 but that doesn't do anything. Man isakmpd reads for fifo using: "t [phase] name" Tear down the named connection, if active. For name, the tag specified in isakmpd.conf(5) or the IP address of the remote host can be used. Hm. Again clueless... Best regards Andre smime.p7s Description: S/MIME Cryptographic Signature
OpenBSD 6.2: how to tear down partial ipsec tunnels without restarting ipsec/isakmpd?
Hello @misc, I use a CARPed pair of 6.2 gateways as vpn access nodes, running "plain" ISAKMPD/ipsec. The peering vpn gateways have different brandings from OpenBSD, linux, cisco to watchguard appliances etc... Interoperability works most like a charm and is a no-brainer in most cases. I have only access to the OpenBSD peering gateways, but most other brands belong to partners / customers. Sometimes I first have problems with some of these peering boxes and only partial tunnels came up (only phase 1 or - more bad - phase 1 only partial). Then I check the logs and - if I got wrong credentials or parameters from the peering partner - I change the configs on my side. It needs mostly much less time than to discuss with the technicians from the peering partners - their problems have to te solved by them by clicking somewhere in a webinterface *sigh*. Ok, back to _my_ problem: If a ipsec tunnel is running with phase 1 and 2, I can stop it with "ipsecctl -d -f ". Works. If the ipsec tunnel is only partial working, I can delete it by using the fifo mechanism. Sometimes. ( I got the tips from this 2013 undeadly.org article: Managing Individual IPsec Tunnels On A Multi-Tunnel Gateway https://undeadly.org/cgi?action=article&sid=20131125041429 ) But I have always problems if only a part of phase 1 came up. 1.) sh -c "echo S > /var/run/isakmpd.fifo" 2.) less /var/run/isakmpd.result ... SA name: (Phase 1/Responder) src: dst: Flags 0x icookie 9f5bf7497f0ebe10 rcookie 8a6c7b1b1f5923ec ... Feeding the fifo with sh -c "echo 't ' > /var/run/isakmpd.fifo" only deletes phase 2. But I didn't have an SA name at this time... ?? Question to the community: how is it possible to reliable stop partial tunnels without restarting isakmpd/ipsec (e.g. disturbing all other running tunnels)? I'm clueless Best regards Andre
Re: IPsec/ISAKMP-trouble after Upgrade 6.0 --> 6.1 --> 6.2 amd64 : ISAKMPD: got AES_CBC, expected 3DES_CBC
Fri, 16 Mar 2018 13:25:49 +0100 Janne Johansson : > 2018-03-16 12:26 GMT+01:00 Andre Ruppert : > > > Hello @misc, > > > > after a nightly release upgrade of our VPN-Gateway(s) from 6.0 via > > 6.1 to 6.2 (amd64) I noticed some trouble with my VPN connections. > > > > Almost always when you get "expected 3DES" it means "the confs are not > matching so obsd chose some default thing which includes 3DES > which is not what the other side is running". > > Things like mixing up "from NetA to NetB" and the other side not > having the exact opposite is a decent way to get that exact error. > > I don't know what part changed so that it is no longer matching for > you, but something makes the negotiations not think > the remote proposal is what it expects, so it goes into some default > mode from which it will never make a connection. > I agree with you in principle, but the question is: why drop these connections (with untouched configurations) sporadically with 6.2 and _not_ with 6.0? Some of these connections drop several times in 24h. No problems at all with 6.0. And it's always the same behavior: first drops the esp tunnel and the esp flows remain active. And its not possible to stop them with 'ipsecctl -d -f ' Is it only possible to stop zombie-type flows with fifo commands? Best regards Andre
Re: IPsec/ISAKMP-trouble after Upgrade 6.0 --> 6.1 --> 6.2 amd64 : ISAKMPD: got AES_CBC, expected 3DES_CBC
2018-03-16 12:26 GMT+01:00 Andre Ruppert : > Hello @misc, > > after a nightly release upgrade of our VPN-Gateway(s) from 6.0 via 6.1 to > 6.2 (amd64) I noticed some trouble with my VPN connections. > Almost always when you get "expected 3DES" it means "the confs are not matching so obsd chose some default thing which includes 3DES which is not what the other side is running". Things like mixing up "from NetA to NetB" and the other side not having the exact opposite is a decent way to get that exact error. I don't know what part changed so that it is no longer matching for you, but something makes the negotiations not think the remote proposal is what it expects, so it goes into some default mode from which it will never make a connection. -- May the most significant bit of your life be positive.
IPsec/ISAKMP-trouble after Upgrade 6.0 --> 6.1 --> 6.2 amd64 : ISAKMPD: got AES_CBC, expected 3DES_CBC
Hello @misc, after a nightly release upgrade of our VPN-Gateway(s) from 6.0 via 6.1 to 6.2 (amd64) I noticed some trouble with my VPN connections. Scenario: - a CARPed OpenBSD VPN gateway with sasyncd (master and backup) - a bunch of customer VPN client gateways (several brands -> Sophos, Fortigate, Cisco , ... ). - ISAKMPD/ipsec (no iked yet) - no syntax errors in ipsec.conf files (checked) - with release 6.0 no problems at all. - with 6.2 sometimes several of the connections drop nearly at the same time and I have do restart them manually. Configuration: ipsec.conf includes - configuration is pretty simple - one include-file for every connection: # -- LOCAL_PEER = "IP_of_my_gateway" LOCAL_NET = "my_network/mask bits" REMOTE_NET_XY = "foreign_network_YX/mask bits" REMOTE_PEER_XY = "IP_of_remote_gateway" ike esp from $LOCAL_NET to $REMOTE_NET_XY \ peer $REMOTE_PEER_XY \ main auth hmac-sha2-256 enc aes-256 group modp1536 lifetime 3600 \ quick auth hmac-sha2-256 enc aes-256 group modp1536 lifetime 1200 \ srcid $LOCAL_PEER psk "SomethingTotalSecretAsPSKsCanBe" Single VPNs are startet by "ipsecctl -f /etc/ipsec/ipsec.include.xy" and deleted by "ipsecctl -d -f /etc/ipsec/ipsec.include.xy) (Deleting connections is a special matter and doesn't work well, but that is not the point here) The problem so far: prior to the connection drops I see isakmpd error messages: isakmpd[35939]: dropped message from "REMOTE_PEER_XY" port 500 due to notification type NO_PROPOSAL_CHOSEN isakmpd[35939]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC isakmpd[35939]: message_negotiate_sa: no compatible proposal found My question: why (and where) do I expect 3DES_CBC encrytion ? And sometimes also other additional error messages appear in the Log. Example: ... ipsec_get_id: section to-10.10.244.0/25 has no "ID-type" tag Mar 16 08:06:11 redacc01-a isakmpd[35939]: connection_init: could not record connection "from-172.16.0.0/16-to-10.10.244.0/25" ... I'm clueless... There are no infos in the upgrade guides (6.0 to 6.1 and 6.1 to 6.2) concerning isakmpd/ipsec changes Sysctl lists: net.inet.ip.ipsec-expire-acquire=30 net.inet.ip.ipsec-invalid-life=60 net.inet.ip.ipsec-pfs=1 net.inet.ip.ipsec-soft-allocs=0 net.inet.ip.ipsec-allocs=0 net.inet.ip.ipsec-soft-bytes=0 net.inet.ip.ipsec-bytes=0 net.inet.ip.ipsec-timeout=86400 net.inet.ip.ipsec-soft-timeout=8 net.inet.ip.ipsec-soft-firstuse=3600 net.inet.ip.ipsec-firstuse=7200 net.inet.ip.ipsec-enc-alg=aes net.inet.ip.ipsec-auth-alg=hmac-sha1 net.inet.ip.ipsec-comp-alg=deflate Any hints? Best regards Andre Ruppert smime.p7s Description: S/MIME Cryptographic Signature
Re: isakmpd ignoring contents of /etc/ipsec.conf
Am 2017-12-07 13:34, schrieb Jeremie Courreges-Anglas: On Thu, Dec 07 2017, Bernd wrote: Am 2017-12-06 18:26, schrieb Jeremie Courreges-Anglas: On Wed, Dec 06 2017, Bernd wrote: [...] As a result, the IPSec tunnel can not be established. What did I overlook here? Looks like ipsec.conf(5) was not loaded, see the manpage, paragraph 4 of DESCRIPTION. Hi, ipsec=YES is set in rc.conf.local: # cat /etc/rc.conf.local isakmpd_flags="-K" ipsec=YES # IPsec OK, then let's go back to your config: did you test it for validity? ritchie ~$ cat /tmp/ipsec.conf ike esp from any to any peer 192.0.2.1/27 \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ psk "myverygoodsecretPSK" ritchie ~$ ipsecctl -nvf /tmp/ipsec.conf /tmp/ipsec.conf: 1: syntax error ipsecctl: Syntax error in config file: ipsec rules not loaded ritchie ~$ Drop the /27 and ipsecctl(8) is happy. It seems weird to specify a netmask as a "peer", maybe you should reconsider what you're using "peer" for. Yes, thanks, it was indeed the netmask. Tunnel was up and running. However, in the meanwhile our customer forced us – "due to legal reasons" – to use Cisco equipment. Thanks Bernd
Re: isakmpd ignoring contents of /etc/ipsec.conf
On Thu, Dec 07 2017, Bernd wrote: > Am 2017-12-06 18:26, schrieb Jeremie Courreges-Anglas: >> On Wed, Dec 06 2017, Bernd wrote: [...] >>> As a result, the IPSec tunnel can not be established. What did >>> I overlook here? >> >> Looks like ipsec.conf(5) was not loaded, see the manpage, paragraph >> 4 of >> DESCRIPTION. > > Hi, > > ipsec=YES is set in rc.conf.local: > > # cat /etc/rc.conf.local > isakmpd_flags="-K" > ipsec=YES # IPsec OK, then let's go back to your config: did you test it for validity? ritchie ~$ cat /tmp/ipsec.conf ike esp from any to any peer 192.0.2.1/27 \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ psk "myverygoodsecretPSK" ritchie ~$ ipsecctl -nvf /tmp/ipsec.conf /tmp/ipsec.conf: 1: syntax error ipsecctl: Syntax error in config file: ipsec rules not loaded ritchie ~$ Drop the /27 and ipsecctl(8) is happy. It seems weird to specify a netmask as a "peer", maybe you should reconsider what you're using "peer" for. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: isakmpd ignoring contents of /etc/ipsec.conf
Am 2017-12-06 18:26, schrieb Jeremie Courreges-Anglas: On Wed, Dec 06 2017, Bernd wrote: Hi @misc, I'm trying to set up a site-to-site IPSec tunnel. I'm using vanilla OpenBSD 6.2 amd64 (dmesg below). My /etc/ipsec.conf looks like this: ike esp from any to any peer x.y.z.0/27 \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ psk "myverygoodsecretPSK" (As can be seen, I want the settings to be applied to a /27 network, from where the tunnel initiation is sent out of. I also tried to use a fixed, single IP address, i.e. x.y.z.23, and tried to fire up IPSec from there – it also failed.) isakmpd is being started as described in ipsec.conf(5) et al: ``-K'' set as its flag(s) in /etc/rc.conf.local However, it seems to ignore the settings made in ipsec.conf (without complaining about them, though): Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_1536, expected MODP_1024 Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_768, expected MODP_1024 Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024 Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: message_negotiate_sa: no compatible proposal found Dec 1 14:01:20 myhostname isakmpd[55480]: dropped message from x.y.z.1 port 500 due to notification type NO_PROPOSAL_CHOSEN For example, ENCRYPTION_ALGORITHM is clearly not what was set in /etc/ipsec.conf, but rather a default. Same applies to GROUP_DESCRIPTION and HASH_ALGORITHM. As a result, the IPSec tunnel can not be established. What did I overlook here? Looks like ipsec.conf(5) was not loaded, see the manpage, paragraph 4 of DESCRIPTION. Hi, ipsec=YES is set in rc.conf.local: # cat /etc/rc.conf.local isakmpd_flags="-K" ipsec=YES # IPsec # sysctl -a | grep ipsec net.inet.ip.ipsec-expire-acquire=30 net.inet.ip.ipsec-invalid-life=60 net.inet.ip.ipsec-pfs=1 net.inet.ip.ipsec-soft-allocs=0 net.inet.ip.ipsec-allocs=0 net.inet.ip.ipsec-soft-bytes=0 net.inet.ip.ipsec-bytes=0 net.inet.ip.ipsec-timeout=86400 net.inet.ip.ipsec-soft-timeout=8 net.inet.ip.ipsec-soft-firstuse=3600 net.inet.ip.ipsec-firstuse=7200 net.inet.ip.ipsec-enc-alg=aes net.inet.ip.ipsec-auth-alg=hmac-sha1 net.inet.ip.ipsec-comp-alg=deflate Best Bernd
Re: isakmpd ignoring contents of /etc/ipsec.conf
On Wed, Dec 06 2017, Bernd wrote: > Hi @misc, > > I'm trying to set up a site-to-site IPSec tunnel. I'm using vanilla > OpenBSD 6.2 amd64 (dmesg below). > > My /etc/ipsec.conf looks like this: > > ike esp from any to any peer x.y.z.0/27 \ > main auth hmac-sha2-256 enc aes-256 group modp2048 \ > psk "myverygoodsecretPSK" > > (As can be seen, I want the settings to be applied to a /27 network, > from where the tunnel initiation is sent out of. I also tried to use > a fixed, single IP address, i.e. x.y.z.23, and tried to fire up IPSec > from there – it also failed.) > > isakmpd is being started as described in ipsec.conf(5) et al: ``-K'' set > as its flag(s) in /etc/rc.conf.local > > However, it seems to ignore the settings made in ipsec.conf (without > complaining about them, though): > > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > GROUP_DESCRIPTION: got MODP_1536, expected MODP_1024 > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > HASH_ALGORITHM: got MD5, expected SHA > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > HASH_ALGORITHM: got MD5, expected SHA > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > HASH_ALGORITHM: got SHA2_256, expected SHA > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > GROUP_DESCRIPTION: got MODP_768, expected MODP_1024 > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > HASH_ALGORITHM: got SHA2_256, expected SHA > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024 > Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: > ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC > Dec 1 14:01:20 myhostname isakmpd[55480]: message_negotiate_sa: no > compatible proposal found > Dec 1 14:01:20 myhostname isakmpd[55480]: dropped message from x.y.z.1 > port 500 due to notification type NO_PROPOSAL_CHOSEN > > For example, ENCRYPTION_ALGORITHM is clearly not what was set in > /etc/ipsec.conf, but rather a default. Same applies to GROUP_DESCRIPTION > and HASH_ALGORITHM. > > As a result, the IPSec tunnel can not be established. What did > I overlook here? Looks like ipsec.conf(5) was not loaded, see the manpage, paragraph 4 of DESCRIPTION. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
isakmpd ignoring contents of /etc/ipsec.conf
Hi @misc, I'm trying to set up a site-to-site IPSec tunnel. I'm using vanilla OpenBSD 6.2 amd64 (dmesg below). My /etc/ipsec.conf looks like this: ike esp from any to any peer x.y.z.0/27 \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ psk "myverygoodsecretPSK" (As can be seen, I want the settings to be applied to a /27 network, from where the tunnel initiation is sent out of. I also tried to use a fixed, single IP address, i.e. x.y.z.23, and tried to fire up IPSec from there – it also failed.) isakmpd is being started as described in ipsec.conf(5) et al: ``-K'' set as its flag(s) in /etc/rc.conf.local However, it seems to ignore the settings made in ipsec.conf (without complaining about them, though): Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_1536, expected MODP_1024 Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_768, expected MODP_1024 Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024 Dec 1 14:01:20 myhostname isakmpd[55480]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Dec 1 14:01:20 myhostname isakmpd[55480]: message_negotiate_sa: no compatible proposal found Dec 1 14:01:20 myhostname isakmpd[55480]: dropped message from x.y.z.1 port 500 due to notification type NO_PROPOSAL_CHOSEN For example, ENCRYPTION_ALGORITHM is clearly not what was set in /etc/ipsec.conf, but rather a default. Same applies to GROUP_DESCRIPTION and HASH_ALGORITHM. As a result, the IPSec tunnel can not be established. What did I overlook here? Thanks in advance for any hints. Best Bernd
Re: IPsec (isakmpd) in rdomain non zero needs default route
On 2017-09-29, BARDOU Pierre wrote: > Hello, > > I don't know if I should post this to misc@ or bugs@... > If this is the wrong list tell me I'll file a proper bug report. > > I need to add a default route in rdomain 1 to be able to use the tunnels > created by isakmpd. > That is a bit weird, routes should be injected by isakmpd. It's more of a feature request than a bug - the IPsec implementations on OpenBSD only work with flows, there isn't a nice way to use them with routes. It would be extremely useful though, especially in conjunction with dynamic routing. For example: it would allow a cluster of health-checked IPsec gateways behind relayd, advertising client routes to the rest of your network via bgp/ospf. Sure it relies on NAT-T and DPD to notice when a gateway goes down, but then there's no horrible mess syncing the SADB between machines. > My guess is that the problem is quite the same as with inter-domain > routing with PF : destination lookup is done BEFORE processing by PF or > IPSEC (explained here for PF : > https://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/). > So when there is no default route, it fails. There doesn't need to be a *default* route, but there must be *a* route for the flow destination. > If this guess is right, the problem shoud also happen on rdomain 0. Yes. > Could you fix the code to make it work without the default route ? What you propose here would mean changing pieces deep in the network stack with tentacles in various subsystems. > Or, as I suspect, is this too difficult and I'll go with my workaround ? There are ways to get IPsec working with routes, but not really nice ones: - you can configure a gif or gre tunnel on top of IKE & IPsec transport mode at both sides, but it's a two-step config, and the other side needs to support gif/gre. - you can configure a gif tunnel with IPsec transport mode at one end, and the other end can be normally configured with tunnel mode if you like (so you can use some endpoint at the other side that doesn't explicitly support gif). This works because gif(4) tunnel headers are *identical* to the IPsec tunnel mode ones. The problem is that this only currently works on OpenBSD with manual keying, not IKE. In terms of code changes, I think the best situation would be for an IPsec daemon to be able to negotiate tunnel mode with the peer via IKE, but actually install just a "proto ipencap" flow between the two endpoint hosts (*not* for the tunnel addresses), and create a gif interface with the correct addressing so the tunnel packets flow. Note this would be a purely userland change. The other endpoint would just see a normal tunnel configuration so it would be perfect for talking to other vendor's implementations. If it helps illustrate it, here's a worked example with manual flows: http://bodgitandscarper.co.uk/openbsd/openbsd-ipsec-and-rfc-3884/
IPsec (isakmpd) in rdomain non zero needs default route
Hello, I don't know if I should post this to misc@ or bugs@... If this is the wrong list tell me I'll file a proper bug report. I need to add a default route in rdomain 1 to be able to use the tunnels created by isakmpd. That is a bit weird, routes should be injected by isakmpd. Here is my test setup : ++ | em1 (rd1):192.168.0.1 em1(rd1)192.168.0.2 | ++ ++ | rtr1 | | rtr2 | | lo1 (rd1): 127.0.0.1 | | lo1 (rd1): 127.0.0.1 | | alias: 192.168.1.1 | | alias: 192.168.2.1 | ++ ++ on rtr 1 and 2 : created enc1 rdomain 1 up launched route -T 1 exec isakmpd -K tunnel conf rtr 1: ike esp from 192.168.1.0/24 to 192.168.2.0/24 local 192.168.0.2 peer 192.168.0.2 \ main auth hmac-md5 enc 3des group modp1024 lifetime 28800 \ quick auth hmac-md5 enc 3des group modp1024 lifetime 3600 psk "deadbeef" tunnel conf rtr 2: ike esp from 192.168.2.0/24 to 192.168.1.0/24 local 192.168.0.2 peer 192.168.0.1 \ main auth hmac-md5 enc 3des group modp1024 lifetime 28800 \ quick auth hmac-md5 enc 3des group modp1024 lifetime 3600 psk "deadbeef" routing table rt1 : Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 127.0.0.1 127.0.0.1 UHhl 12 32768 1 lo1 192.168.0/24 192.168.0.1UCn10 - 4 em1 192.168.0.100:50:56:b4:7b:eb UHLl 0 37 - 1 em1 192.168.0.200:50:56:b4:77:82 UHLc 1 16 - 3 em1 192.168.0.255 192.168.0.1UHb00 - 1 em1 192.168.1.1192.168.1.1UHl07 32768 1 lo1 routing table rt2 : Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface 127.0.0.1 127.0.0.1 UHhl 12 32768 1 lo1 192.168.0/24 192.168.0.2UCn00 - 4 em1 192.168.0.200:50:56:b4:77:82 UHLl 0 245 - 1 em1 192.168.0.255 192.168.0.2UHb00 - 1 em1 192.168.2.1192.168.2.1UHl0 52 32768 1 lo1 flows rtr1 : # route -T1 exec ipsecctl -sf flow esp in from 192.168.2.0/24 to 192.168.1.0/24 peer 192.168.0.2 srcid 192.168.0.1/32 dstid 192.168.0.2/32 type use flow esp out from 192.168.1.0/24 to 192.168.2.0/24 peer 192.168.0.2 srcid 192.168.0.1/32 dstid 192.168.0.2/32 type require flows rtr2 : # route -T1 exec ipsecctl -sf flow esp in from 192.168.1.0/24 to 192.168.2.0/24 peer 192.168.0.1 srcid 192.168.0.2/32 dstid 192.168.0.1/32 type use flow esp out from 192.168.2.0/24 to 192.168.1.0/24 peer 192.168.0.1 srcid 192.168.0.2/32 dstid 192.168.0.1/32 type require On rtr1 : ping -V 1 -I 192.168.1.1 192.168.2.1 won't work until I do on both routers : route -T1 add default 127.0.0.1 My guess is that the problem is quite the same as with inter-domain routing with PF : destination lookup is done BEFORE processing by PF or IPSEC (explained here for PF : https://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/). So when there is no default route, it fails. If this guess is right, the problem shoud also happen on rdomain 0. Could you fix the code to make it work without the default route ? Or, as I suspect, is this too difficult and I'll go with my workaround ? -- Cordialement, Pierre Bardou
Re: isakmpd memory usage
On 17/06/17(Sat) 09:49, Nicolas Repentin wrote: > No one ? > > Le 13 juin 2017 09:11:02 GMT+02:00, Nicolas a écrit : > >Hi everyone > > > >I'm searching some help about isakmpd, which is eating a lot of memory, > >until the machine crash. It's an OpenBSD 6.1 on Qemu KVM (ganeti). > >After 3 days, the process is using 650MB of memory. > > > >When she's "freezed", she's unreachable on network, and on console > >she's blinking on tty, like normal, but we can't write anything on it. > >No .core are generated. > > > >I got a lot of errors like "INVALID_ID_INFORMATION" on > >"NO_PROPOSAL_CHOSEN" on ipsec logs, but ipsec connections are working. > > > >Any idea how I can debug it? You could start by increasing the log level. Then rotate the log regularity, like everyday. Every time you rotate the log, write down the amount of memory consumed by the daemon. Then hopefully you can find a pattern in the log that's proportional to the amount of memory leaked between each rotation. Many the number of INVALID_ID_INFORMATION or something else. That information could help us reducing the scope of the memory leak.
Re: isakmpd memory usage
Hi
Here is my ipsec.conf :
ike esp from /24 to /24
peer
main auth hmac-sha1 enc aes-256 group modp1024 lifetime 28800
quick auth hmac-sha1 enc aes-256 group modp1024 lifetime 3600
srcid
psk ''
tag vpn
ike passive esp transport proto udp from to any port 1701
main auth hmac-sha1 enc aes group modp2048
quick auth hmac-sha1 enc aes
srcid
psk ""
tag vpnrw
ike esp from /32 to /24
peer
main auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 3600
quick auth hmac-sha2-256 enc aes-256 group modp2048 lifetime 1200
srcid
psk ''
ike esp from /32 to /24
peer
main auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 3600
quick auth hmac-sha2-256 enc aes-256 group modp1024 lifetime 1200
srcid
psk ''
ike esp from to /24
peer
main auth hmac-sha1 enc aes-256 group modp1024 lifetime 28800
quick auth hmac-sha1 enc aes-256 group modp1024 lifetime 3600
srcid
psk ''
tag vpn
Actually the isakmpd process is eating more than 100MB of memory per day.
Nicolas
17 juin 2017 11:13 "Michał Koc" a écrit:
Hi Nicolas,
We are currently investigating some isakmpd memory problem with the
devs.
We have isakmpd running more than 100 tunnels.
Please post Your ipsec.conf with auth data and addresses anonimised to
investigate.
best regards
Michał Koc
-- Wiadomość oryginalna --
Temat: Re: isakmpd memory usage
Nadawca: Nicolas Repentin (mailto:nico...@shivaserv.fr)
Adresat: misc@openbsd.org (mailto:misc@openbsd.org)
Data: 17.06.2017 09:49
No one ? Le 13 juin 2017 09:11:02 GMT+02:00, Nicolas
(mailto:nico...@shivaserv.fr) a écrit :
Hi everyone I'm searching some help about isakmpd, which is eating a
lot of memory, until the machine crash. It's an OpenBSD 6.1 on Qemu KVM
(ganeti). After 3 days, the process is using 650MB of memory. When she's
"freezed", she's unreachable on network, and on console she's blinking on tty,
like normal, but we can't write anything on it. No .core are generated. I got a
lot of errors like "INVALID_ID_INFORMATION" on "NO_PROPOSAL_CHOSEN" on ipsec
logs, but ipsec connections are working. Any idea how I can debug it? Thanks,
Nicolas
Re: isakmpd memory usage
No one ? Le 13 juin 2017 09:11:02 GMT+02:00, Nicolas a écrit : >Hi everyone > >I'm searching some help about isakmpd, which is eating a lot of memory, >until the machine crash. It's an OpenBSD 6.1 on Qemu KVM (ganeti). >After 3 days, the process is using 650MB of memory. > >When she's "freezed", she's unreachable on network, and on console >she's blinking on tty, like normal, but we can't write anything on it. >No .core are generated. > >I got a lot of errors like "INVALID_ID_INFORMATION" on >"NO_PROPOSAL_CHOSEN" on ipsec logs, but ipsec connections are working. > >Any idea how I can debug it? >Thanks, > >Nicolas -- Nicolas
isakmpd memory usage
Hi everyone I'm searching some help about isakmpd, which is eating a lot of memory, until the machine crash. It's an OpenBSD 6.1 on Qemu KVM (ganeti). After 3 days, the process is using 650MB of memory. When she's "freezed", she's unreachable on network, and on console she's blinking on tty, like normal, but we can't write anything on it. No .core are generated. I got a lot of errors like "INVALID_ID_INFORMATION" on "NO_PROPOSAL_CHOSEN" on ipsec logs, but ipsec connections are working. Any idea how I can debug it? Thanks, Nicolas
Re: isakmpd dies quietly with over 100 tunnels
Hi Stuart, Rising openfiles-cur does not change anything. Best Regards M.K. -- Wiadomość oryginalna -- *Temat: *Re: isakmpd dies quietly with over 100 tunnels *Nadawca: *Stuart Henderson *Adresat: *misc@openbsd.org *Data: *30.05.2017 11:55 On 2017-05-28, Michał Koc wrote: Hi all, I'm running 6.0/amd64 inside KVM/Quemu with over 100 ipsec tunnels. Everything was running just fine when the number of tunnels was lower. But as we have been setting up more and more tunnels we suddenly run on problems. The isakmpd deaemon keeps dying quietly. Probably I'm running out of something, but I need some help to find out what it is and how to monitor it and tweak. Does it help to raise openfiles-cur for the daemon class in /etc/login.conf?
Re: isakmpd dies quietly with over 100 tunnels
On 2017-05-28, Michał Koc wrote: > Hi all, > > I'm running 6.0/amd64 inside KVM/Quemu with over 100 ipsec tunnels. > > Everything was running just fine when the number of tunnels was lower. > But as we have been setting up more and more tunnels we suddenly run on > problems. > The isakmpd deaemon keeps dying quietly. Probably I'm running out of > something, but I need some help to find out what it is and how to > monitor it and tweak. Does it help to raise openfiles-cur for the daemon class in /etc/login.conf?
Re: isakmpd dies quietly with over 100 tunnels
On 2017-05-29, Alexis VACHETTE wrote: > I didn't think it was isakmpd related back then. > Maybe a configuration issue on my end or the partner's. If isakmpd crashes, there is a bug in isakmpd. No network input should cause that to happen.
Re: isakmpd dies quietly with over 100 tunnels
Hi All,
the trace is below, give mi a notice if anything else is needed:
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 162385]
conf_get_str (section=0xa8735b03f80 ' 0xa8735b04000 out of bounds>, tag=0xa8459272809 "Phase") at
/usr/src/sbin/isakmpd/conf.c:94
94 /usr/src/sbin/isakmpd/conf.c: No such file or directory.
in /usr/src/sbin/isakmpd/conf.c
Current language: auto; currently c
(gdb) bt
#0 conf_get_str (section=0xa8735b03f80 ' 0xa8735b04000 out of bounds>, tag=0xa8459272809 "Phase") at
/usr/src/sbin/isakmpd/conf.c:94
#1 0x0a84590293b4 in pf_key_v2_remove_conf (section=0xa8735b03f80 '
) at
/usr/src/sbin/isakmpd/pf_key_v2.c:1905
#2 0x0a845902956a in pf_key_v2_stayalive (exchange=0xa86a6f44200,
vconn=0xa8735b03f80, fail=1) at /usr/src/sbin/isakmpd/pf_key_v2.c:2131
#3 0x0a8459005bdf in exchange_run_finalizations
(exchange=0xa86a6f44200, arg=0xa86c2fa4f80, fail=1) at
/usr/src/sbin/isakmpd/exchange.c:653
#4 0x0a8459005bd2 in exchange_run_finalizations
(exchange=0xa86a6f44200, arg=0xa86d33c9700, fail=1) at
/usr/src/sbin/isakmpd/exchange.c:652
#5 0x0a8459005bd2 in exchange_run_finalizations
(exchange=0xa86a6f44200, arg=0xa86a3fb3580, fail=1) at
/usr/src/sbin/isakmpd/exchange.c:652
#6 0x0a8459005bd2 in exchange_run_finalizations
(exchange=0xa86a6f44200, arg=0xa86f3332820, fail=1) at
/usr/src/sbin/isakmpd/exchange.c:652
#7 0x0a8459005bd2 in exchange_run_finalizations
(exchange=0xa86a6f44200, arg=0xa86d33c99a0, fail=1) at
/usr/src/sbin/isakmpd/exchange.c:652
#8 0x0a8459005bd2 in exchange_run_finalizations
(exchange=0xa86a6f44200, arg=0xa86f3332f20, fail=1) at
/usr/src/sbin/isakmpd/exchange.c:652
#9 0x0a84590069e0 in exchange_free_aux (v_exch=Variable "v_exch" is
not available.
) at /usr/src/sbin/isakmpd/exchange.c:1230
#10 0x0a845901e8f0 in timer_handle_expirations () at
/usr/src/sbin/isakmpd/timer.c:76
#11 0x0a8459015b1b in main (argc=Variable "argc" is not available.
) at /usr/src/sbin/isakmpd/isakmpd.c:533
(gdb)
Best regards
M.K.
-- Wiadomość oryginalna --
*Temat: *Re: isakmpd dies quietly with over 100 tunnels
*Nadawca: *Michał Koc
*Adresat: *Alexis VACHETTE , Theo de Raadt
, Florian Ermisch
*Kopia: *misc@openbsd.org
*Data: *29.05.2017 11:39
Hi all,
we are setting up a test environment, will be back soon with the traces.
Best Regards
M.K.
-- Wiadomość oryginalna --
*Temat: *Re: isakmpd dies quietly with over 100 tunnels
*Nadawca: *Alexis VACHETTE
*Adresat: *Theo de Raadt , Florian Ermisch
*Kopia: *, Michał Koc
*Data: *29.05.2017 11:31
I didn't think it was isakmpd related back then.
Maybe a configuration issue on my end or the partner's.
But sure we need to post traces.
Nonetheless OpenBSD is an amazing piece of software, so thank you !
Regards,
Alexis.
On 29/05/2017 11:14, Theo de Raadt wrote:
Great thing is you all have source code, and can run the same
debuggers live in your key-happy situations, and then generate traces
to expose the problem so that someone can help you.
But, yet, that doesn't happen. Strange isn't it?
--
Michał Koc
Re: isakmpd dies quietly with over 100 tunnels
Hi all, we are setting up a test environment, will be back soon with the traces. Best Regards M.K. -- Wiadomość oryginalna -- *Temat: *Re: isakmpd dies quietly with over 100 tunnels *Nadawca: *Alexis VACHETTE *Adresat: *Theo de Raadt , Florian Ermisch *Kopia: *, Michał Koc *Data: *29.05.2017 11:31 I didn't think it was isakmpd related back then. Maybe a configuration issue on my end or the partner's. But sure we need to post traces. Nonetheless OpenBSD is an amazing piece of software, so thank you ! Regards, Alexis. On 29/05/2017 11:14, Theo de Raadt wrote: Great thing is you all have source code, and can run the same debuggers live in your key-happy situations, and then generate traces to expose the problem so that someone can help you. But, yet, that doesn't happen. Strange isn't it? --
Re: isakmpd dies quietly with over 100 tunnels
I didn't think it was isakmpd related back then. Maybe a configuration issue on my end or the partner's. But sure we need to post traces. Nonetheless OpenBSD is an amazing piece of software, so thank you ! Regards, Alexis. On 29/05/2017 11:14, Theo de Raadt wrote: Great thing is you all have source code, and can run the same debuggers live in your key-happy situations, and then generate traces to expose the problem so that someone can help you. But, yet, that doesn't happen. Strange isn't it?
Re: isakmpd dies quietly with over 100 tunnels
Great thing is you all have source code, and can run the same debuggers live in your key-happy situations, and then generate traces to expose the problem so that someone can help you. But, yet, that doesn't happen. Strange isn't it?
Re: isakmpd dies quietly with over 100 tunnels
Hi all, I got to admit I've seen isakmpd dying on 5.9* (amd64 on VMware). But after having to deal with half a dozen peers all over Europe using different proprietary solutions a cronjob like "rcctl ls faulty | grep isakmpd && rcctl restart…" worked well enough for me. I won't be able to test with the setup at work but I got a little VPS running 6.1 I could use (and update to -STABLE if necessary). We probably won't get to over 100 tunnels but I've seen the problem with ~8 tunnels. The question would be if this problem would even show up in a homogeneous OpenBSD network… Regards, Florian *) the central hub isn't my problem anymore, and it will take some time to convince my replacement there to update to 6.1… Am 29. Mai 2017 09:26:18 MESZ schrieb Alexis VACHETTE : >Hi Michał, > >I'm having same issue without 100 ipsec tunnels and dedicated hardware. > >Unfortunately it's a production environment so I can't really >troubleshooting this issue to track down the culprit. > >Anyway maybe it's not related to your issue. > >Regards, >Alexis. >On 28/05/2017 14:31, Michał Koc wrote: >> Hi all, >> >> I'm running 6.0/amd64 inside KVM/Quemu with over 100 ipsec tunnels. >> >> Everything was running just fine when the number of tunnels was >lower. >> But as we have been setting up more and more tunnels we suddenly run >> on problems. >> The isakmpd deaemon keeps dying quietly. Probably I'm running out of >> something, but I need some help to find out what it is and how to >> monitor it and tweak. >> >> Thank You in advance. >> >> Best Regards >> M.K. >> >> root@vgate0:/root# netstat -m >> 215 mbufs in use: >> 163 mbufs allocated to data >> 46 mbufs allocated to packet headers >> 6 mbufs allocated to socket names and addresses >> 160/920/6144 mbuf 2048 byte clusters in use (current/peak/max) >> 0/8/6144 mbuf 4096 byte clusters in use (current/peak/max) >> 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max) >> 0/14/6146 mbuf 9216 byte clusters in use (current/peak/max) >> 0/10/6150 mbuf 12288 byte clusters in use (current/peak/max) >> 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max) >> 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max) >> 2760 Kbytes allocated to network (13% in use) >> 0 requests for memory denied >> 0 requests for memory delayed >> 0 calls to protocol drain routines >> >> Sample tail of the log: >> When I run "isakmpd -K -d -DA=10": >> 142043.246192 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx > >> SPI 0x42f03e5d >> 142043.246209 Timr 10 timer_add_event: event >> sa_soft_expire(0x1fb9d0bdf400) added before >> sa_soft_expire(0x1fb9c8f05400), expiration in 25056s >> 142043.246223 Timr 10 timer_add_event: event >> sa_hard_expire(0x1fb9d0bdf400) added before >> sa_soft_expire(0x1fb9dd458200), expiration in 28800s >> 142043.246326 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx > >> SPI 0x3ffa5955 >> 142043.268229 Default responder_recv_HASH_SA_NONCE: KEY_EXCH payload >> without a group desc. attribute >> 142043.268250 Default dropped message from xxx.xxx.xxx.xxx port 500 >> due to notification type NO_PROPOSAL_CHOSEN >> 142043.268281 Timr 10 timer_add_event: event >> exchange_free_aux(0x1fb9a5336400) added before >> sa_soft_expire(0x1fba0d6a2a00), expiration in 120s >> 142043.268289 Exch 10 exchange_establish_p2: 0x1fb9a5336400 > >> policy initiator phase 2 doi 1 exchange 5 step 0 >> 142043.268295 Exch 10 exchange_establish_p2: icookie 8c58f4e7f8269ed3 > >> rcookie 0fe2d7657125a339 >> 142043.268301 Exch 10 exchange_establish_p2: msgid de2c5cc3 sa_list >> 142043.269079 Timr 10 timer_add_event: event >> message_send_expire(0x1fb994136900) added before >> connection_checker(0x1fb9b2646280), expiration in 7s >> 142043.269614 Exch 10 exchange_finalize: 0x1fb9a5336400 >> policy> policy initiator phase 2 doi 1 exchange 5 step 1 >> 142043.269630 Exch 10 exchange_finalize: icookie 8c58f4e7f8269ed3 >> rcookie 0fe2d7657125a339 >> 142043.269637 Exch 10 exchange_finalize: msgid de2c5cc3 sa_list >> 142043.269653 Timr 10 timer_remove_event: removing event >> exchange_free_aux(0x1fb9a5336400) >> 142043.289465 Timr 10 timer_remove_event: removing event >> message_send_expire(0x1fb994136900) >> 142043.289513 Exch 10 exchange_finalize: 0x1fb972b59400 >> from-xxx.xxx.xxx.xxx/24-to-xxx.xxx.xxx.xxx/24 policy >> responder phase 2 doi 1 exchange 32 step 2 >
Re: isakmpd dies quietly with over 100 tunnels
Hi Michał, I'm having same issue without 100 ipsec tunnels and dedicated hardware. Unfortunately it's a production environment so I can't really troubleshooting this issue to track down the culprit. Anyway maybe it's not related to your issue. Regards, Alexis. On 28/05/2017 14:31, Michał Koc wrote: Hi all, I'm running 6.0/amd64 inside KVM/Quemu with over 100 ipsec tunnels. Everything was running just fine when the number of tunnels was lower. But as we have been setting up more and more tunnels we suddenly run on problems. The isakmpd deaemon keeps dying quietly. Probably I'm running out of something, but I need some help to find out what it is and how to monitor it and tweak. Thank You in advance. Best Regards M.K. root@vgate0:/root# netstat -m 215 mbufs in use: 163 mbufs allocated to data 46 mbufs allocated to packet headers 6 mbufs allocated to socket names and addresses 160/920/6144 mbuf 2048 byte clusters in use (current/peak/max) 0/8/6144 mbuf 4096 byte clusters in use (current/peak/max) 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max) 0/14/6146 mbuf 9216 byte clusters in use (current/peak/max) 0/10/6150 mbuf 12288 byte clusters in use (current/peak/max) 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max) 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max) 2760 Kbytes allocated to network (13% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Sample tail of the log: When I run "isakmpd -K -d -DA=10": 142043.246192 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0x42f03e5d 142043.246209 Timr 10 timer_add_event: event sa_soft_expire(0x1fb9d0bdf400) added before sa_soft_expire(0x1fb9c8f05400), expiration in 25056s 142043.246223 Timr 10 timer_add_event: event sa_hard_expire(0x1fb9d0bdf400) added before sa_soft_expire(0x1fb9dd458200), expiration in 28800s 142043.246326 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0x3ffa5955 142043.268229 Default responder_recv_HASH_SA_NONCE: KEY_EXCH payload without a group desc. attribute 142043.268250 Default dropped message from xxx.xxx.xxx.xxx port 500 due to notification type NO_PROPOSAL_CHOSEN 142043.268281 Timr 10 timer_add_event: event exchange_free_aux(0x1fb9a5336400) added before sa_soft_expire(0x1fba0d6a2a00), expiration in 120s 142043.268289 Exch 10 exchange_establish_p2: 0x1fb9a5336400 policy initiator phase 2 doi 1 exchange 5 step 0 142043.268295 Exch 10 exchange_establish_p2: icookie 8c58f4e7f8269ed3 rcookie 0fe2d7657125a339 142043.268301 Exch 10 exchange_establish_p2: msgid de2c5cc3 sa_list 142043.269079 Timr 10 timer_add_event: event message_send_expire(0x1fb994136900) added before connection_checker(0x1fb9b2646280), expiration in 7s 142043.269614 Exch 10 exchange_finalize: 0x1fb9a5336400 policy> policy initiator phase 2 doi 1 exchange 5 step 1 142043.269630 Exch 10 exchange_finalize: icookie 8c58f4e7f8269ed3 rcookie 0fe2d7657125a339 142043.269637 Exch 10 exchange_finalize: msgid de2c5cc3 sa_list 142043.269653 Timr 10 timer_remove_event: removing event exchange_free_aux(0x1fb9a5336400) 142043.289465 Timr 10 timer_remove_event: removing event message_send_expire(0x1fb994136900) 142043.289513 Exch 10 exchange_finalize: 0x1fb972b59400 from-xxx.xxx.xxx.xxx/24-to-xxx.xxx.xxx.xxx/24 policy responder phase 2 doi 1 exchange 32 step 2 142043.289521 Exch 10 exchange_finalize: icookie 8c58f4e7f8269ed3 rcookie 0fe2d7657125a339 142043.289528 Exch 10 exchange_finalize: msgid de079ef6 sa_list 0x1fb9dd458800 0x1fb985d09e00 142043.289578 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0xe5d04953 142043.289594 Timr 10 timer_add_event: event sa_soft_expire(0x1fb9dd458800) added before sa_soft_expire(0x1fba1d81de00), expiration in 3279s 142043.289608 Timr 10 timer_add_event: event sa_hard_expire(0x1fb9dd458800) added before sa_soft_expire(0x1fba2c980800), expiration in 3600s 142043.289710 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0x4d895568 root@vgate0:/root# OpenBSD 6.0-stable (GENERIC.MP) #0: Sat Feb 4 21:55:17 CET 2017 root@amd64.vcomp:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056956416 (1007MB) avail mem = 1020506112 (973MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1dc0 (11 entries) bios0: vendor Bochs version "Bochs" date 01/01/2011 bios0: Bochs Bochs acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC HPET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: QEMU Virtual CPU version 2.1.2, 3492.32 MHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT,HV,NXE,LONG,LAHF,ABM cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way
isakmpd dies quietly with over 100 tunnels
Hi all, I'm running 6.0/amd64 inside KVM/Quemu with over 100 ipsec tunnels. Everything was running just fine when the number of tunnels was lower. But as we have been setting up more and more tunnels we suddenly run on problems. The isakmpd deaemon keeps dying quietly. Probably I'm running out of something, but I need some help to find out what it is and how to monitor it and tweak. Thank You in advance. Best Regards M.K. root@vgate0:/root# netstat -m 215 mbufs in use: 163 mbufs allocated to data 46 mbufs allocated to packet headers 6 mbufs allocated to socket names and addresses 160/920/6144 mbuf 2048 byte clusters in use (current/peak/max) 0/8/6144 mbuf 4096 byte clusters in use (current/peak/max) 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max) 0/14/6146 mbuf 9216 byte clusters in use (current/peak/max) 0/10/6150 mbuf 12288 byte clusters in use (current/peak/max) 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max) 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max) 2760 Kbytes allocated to network (13% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Sample tail of the log: When I run "isakmpd -K -d -DA=10": 142043.246192 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0x42f03e5d 142043.246209 Timr 10 timer_add_event: event sa_soft_expire(0x1fb9d0bdf400) added before sa_soft_expire(0x1fb9c8f05400), expiration in 25056s 142043.246223 Timr 10 timer_add_event: event sa_hard_expire(0x1fb9d0bdf400) added before sa_soft_expire(0x1fb9dd458200), expiration in 28800s 142043.246326 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0x3ffa5955 142043.268229 Default responder_recv_HASH_SA_NONCE: KEY_EXCH payload without a group desc. attribute 142043.268250 Default dropped message from xxx.xxx.xxx.xxx port 500 due to notification type NO_PROPOSAL_CHOSEN 142043.268281 Timr 10 timer_add_event: event exchange_free_aux(0x1fb9a5336400) added before sa_soft_expire(0x1fba0d6a2a00), expiration in 120s 142043.268289 Exch 10 exchange_establish_p2: 0x1fb9a5336400 policy initiator phase 2 doi 1 exchange 5 step 0 142043.268295 Exch 10 exchange_establish_p2: icookie 8c58f4e7f8269ed3 rcookie 0fe2d7657125a339 142043.268301 Exch 10 exchange_establish_p2: msgid de2c5cc3 sa_list 142043.269079 Timr 10 timer_add_event: event message_send_expire(0x1fb994136900) added before connection_checker(0x1fb9b2646280), expiration in 7s 142043.269614 Exch 10 exchange_finalize: 0x1fb9a5336400 policy> policy initiator phase 2 doi 1 exchange 5 step 1 142043.269630 Exch 10 exchange_finalize: icookie 8c58f4e7f8269ed3 rcookie 0fe2d7657125a339 142043.269637 Exch 10 exchange_finalize: msgid de2c5cc3 sa_list 142043.269653 Timr 10 timer_remove_event: removing event exchange_free_aux(0x1fb9a5336400) 142043.289465 Timr 10 timer_remove_event: removing event message_send_expire(0x1fb994136900) 142043.289513 Exch 10 exchange_finalize: 0x1fb972b59400 from-xxx.xxx.xxx.xxx/24-to-xxx.xxx.xxx.xxx/24 policy responder phase 2 doi 1 exchange 32 step 2 142043.289521 Exch 10 exchange_finalize: icookie 8c58f4e7f8269ed3 rcookie 0fe2d7657125a339 142043.289528 Exch 10 exchange_finalize: msgid de079ef6 sa_list 0x1fb9dd458800 0x1fb985d09e00 142043.289578 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0xe5d04953 142043.289594 Timr 10 timer_add_event: event sa_soft_expire(0x1fb9dd458800) added before sa_soft_expire(0x1fba1d81de00), expiration in 3279s 142043.289608 Timr 10 timer_add_event: event sa_hard_expire(0x1fb9dd458800) added before sa_soft_expire(0x1fba2c980800), expiration in 3600s 142043.289710 Sdep 10 pf_key_v2_set_spi: satype 2 dst xxx.xxx.xxx.xxx SPI 0x4d895568 root@vgate0:/root# OpenBSD 6.0-stable (GENERIC.MP) #0: Sat Feb 4 21:55:17 CET 2017 root@amd64.vcomp:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056956416 (1007MB) avail mem = 1020506112 (973MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf1dc0 (11 entries) bios0: vendor Bochs version "Bochs" date 01/01/2011 bios0: Bochs Bochs acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC HPET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: QEMU Virtual CPU version 2.1.2, 3492.32 MHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT,HV,NXE,LONG,LAHF,ABM cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz cpu1
Re: isakmpd listen address
Thanks so much I was looking at the wrong place and was expecting it to be a parameter... Original Message Subject: Re: isakmpd listen address Local Time: May 25, 2017 9:06 PM UTC Time: May 25, 2017 7:06 PM From: hrv...@srce.hr To: misc@openbsd.org On 25.5.2017. 20:46, mabi wrote: > Hello, > I can't seem to find an option in isakmpd in order to have it listen only on > one interface or IP address respectively. Is there an option for that I am > not aware of? I just saw the -p option but that's for the port number. > Thanks, > M. > Hi, create isakmpd.conf file # ls -apl /etc/isakmpd/isakmpd.conf -rw--- 1 root wheel 31 Oct 29 2015 /etc/isakmpd/isakmpd.conf and edit like this: # cat /etc/isakmpd/isakmpd.conf [general] Listen-on =em0 man isakmpd.conf
Re: isakmpd listen address
On 25.5.2017. 20:46, mabi wrote: > Hello, > I can't seem to find an option in isakmpd in order to have it listen only on > one interface or IP address respectively. Is there an option for that I am > not aware of? I just saw the -p option but that's for the port number. > Thanks, > M. > Hi, create isakmpd.conf file # ls -apl /etc/isakmpd/isakmpd.conf -rw--- 1 root wheel 31 Oct 29 2015 /etc/isakmpd/isakmpd.conf and edit like this: # cat /etc/isakmpd/isakmpd.conf [general] Listen-on =em0 man isakmpd.conf
isakmpd listen address
Hello, I can't seem to find an option in isakmpd in order to have it listen only on one interface or IP address respectively. Is there an option for that I am not aware of? I just saw the -p option but that's for the port number. Thanks, M.
Re: Isakmpd and NAT-T
Hi,
Ok working well now, actually I shouldn't have set up the srcid with my
public_ip. Without this line (or this line containing private IP) it's
working well.
Regards,
Sebastien
On Sat, Mar 18, 2017 at 2:03 AM, Sébastien Morand
wrote:
> Hello Mike,
>
> "group none" in phase 2 because of this in the documentation:
> <<
> Possible values for auth, enc, and group are described below in CRYPTO
> TRANSFORMS. Perfect Forward Secrecy (PFS) is enabled unless group none is
> specified.
> >>
>
> And their documentation says: No PFS. As far as I understand I disable PFS
> by putting "group none" in phase 2, don't I?
>
> I'm actually waiting their logs for more information.
>
> Regards,
> Sebastien
>
>
> On Thu, Mar 16, 2017 at 10:08 PM, Mik J wrote:
>
>> Hello Sebastien,
>> Why "group none" for phase 2 ?
>>
>> " The following group types are permitted with the group keyword:
>>Group Size
>>none0 [phase 2 only]
>> "
>>
>> maybe you should ask them their conf and their logs
>>
>> Try also
>> sysctl -a | grep esp
>>
>>
>>
>>
>> Le Jeudi 16 mars 2017 16h33, Sébastien Morand a
>> écrit :
>>
>>
>> Hi Mike and everybody,
>>
>> Thank you Mike for your answer. There is nothing more like you said.
>> Actually we succeed in phase 1 but not in phase 2.
>>
>> My client give me the following spec:
>> Phase 1: SHA1 - 160 bits / DH 5 / Authentication with PSK / CIPHER :
>> AES-256 / Lifetime 86400s
>> Phase 2: Tunnel mode / SHA1 / No PFS / Authentication with PSK / CIPHER
>> AES-128 / Lifetime 3600s
>>
>> So I end up with the following in ipsec.conf:
>> ike active esp tunnel \
>> from 10.85.98.16/29 to \
>> {10.249.0.0/21} \
>> peer \
>> main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
>> quick auth hmac-sha1 enc aes-128 group none lifetime 3600 \
>> srcid "" \
>> psk ""
>>
>> I'm starting the ipsec like this :
>> isakmpd -Kdvvv (to see what is happening)
>> and
>> ipsecctl -f /etc/ipsec.conf
>>
>> It's look like good to me and conform to the provided specs. Phase 1 is ok
>> but no phase 2:
>> 155851.640374 Default ipsec_validate_id_information: dubious ID
>> information
>> accepted
>> 155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154,
>> responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142
>> 155918.682560 Default transport_send_messages: giving up on exchange
>> from-10.85.98.16/29-to-10.249.0.0/21, no response from peer
>> 80.125.165.142:4500
>> 155918.682611 Default transport_send_messages: giving up on exchange
>> from-10.85.98.16/29-to-80.125.172.0/23, no response from peer
>> 80.125.165.142:4500
>> 155918.682644 Default transport_send_messages: giving up on exchange
>> from-10.85.98.16/29-to-80.125.174.0/24, no response from peer
>> 80.125.165.142:4500
>>
>> In TCPDUMP I got no answer on port 4500 (but everything fine on port 500)
>> so it means to me they don't answer to my packet but I don't know why :
>> 16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
>> v1.0 exchange QUICK_MODE encrypted
>> 16:01:41.673655 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
>> v1.0 exchange QUICK_MODE encrypted
>> 16:01:41.673674 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
>> v1.0 exchange QUICK_MODE encrypted
>> 16:01:50.686803 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
>> v1.0 exchange QUICK_MODE encrypted
>> 16:01:50.686862 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
>> v1.0 exchange QUICK_MODE encrypted
>> 16:01:50.686881 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
>> v1.0 exchange QUICK_MODE encrypted
>> 16:02:01.700016 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
>> v1.0 exchange QUICK_MODE encrypted
>> 16:02:01.700106 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
>> v1.0 exchange QUICK_MODE encrypted
>> 16:02:01.700154 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
>> v1.0 exchange QUICK_MODE encrypted
>> (... it can last forever ...)
>>
>> Any idea what can be done or a way to get more information on what's going
>> on? They are using CISCO 6509 with IOS 12.2-33.SXH3a.
>>
>> Thanks by advance,
>> Sebastien
>&g
Re: L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?
Hi Philipp, Thank you - this was exactly what I was missing. I have now gotten it to work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1), which strongly suggests my Nexus 6P (all patched) doesn't implement hmac-sha2-256 correctly. The irony is that the manpage of isakmpd.policy explains all this excellently, but I didn't read it because I misunderstood what the manpage of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run at boot time via the isakmpd_flags variable in rc.conf.local(8). Note that it will probably need to be run with at least the -K option, to avoid keynote(4) policy checking." I read this as meaning that keynote policy checking is *always* unwanted when ipsecctl is used, and that you can avoid policy checking either by not having a policy file at all (in which case the -K option doesn't matter), or by using the -K option (in which case it's certain that policy checking never happens). But now I know better. :) Thanks, Jurjen 2017-03-20 9:33 GMT+01:00 Jurjen Oskam : > Hi Philipp, > > Thank you - this was exactly what I was missing. I have now gotten it to > work by excluding hmac-sha2-256 (and therefore falling back to hmac-sha1), > which strongly suggests my Nexus 6P (all patched) doesn't implement > hmac-sha2-256 correctly. > > The irony is that the manpage of isakmpd.policy explains all this > excellently, but I didn't read it because I misunderstood what the manpage > of ipsec.conf says: "The keying daemon, isakmpd(8), can be enabled to run > at boot time via the isakmpd_flags variable in rc.conf.local(8). Note that > it will probably need to be run with at least the -K option, to avoid > keynote(4) policy checking." I read this as meaning that keynote policy > checking is *always* unwanted when ipsecctl is used, and that you can avoid > policy checking either by not having a policy file at all (in which case > the -K option doesn't matter), or by using the -K option (in which case > it's certain that policy checking never happens). > > But now I know better. :) > > Thanks, > > Jurjen > > > 2017-03-20 6:08 GMT+01:00 Philipp Buehler 7...@posteo.net>: > >> Am 19.03.2017 15:36 schrieb Jurjen Oskam: >> >> So, to validate that I'm indeed hitting this bug (and also as a >>> workaround) >>> I tried to set up the OpenBSD side to not use SHA2. I haven't been able >>> to >>> get this running yet: isakmpd always seems to offer HMAC_SHA2_256. >>> >> >> It's not offering that - but accepting "better" Phase2 transforms. If >> isakmpd >> would start the negotiation, it'd propose HMAC_SHA. >> >> To keep out unwanted proposals, you need an isakmpd.policy. (hint: no -K) >> >> In my eyes this is 'bad behaviour' and tends to lead to situations where >> e.g. >> a remote end "upgrades" (and locks down) the transforms and thus rekeying >> started by isakmpd start to fail. >> >> HTH, >> -- >> pb
Re: L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?
Am 19.03.2017 15:36 schrieb Jurjen Oskam: So, to validate that I'm indeed hitting this bug (and also as a workaround) I tried to set up the OpenBSD side to not use SHA2. I haven't been able to get this running yet: isakmpd always seems to offer HMAC_SHA2_256. It's not offering that - but accepting "better" Phase2 transforms. If isakmpd would start the negotiation, it'd propose HMAC_SHA. To keep out unwanted proposals, you need an isakmpd.policy. (hint: no -K) In my eyes this is 'bad behaviour' and tends to lead to situations where e.g. a remote end "upgrades" (and locks down) the transforms and thus rekeying started by isakmpd start to fail. HTH, -- pb
L2TP/IPsec VPN server: trying to force HMAC_SHA in phase 2, but isakmpd keeps offering HMAC_SHA2_256?
Hi, I'm trying to set up my OpenBSD 6.0 box as an L2TP/IPsec server for my Android phone to connect to. It appears that recent Android versions have a bug that can prevent it to successfully use HMAC_SHA2_256 for its built-in L2TP/IPsec VPN client. (Whether the bug occurs seems to depend on the specifics of the Linux kernel that happens to be used for the device. See https://code.google.com/p/android/issues/detail?id=196939 for more information). I suspect I'm hit by this bug. The isakmpd negotiations seem to work fine, but npppd doesn't see any traffic. When tcpdumping the external interface of the OpenBSD box, I see incoming encrypted traffic, but on a simultaneously running tcpdump on the enc0 interface, I see no traffic at all. This behavior is consistent with the Android bug description: Android is requesting a SHA2 HMAC, but it is using a DRAFT version that is incompatible with the final RFC. So, to validate that I'm indeed hitting this bug (and also as a workaround) I tried to set up the OpenBSD side to not use SHA2. I haven't been able to get this running yet: isakmpd always seems to offer HMAC_SHA2_256. Here is /etc/ipsec.conf: ike passive esp transport \ proto udp from egress to any port 1701 \ main auth "hmac-sha1" enc "aes" group modp1024 \ quick auth "hmac-sha1" enc "aes" group modp1024 \ psk "SHARED_SEEKRIT" With this configuration, isakmpd still offers HMAC_SHA2_256. See a snippet of the output of tcpdumping the pcap file created by isakmpd below. The " ziggo.nl" address is OpenBSD, the "static.kpn.net" address is my Android phone connected to the cellular network): 15:31:00.865423 static.kpn.net.ipsec-nat-t > 5356F312.cm-6-7d.dynamic.ziggo.nl.isakmp: [bad udp cksum e50! -> 74e4] udpencap: isakmp v1.0 exchange QUICK_MODE cookie: 0f659aa030f4904d->64d8256cce1ec37b msgid: 8281d122 len: 460 payload: HASH len: 24 payload: SA len: 336 DOI: 1(IPSEC) situation: IDENTITY_ONLY payload: PROPOSAL len: 324 proposal: 1 proto: IPSEC_ESP spisz: 4 xforms: 12 SPI: 0x0a89e2b7 payload: TRANSFORM len: 28 transform: 1 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute KEY_LENGTH = 256 attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256 payload: TRANSFORM len: 28 transform: 2 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute KEY_LENGTH = 256 attribute AUTHENTICATION_ALGORITHM = HMAC_SHA payload: TRANSFORM len: 28 transform: 3 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute KEY_LENGTH = 256 attribute AUTHENTICATION_ALGORITHM = HMAC_MD5 payload: TRANSFORM len: 28 transform: 4 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute KEY_LENGTH = 128 attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256 payload: TRANSFORM len: 28 transform: 5 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute KEY_LENGTH = 128 attribute AUTHENTICATION_ALGORITHM = HMAC_SHA payload: TRANSFORM len: 28 transform: 6 ID: AES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute KEY_LENGTH = 128 attribute AUTHENTICATION_ALGORITHM = HMAC_MD5 payload: TRANSFORM len: 24 transform: 7 ID: 3DES attribute LIFE_TYPE = SECONDS attribute LIFE_DURATION = 28800 attribute ENCAPSULATION_MODE = UDP_ENCAP_TRANSPORT attribute AUTHENTICATION_ALGORITHM = HMAC_SHA2_256 payload: TRANSFORM len: 24 transform: 8 ID: 3DES attribute LIFE_
Re: Isakmpd and NAT-T
Hello Mike,
"group none" in phase 2 because of this in the documentation:
<<
Possible values for auth, enc, and group are described below in CRYPTO
TRANSFORMS. Perfect Forward Secrecy (PFS) is enabled unless group none is
specified.
>>
And their documentation says: No PFS. As far as I understand I disable PFS
by putting "group none" in phase 2, don't I?
I'm actually waiting their logs for more information.
Regards,
Sebastien
On Thu, Mar 16, 2017 at 10:08 PM, Mik J wrote:
> Hello Sebastien,
> Why "group none" for phase 2 ?
>
> " The following group types are permitted with the group keyword:
>Group Size
>none0 [phase 2 only]
> "
>
> maybe you should ask them their conf and their logs
>
> Try also
> sysctl -a | grep esp
>
>
>
>
> Le Jeudi 16 mars 2017 16h33, Sébastien Morand a
> écrit :
>
>
> Hi Mike and everybody,
>
> Thank you Mike for your answer. There is nothing more like you said.
> Actually we succeed in phase 1 but not in phase 2.
>
> My client give me the following spec:
> Phase 1: SHA1 - 160 bits / DH 5 / Authentication with PSK / CIPHER :
> AES-256 / Lifetime 86400s
> Phase 2: Tunnel mode / SHA1 / No PFS / Authentication with PSK / CIPHER
> AES-128 / Lifetime 3600s
>
> So I end up with the following in ipsec.conf:
> ike active esp tunnel \
> from 10.85.98.16/29 to \
> {10.249.0.0/21} \
> peer \
> main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
> quick auth hmac-sha1 enc aes-128 group none lifetime 3600 \
> srcid "" \
> psk ""
>
> I'm starting the ipsec like this :
> isakmpd -Kdvvv (to see what is happening)
> and
> ipsecctl -f /etc/ipsec.conf
>
> It's look like good to me and conform to the provided specs. Phase 1 is ok
> but no phase 2:
> 155851.640374 Default ipsec_validate_id_information: dubious ID information
> accepted
> 155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154,
> responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142
> 155918.682560 Default transport_send_messages: giving up on exchange
> from-10.85.98.16/29-to-10.249.0.0/21, no response from peer
> 80.125.165.142:4500
> 155918.682611 Default transport_send_messages: giving up on exchange
> from-10.85.98.16/29-to-80.125.172.0/23, no response from peer
> 80.125.165.142:4500
> 155918.682644 Default transport_send_messages: giving up on exchange
> from-10.85.98.16/29-to-80.125.174.0/24, no response from peer
> 80.125.165.142:4500
>
> In TCPDUMP I got no answer on port 4500 (but everything fine on port 500)
> so it means to me they don't answer to my packet but I don't know why :
> 16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
> v1.0 exchange QUICK_MODE encrypted
> 16:01:41.673655 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
> v1.0 exchange QUICK_MODE encrypted
> 16:01:41.673674 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
> v1.0 exchange QUICK_MODE encrypted
> 16:01:50.686803 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
> v1.0 exchange QUICK_MODE encrypted
> 16:01:50.686862 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
> v1.0 exchange QUICK_MODE encrypted
> 16:01:50.686881 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
> v1.0 exchange QUICK_MODE encrypted
> 16:02:01.700016 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
> v1.0 exchange QUICK_MODE encrypted
> 16:02:01.700106 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
> v1.0 exchange QUICK_MODE encrypted
> 16:02:01.700154 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
> v1.0 exchange QUICK_MODE encrypted
> (... it can last forever ...)
>
> Any idea what can be done or a way to get more information on what's going
> on? They are using CISCO 6509 with IOS 12.2-33.SXH3a.
>
> Thanks by advance,
> Sebastien
>
> On Tue, Mar 14, 2017 at 12:46 AM, Mik J wrote:
>
> > Hello Sebastien,
> > I'm not sure there's something special to force nat-t, it's automatic.
> > The natted side has to initiate the flow to the non natted side.
> > If the two sides are natted then there should be a port forward to one of
> > them.
> > There should be a nat keepalive parameter as well.
> >
> >
> >
> > Le Lundi 13 mars 2017 18h40, Sébastien Morand a
> > écrit :
>
> >
> >
> > Hi,
> >
> > I'm trying to set up a NAT-T IPSec VPN with one of my client.
> >
> > Is this configuration ok on ipsec.conf for NAT-T?
> > ike esp \
> >from 10.85.98.16/29 to {10.249.0.0/21} \
> >peer \
> >main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
> >quick auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
> >srcid "" \
> >psk ""
> >
> > Something else to force NAT-T?
> > Thanks by advance,
>
> > S̮̩bastien
Re: Isakmpd and NAT-T
Hello, On Fri, Mar 17 2017 at 22:07, Stuart Henderson wrote: > On 2017-03-16, Sébastien Morand wrote: > > Thank you Mike for your answer. There is nothing more like you said. > > Actually we succeed in phase 1 but not in phase 2. > .. > > It's look like good to me and conform to the provided specs. Phase 1 is ok > > but no phase 2: > > 155851.640374 Default ipsec_validate_id_information: dubious ID information > > accepted > > 155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154, > > responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142 > > 155918.682560 Default transport_send_messages: giving up on exchange > > from-10.85.98.16/29-to-10.249.0.0/21, no response from peer > > 80.125.165.142:4500 > .. > > so it means to me they don't answer to my packet but I don't know why : > > 16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp > > v1.0 exchange QUICK_MODE encrypted > .. > > Any idea what can be done or a way to get more information on what's going > > on? They are using CISCO 6509 with IOS 12.2-33.SXH3a. > > isakmpd sends the wrong encapsulation mode (always TUNNEL, not > UDP_ENCAPSULATED_TUNNEL). But also last time I tried this (in 2011) > Cisco hadn't caught up with the RFC and actually required the > UDP_ENCAPSULATED_TUNNEL_DRAFT value from the draft nat-t spec. > > This would cause a phase 2 failure, an ASA reports it like > "[IKEv1]Phase 2 failure: Mismatched attribute types for class > Encapsulation Mode: Rcv'd: Tunnel Cfg'd: UDP Tunnel(NAT-T)" > > Here's an old post about it with an isakmpd diff that was working > against Cisco. What I don't know is whether it harms interop with > anything else. > > http://marc.info/?l=openbsd-tech&m=131244805816474 I ran with this patch on production for nearly 2 years. It didn't cause any issue interoperating with few kind of devices. I successfully configured VPN with ASA, Juniper, Fortinet, StormShield and Windows on the other side. If there were some side effects, they were not visible. Claer
Re: Trouble with isakmpd authentication
On 2017-03-11, Simon McFarlane wrote: > Hi all, > > I'm trying to set up an IPSec tunnel with a remote peer (HamWAN) who are > helping > me annouce an IPv4 allocation. We are having some trouble authenticating with > isakmpd. We got it to connect with a PSK, but can't get certificates or public > key auth working (they don't do secrets as a matter of policy). > > They normally use a certificate setup, but it looks like isakmpd requires > subjectaltname to be filled. Using certs without subjectaltname did not > work. > > One thing I noticed is that looking at an ultra-verbose log, and using ktrace, > isakmpd loads local.key, but never seems to load anything in the pubkeys > directory. > > Before I dump my config files and debug info, I want to give some immense > thanks > to EO_ from HamWAN, who has gone way above the call of duty in helping me get > connected. > > Here is a link to their instructions page for Mikrotik/RouterOS routers: > https://hamwan.org/Labs/Open%20Peering%20Policy.html#setup-on-mikrotik-routeros-edge-router > > This is my ipsec.conf: > ike active ah tunnel from 44.24.246.18/31 to 44.24.246.0/31 peer 44.24.221.2 > main auth hmac-sha1 enc aes-128 group modp1024 lifetime 30m quick auth > hmac-md5 group modp1024 lifetime 30m > > My /etc/isakmpd/: > /etc/isakmpd/ >|-- ca >|-- certs >|-- crls >|-- keynote >|-- local.pub >|-- private >| `-- local.key > `-- pubkeys > |-- fqdn > |-- ipv4 > | `-- 44.24.221.2 > |-- ipv6 > `-- ufqdn > > local.key is a 2048-bit RSA private key generated by me, and local.pub is the > corresponding public key. pubkeys/ipv4/44.24.221.2 is the public key extracted > from their certificate. All of these are in PEM format. > > Any isakmpd experts know how I might make this work? They can give me a > client cert > with an arbitrary subjectaltname if that would fix it. Would they need to add > a > subjectaltname field to their server cert? ipv4/* is for host key auth, not X509. Put the signed cert in certs/.crt, and the CA cert in ca/ca.crt. subjectAltName needs to be either "IP:10.0.0.1" or "DNS:fqdn.example.com" and the cert must have extendedKeyUsage=serverAuth,clientAuth. isakmpd must use the IP or DNS mentioned in the cert as an identifier, easiest to set this with "srcid".
Re: Isakmpd and NAT-T
On 2017-03-16, Sébastien Morand wrote: > Thank you Mike for your answer. There is nothing more like you said. > Actually we succeed in phase 1 but not in phase 2. .. > It's look like good to me and conform to the provided specs. Phase 1 is ok > but no phase 2: > 155851.640374 Default ipsec_validate_id_information: dubious ID information > accepted > 155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154, > responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142 > 155918.682560 Default transport_send_messages: giving up on exchange > from-10.85.98.16/29-to-10.249.0.0/21, no response from peer > 80.125.165.142:4500 .. > so it means to me they don't answer to my packet but I don't know why : > 16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp > v1.0 exchange QUICK_MODE encrypted .. > Any idea what can be done or a way to get more information on what's going > on? They are using CISCO 6509 with IOS 12.2-33.SXH3a. isakmpd sends the wrong encapsulation mode (always TUNNEL, not UDP_ENCAPSULATED_TUNNEL). But also last time I tried this (in 2011) Cisco hadn't caught up with the RFC and actually required the UDP_ENCAPSULATED_TUNNEL_DRAFT value from the draft nat-t spec. This would cause a phase 2 failure, an ASA reports it like "[IKEv1]Phase 2 failure: Mismatched attribute types for class Encapsulation Mode: Rcv'd: Tunnel Cfg'd: UDP Tunnel(NAT-T)" Here's an old post about it with an isakmpd diff that was working against Cisco. What I don't know is whether it harms interop with anything else. http://marc.info/?l=openbsd-tech&m=131244805816474
Re: Isakmpd and NAT-T
Hello Sebastien,Why "group none" for phase 2 ?
"Â Â Â Â The following group types are permitted with the group keyword:
          Group      Size
          none       0      [phase 2 only]
"
maybe you should ask them their conf and their logs
Try alsosysctl -a | grep esp
Le Jeudi 16 mars 2017 16h33, Sébastien Morand a
écrit :
Hi Mike and everybody,
Thank you Mike for your answer. There is nothing more like you said.
Actually we succeed in phase 1 but not in phase 2.
My client give me the following spec:
Phase 1: SHA1 - 160 bits / DH 5 / Authentication with PSK / CIPHER :
AES-256 / Lifetime 86400s
Phase 2: Tunnel mode / SHA1 / No PFS / Authentication with PSK / CIPHER
AES-128 / Lifetime 3600s
So I end up with the following in ipsec.conf:
ike active esp tunnel \
  from 10.85.98.16/29 to \
    {10.249.0.0/21} \
  peer \
  main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
  quick auth hmac-sha1 enc aes-128 group none lifetime 3600 \
  srcid "" \
  psk ""
I'm starting the ipsec like this :
isakmpd -Kdvvv (to see what is happening)
and
ipsecctl -f /etc/ipsec.conf
It's look like good to me and conform to the provided specs. Phase 1 is ok
but no phase 2:
155851.640374 Default ipsec_validate_id_information: dubious ID information
accepted
155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154,
responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142
155918.682560 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-10.249.0.0/21, no response from peer
80.125.165.142:4500
155918.682611 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-80.125.172.0/23, no response from peer
80.125.165.142:4500
155918.682644 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-80.125.174.0/24, no response from peer
80.125.165.142:4500
In TCPDUMP I got no answer on port 4500 (but everything fine on port 500)
so it means to me they don't answer to my packet but I don't know why :
16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:41.673655 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:41.673674 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686803 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686862 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686881 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700016 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700106 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700154 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
(... it can last forever ...)
Any idea what can be done or a way to get more information on what's going
on? They are using CISCO 6509 with IOS 12.2-33.SXH3a.
Thanks by advance,
Sebastien
On Tue, Mar 14, 2017 at 12:46 AM, Mik J wrote:
> Hello Sebastien,
> I'm not sure there's something special to force nat-t, it's automatic.
> The natted side has to initiate the flow to the non natted side.
> If the two sides are natted then there should be a port forward to one of
> them.
> There should be a nat keepalive parameter as well.
>
>
>
> Le Lundi 13 mars 2017 18h40, Sébastien Morand a
> écrit :
>
>
> Hi,
>
> I'm trying to set up a NAT-T IPSec VPN with one of my client.
>
> Is this configuration ok on ipsec.conf for NAT-T?
> ike esp \
>Â Â from 10.85.98.16/29 to {10.249.0.0/21} \
>Â Â peer \
>Â Â main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
>Â Â quick auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
>Â Â srcid "" \
>Â Â psk ""
>
> Something else to force NAT-T?
> Thanks by advance,
> S̮̩bastien
Re: Isakmpd and NAT-T
Hi Mike and everybody,
Thank you Mike for your answer. There is nothing more like you said.
Actually we succeed in phase 1 but not in phase 2.
My client give me the following spec:
Phase 1: SHA1 - 160 bits / DH 5 / Authentication with PSK / CIPHER :
AES-256 / Lifetime 86400s
Phase 2: Tunnel mode / SHA1 / No PFS / Authentication with PSK / CIPHER
AES-128 / Lifetime 3600s
So I end up with the following in ipsec.conf:
ike active esp tunnel \
from 10.85.98.16/29 to \
{10.249.0.0/21} \
peer \
main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
quick auth hmac-sha1 enc aes-128 group none lifetime 3600 \
srcid "" \
psk ""
I'm starting the ipsec like this :
isakmpd -Kdvvv (to see what is happening)
and
ipsecctl -f /etc/ipsec.conf
It's look like good to me and conform to the provided specs. Phase 1 is ok
but no phase 2:
155851.640374 Default ipsec_validate_id_information: dubious ID information
accepted
155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154,
responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142
155918.682560 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-10.249.0.0/21, no response from peer
80.125.165.142:4500
155918.682611 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-80.125.172.0/23, no response from peer
80.125.165.142:4500
155918.682644 Default transport_send_messages: giving up on exchange
from-10.85.98.16/29-to-80.125.174.0/24, no response from peer
80.125.165.142:4500
In TCPDUMP I got no answer on port 4500 (but everything fine on port 500)
so it means to me they don't answer to my packet but I don't know why :
16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:41.673655 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:41.673674 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686803 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686862 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:01:50.686881 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700016 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700106 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
16:02:01.700154 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp
v1.0 exchange QUICK_MODE encrypted
(... it can last forever ...)
Any idea what can be done or a way to get more information on what's going
on? They are using CISCO 6509 with IOS 12.2-33.SXH3a.
Thanks by advance,
Sebastien
On Tue, Mar 14, 2017 at 12:46 AM, Mik J wrote:
> Hello Sebastien,
> I'm not sure there's something special to force nat-t, it's automatic.
> The natted side has to initiate the flow to the non natted side.
> If the two sides are natted then there should be a port forward to one of
> them.
> There should be a nat keepalive parameter as well.
>
>
>
> Le Lundi 13 mars 2017 18h40, Sébastien Morand a
> écrit :
>
>
> Hi,
>
> I'm trying to set up a NAT-T IPSec VPN with one of my client.
>
> Is this configuration ok on ipsec.conf for NAT-T?
> ike esp \
> from 10.85.98.16/29 to {10.249.0.0/21} \
> peer \
> main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
> quick auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
> srcid "" \
> psk ""
>
> Something else to force NAT-T?
> Thanks by advance,
> Sébastien
Re: Isakmpd and NAT-T
Am 14.03.2017 01:46 schrieb Mik J: Hello Sebastien,I'm not sure there's something special to force nat-t, it's automatic.The natted side has to initiate the flow to the non natted side.If the two sides are natted then there should be a port forward to one of them.There should be a nat keepalive parameter as well. Since I've seen this on several occassions, check that isakmpd is /not/ having the flag -T. But you might want to use -L and look into the resulting /var/run/isakmpd.pcap (hint: tail -fc+0 isakmpd.pcap|tcpdump -netttvvr -) and watch out for the vendor lines in the proposal if NAT-T is actually advertised - and of course allow 4500/udp in both directions.
Re: Isakmpd and NAT-T
Hello Sebastien,I'm not sure there's something special to force nat-t, it's
automatic.The natted side has to initiate the flow to the non natted side.If
the two sides are natted then there should be a port forward to one of
them.There should be a nat keepalive parameter as well.
Le Lundi 13 mars 2017 18h40, Sébastien Morand a
écrit :
Hi,
I'm trying to set up a NAT-T IPSec VPN with one of my client.
Is this configuration ok on ipsec.conf for NAT-T?
ike esp \
  from 10.85.98.16/29 to {10.249.0.0/21} \
  peer \
  main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
  quick auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
  srcid "" \
  psk ""
Something else to force NAT-T?
Thanks by advance,
Sébastien
Isakmpd and NAT-T
Hi,
I'm trying to set up a NAT-T IPSec VPN with one of my client.
Is this configuration ok on ipsec.conf for NAT-T?
ike esp \
from 10.85.98.16/29 to {10.249.0.0/21} \
peer \
main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
quick auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \
srcid "" \
psk ""
Something else to force NAT-T?
Thanks by advance,
Sébastien
Re: Trouble with isakmpd authentication
On 03/11/2017 02:47 PM, Simon McFarlane wrote: > Any isakmpd experts know how I might make this work? They can give me a > client cert > with an arbitrary subjectaltname if that would fix it. Would they need to add > a > subjectaltname field to their server cert? We toyed around with this, and after getting the correct SAN, something still gets hung up at the same place, despite the certificate being loaded. At this point, I'd just like to get host key auth working, which the man page says should eschew the need for certificates, but isakmpd still doesn't even seem to look at anything in the pubkeys folder.
Trouble with isakmpd authentication
Hi all, I'm trying to set up an IPSec tunnel with a remote peer (HamWAN) who are helping me annouce an IPv4 allocation. We are having some trouble authenticating with isakmpd. We got it to connect with a PSK, but can't get certificates or public key auth working (they don't do secrets as a matter of policy). They normally use a certificate setup, but it looks like isakmpd requires subjectaltname to be filled. Using certs without subjectaltname did not work. One thing I noticed is that looking at an ultra-verbose log, and using ktrace, isakmpd loads local.key, but never seems to load anything in the pubkeys directory. Before I dump my config files and debug info, I want to give some immense thanks to EO_ from HamWAN, who has gone way above the call of duty in helping me get connected. Here is a link to their instructions page for Mikrotik/RouterOS routers: https://hamwan.org/Labs/Open%20Peering%20Policy.html#setup-on-mikrotik-routeros-edge-router This is my ipsec.conf: ike active ah tunnel from 44.24.246.18/31 to 44.24.246.0/31 peer 44.24.221.2 main auth hmac-sha1 enc aes-128 group modp1024 lifetime 30m quick auth hmac-md5 group modp1024 lifetime 30m My /etc/isakmpd/: /etc/isakmpd/ |-- ca |-- certs |-- crls |-- keynote |-- local.pub |-- private | `-- local.key `-- pubkeys |-- fqdn |-- ipv4 | `-- 44.24.221.2 |-- ipv6 `-- ufqdn local.key is a 2048-bit RSA private key generated by me, and local.pub is the corresponding public key. pubkeys/ipv4/44.24.221.2 is the public key extracted from their certificate. All of these are in PEM format. Any isakmpd experts know how I might make this work? They can give me a client cert with an arbitrary subjectaltname if that would fix it. Would they need to add a subjectaltname field to their server cert? Thanks, Simon For understanding the below config, my IP address is 71.32.246.199. Output of isakmpd -K -d -T -v -D A=39: - 135329.733775 Default log_debug_cmd: log level changed from 0 to 39 for class 0 [priv] 135329.734769 Default log_debug_cmd: log level changed from 0 to 39 for class 1 [priv] 135329.734788 Default log_debug_cmd: log level changed from 0 to 39 for class 2 [priv] 135329.734804 Default log_debug_cmd: log level changed from 0 to 39 for class 3 [priv] 135329.734820 Default log_debug_cmd: log level changed from 0 to 39 for class 4 [priv] 135329.734835 Default log_debug_cmd: log level changed from 0 to 39 for class 5 [priv] 135329.734850 Default log_debug_cmd: log level changed from 0 to 39 for class 6 [priv] 135329.734865 Default log_debug_cmd: log level changed from 0 to 39 for class 7 [priv] 135329.734880 Default log_debug_cmd: log level changed from 0 to 39 for class 8 [priv] 135329.734896 Default log_debug_cmd: log level changed from 0 to 39 for class 9 [priv] 135329.734939 Default log_debug_cmd: log level changed from 0 to 39 for class 10 [priv] 135329.734954 Default isakmpd: starting [priv] 135329.737177 Misc 10 monitor_init: privileges dropped for child process 135330.101234 Plcy 30 policy_init: initializing 135330.103973 Misc 20 udp_make: transport 0x4d1d7733400 socket 8 ip ::1 port 500 135330.104497 Misc 20 udp_make: transport 0x4d1bc508b80 socket 9 ip fe80:5::1 port 500 135330.105066 Misc 20 udp_make: transport 0x4d1d7733680 socket 10 ip 127.0.0.1 port 500 135330.105565 Misc 20 udp_make: transport 0x4d1d7733700 socket 11 ip 192.168.0.1 port 500 135330.106023 Misc 20 udp_make: transport 0x4d16df1f480 socket 12 ip fe80:7::20d:b9ff:fe41:e7fc port 500 135330.106637 Misc 20 udp_make: transport 0x4d12e3ae980 socket 13 ip 71.32.246.199 port 500 135330.107060 Misc 20 udp_make: transport 0x4d1d7733c00 socket 14 ip 0.0.0.0 port 500 135330.107490 Misc 20 udp_make: transport 0x4d16df1fd80 socket 15 ip :: port 500 135336.262336 UI 30 ui_config: "C set [Phase 1]:44.24.221.2=peer-44.24.221.2 force" 135336.262557 UI 30 ui_config: "C set [peer-44.24.221.2]:Phase=1 force" 135336.262773 UI 30 ui_config: "C set [peer-44.24.221.2]:Address=44.24.221.2 force" 135336.262852 UI 30 ui_config: "C set [peer-44.24.221.2]:Configuration=phase1-peer-44.24.221.2 force" 135336.262953 UI 30 ui_config: "C set [phase1-peer-44.24.221.2]:EXCHANGE_TYPE=ID_PROT force" 135336.263286 UI 30 ui_config: "C add [phase1-peer-44.24.221.2]:Transforms=phase1-transform-peer-44.24.221.2-RSA_SIG-SHA-AES128-MODP_1024 force" 135336.263376 UI 30 ui_config: "C set [phase1-transform-peer-44.24.221.2-RSA_SIG-SHA-AES128-MODP_1024]:AUTHENTICATION_METHOD=RSA_SIG force" 135336.263478 UI 30 ui_config: "C set [phase1-transform-peer-44.24.221.2-RSA_SIG-SHA-AES128-MODP_1024]:HASH_ALGORITHM=SHA force" 135336.263580 UI 30 ui_config: "C set [phase1-transform-peer-44.24.221.2-RSA_SIG-SHA-AES128-MODP_1024]:ENCRYPTION_ALGORITHM=AES_CBC force" 135336.263651 UI 30 ui_config: "C set [p
Re: Isakmpd vs iked
Disclaimer: I don't want to sound too negative, I really appreciate all the hard work that went in to OpenIKED but I've just made the reverse trip; OpenIKED (IKEv2) to isakmpd (IKEv1). We just couldn't get our connections stable with OpenIKED. We backported multiple patches from the master in to our 6.0 source tree which improved things but in the end after what seemed like about a month without trouble OpenIKED suddenly started to run in to trouble with rekeying so I finally called it quits and deployed isakmpd. For example we bumped in to an issue described on the mailinglist[1] with rekeying. This is one of the patches we applied which improved things for us but as far as I can tell this hasn't ended up in the main source tree. Also there are some pitfalls of things that work with isakmpd but not with iked. For example sasyncd has some shortcomings with iked [2]. We bumped into like 5 other things like this before throwing in the towel. So my advice is: Ask yourself if you really need IKEv2 with iked because it won't be as smooth sailing as with isakmpd. [1] https://marc.info/?l=openbsd-tech&m=147869752432059&w=2 [2] https://marc.info/?l=openbsd-misc&m=147574084806723&w=2 Kind regards, Jasper > Op 7 februari 2017 om 18:43 schreef Christopher Sean Hilton > : > > > How hard is it to transition from an isakmpd managed IPsec VPN to iked > managment? I have a certificate based isakmpd solution that works. It > is mainly just a matter of rsyncing the directories and using a little > editor magic on the ipsec.conf file to create iked.conf? > > Thanks in advance, > > -- Chris
Solved -- Was: Isakmpd Cert question.
On Tue, Feb 07, 2017 at 01:30:13PM -0500, Christopher Sean Hilton wrote: > On Tue, Feb 07, 2017 at 11:23:29AM -0500, Christopher Sean Hilton wrote: > > I'm using isakmpd to manage an ipsec VPN between OpenBSD 5.8 <-> OpenBSD > > 6.0. This also manages a VPN between Mac OS X/ IPsecuritas and OpenBSD 6.0. > > > > Some more information on this and possibly a real question: > > Here's the logs from the OpenBSD 5.8 machine: > > 130142.003702 Cryp 40 x509_read_from_dir: reading certs from /etc/isakmpd/ca/ > 130142.004443 Cryp 60 x509_read_from_dir: reading certificate > /etc/isakmpd/ca/Readme.md > 130142.004825 Default x509_read_from_dir: PEM_read_X509 failed for > /etc/isakmpd/ca/Readme.md > 130142.004921 Cryp 60 x509_read_from_dir: reading certificate > /etc/isakmpd/ca/ca.crt > 130142.006237 Cryp 60 x509_read_from_dir: reading certificate > /etc/isakmpd/ca/root.crt > 130142.007072 Cryp 60 x509_read_from_dir: reading certificate > /etc/isakmpd/ca/sign.crt > 130142.008005 Cryp 50 x509_read_from_dir: X509_STORE_add_cert failed for > /etc/isakmpd/ca/sign.crt > 130142.008133 Cryp 40 x509_read_from_dir: reading certs from > /etc/isakmpd/certs/ > Looks like the ../ca/ca.crt and ../ca/sign.crt had the same cert. isakmpd was rejecting both from it's internal CA as a duplicate so there was no issuer for my peer certs. Removing the duplicate solved the problem. Thanks if you looked or even if you didn't -- Chris
Re: Isakmpd Cert question.
On Tue, Feb 07, 2017 at 11:23:29AM -0500, Christopher Sean Hilton wrote: > I'm using isakmpd to manage an ipsec VPN between OpenBSD 5.8 <-> OpenBSD > 6.0. This also manages a VPN between Mac OS X/ IPsecuritas and OpenBSD 6.0. > Some more information on this and possibly a real question: Here's the logs from the OpenBSD 5.8 machine: 130142.003702 Cryp 40 x509_read_from_dir: reading certs from /etc/isakmpd/ca/ 130142.004443 Cryp 60 x509_read_from_dir: reading certificate /etc/isakmpd/ca/Readme.md 130142.004825 Default x509_read_from_dir: PEM_read_X509 failed for /etc/isakmpd/ca/Readme.md 130142.004921 Cryp 60 x509_read_from_dir: reading certificate /etc/isakmpd/ca/ca.crt 130142.006237 Cryp 60 x509_read_from_dir: reading certificate /etc/isakmpd/ca/root.crt 130142.007072 Cryp 60 x509_read_from_dir: reading certificate /etc/isakmpd/ca/sign.crt 130142.008005 Cryp 50 x509_read_from_dir: X509_STORE_add_cert failed for /etc/isakmpd/ca/sign.crt 130142.008133 Cryp 40 x509_read_from_dir: reading certs from /etc/isakmpd/certs/ The intermediate cert: .../ca/sign.crt is an x509 CA cert which is signed by .../ca/root.crt yet X509_STORE_add_cert fails to add it to the chain. I'm expecting sign.crt to be accepted because it's issued by root.crt. Q: Is X509_STORE_add_cert trying to build a chain or is it expecting a list of self-signed root certificates? -- Chris
Isakmpd vs iked
How hard is it to transition from an isakmpd managed IPsec VPN to iked managment? I have a certificate based isakmpd solution that works. It is mainly just a matter of rsyncing the directories and using a little editor magic on the ipsec.conf file to create iked.conf? Thanks in advance, -- Chris
Isakmpd Cert question.
I'm using isakmpd to manage an ipsec VPN between OpenBSD 5.8 <-> OpenBSD 6.0. This also manages a VPN between Mac OS X/ IPsecuritas and OpenBSD 6.0. The example describes a situation where you have one self signed root certificate located in /etc/isakmpd/ca/root.crt and otherside::client.crt from the other side which should be signed by root.crt. My situation is slightly different. I have: otherside::client.crt (signed by) /etc/isakmpd/ca/intermediate.crt (signed by) /etc/isakmpd/ca/root.crt But I'm having trouble getting this going. As I read the source code in x509.c I can see that isakmpd is at least reading and hashing all the certs in /etc/isakmpd/ca. Is there something special that I have to do to have it chain intermediate.crt -> root.crt so it can use client.crt without having to put client.crt into /etc/isakmpd/certs? Thanks for all your help! -- Chris
Re: isakmpd set up
On 2017-01-02, Peter Fraser wrote: > I want the fixed IP address so I don't have to drive there to fix problems. PS: I haven't used it recently, but I've found ports/sysutils/autossh useful in the past for these.
Re: isakmpd set up
On 2017-01-02, Peter Fraser wrote:
> A charity that I support has been having trouble with its internet provider
> (Rogers).
> The problem I have is that Roger is the only supplier that is available that
> will
> give a fixed IP address.
>
> I want the fixed IP address so I don't have to drive there to fix problems.
>
> It occurred to me that if I could get a VPN set up automatically when their
> OpenBSD firewall boots.
> I could then use the VPN to reach back into their computer.
>
> Having never set up a VPN using OpenBSD I started by reading, and I was left
> very confused.
>
> I came up with:
>
> On my firewall I have /etc/ipsec.conf
>
> ike passive from egress to 192.168.254/24 peer 192.168.254.1 srcid thinkage.ca
> dstid kwaccessability.ca tag ipsec-kwa
> ike passive from 192.102.11.0/24 to 192.168.254.0/24 peer 192.168.254.1 srcid
> thinkage.ca dstid kwaccessability.ca tag ipsec-kwa
Because you don't know the other side's IP address, use "to any" here
to set it as the "default peer", i.e. the peer that matches traffic from a
destination where you don't have a specific IP configuration in isakmpd.conf.
Remove "peer 192.168.254.1".
Don't rely on shortcuts like 192.168.254/24, use the proper 192.168.254.0/24.
It might not be a problem but it's something else to go wrong (or something that
might work now but go wrong later). Not worth the typing saving.
So I'd try something like
ike passive from {egress, 192.102.11.0/24} to any srcid thinkage.ca \
dstid kwaccessability.ca tag ipsec-kwa
> on their firewall
>
> ike from egress to 192.102.11/24 peer 192.102.11.1 srcid kwaccessability.ca
> dstid thinkage.ca tag ipsec-kwa
> ike from 192.168.254/24 to 192.102.11/24 peer 192.102.11.1 srcid
> kwaccessability.ca dstid thinkage.ca tag ipsec-kwa
>
> I also opened up the firewall to allow packed in from both networks without
> restrictions,
> something I will have to clean up later
>
> On both system I have isakmpd_flags=-K -v -D A=10
After reading code and trying things out I settled on using this as my
standard config for systems where I'm interested in getting logging out of
isakmpd:
isakmpd_flags="-Kv -D0=29 -D1=49 -D2=10 -D3=30 -D5=20 -D6=30 -D8=30 -D9=30
-D10=20"
Then if there's something particular I need to look at I'll bump that
area's logging based on looking at the source code.
> because of some of the readings I also put on both systems into
> /etc/hostname.enc0
> up
Not needed.
> when I try to start isakmpd on the remote system I get only a message about
> privilege droping.
Are you doing anything funny with logging setup?
Are you actually loading ipsec.conf (ipsec=YES in rc.conf.local or manually
running ipsecctl -f /etc/ipsec.conf)?
> Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section
> to-192.168.254/24 network 192.168.254
that might be connected with your truncated IP addresses.
> Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not record
> passive connection "from-ste0-to-192.168.254/24"
ste, not my favourite nic ;)
Re: isakmpd set up
I apologise if it has already been said but we have heaps of clients with Office 365 where Microsoft do not control the DNS. The client does but you need special TXT records. Then again, none are charities with that special $1/month/user deal. Regards - Damian Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037 Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here Views & opinions here are mine and not those of any past or present employer
Re: isakmpd set up
On Mon, 2017-01-02 at 22:05 +, Peter Fraser wrote: [...] > any hint as to what I am doing wrong? Your config looks strange for sure! Please read http://www.kernel-panic.it/openbsd/vpn/vpn3.html and http:/ /stuffresearch.tor.hu/?p=64 In addition I recomend reading http://undeadly.org/cgi?action=article&s id=20131125041429 Regards, Armin.
Re: isakmpd set up
Hi, You should see if the client can operate as a Microsoft Office "partial redelegation". One client where I work uses Office 365 and still retains control of their own DNS. I did a quick google... https://support.office.com/en-us/article/How-Office-365-manages-DNS-records-5980474a-097f-4f21-a864-21245314957f If you can't get to a "partial redelation" situation, then you are really limited on what you can do, and it's likely that a dynamic IP address just won't work with Office 365 either. Good luck! Cheers, Steve W. / / On 03/01/2017 8:49 AM, Peter Fraser wrote: > The charity uses Office 365, which for charities a great deal, Microsoft > charges them $1US per user per month > up to 75 users, but a result, Microsoft control their DNS. > > I also expect that they will be NATed and given a 10/8 address. > > > > > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of > Steve Williams > Sent: Monday, January 2, 2017 6:57 PM > To: Peter Fraser ; 'misc@openbsd.org' > Subject: Re: isakmpd set up > > Hi, > > I have been using OpenBSD on a dynamic IP address for 10+ years. > > I have an account with dynamic dns provider Zoneedit and use the ddclient > package. > > I run a SMTP daemon, HTTP, SSH and in those 10+ years, I have never had a > situation where I could not reach my server. I access it from all over the > world using putty (ssh), imap (dovecot), webmail > (roundcubemail) and access my web server for various purposes. > > When I first got my server going, I was a paranoid & had a modem connected to > the serial port of my server so I could get to my server in the case of > loosing Internet access. I used the modem exactly 0 times and finally got > rid of the landline. > > Since I am paranoid, I had a backup to the backup & received an email every 2 > hours (initially) that had the IP address of the interface. I had a filter > so the email just went into a folder. I never had to use it... > > If you feel tied to an ISP because of static IP, I would not hesitate to go > the dynamic route. > > Cheers, > Steve Williams > > On 02/01/2017 3:05 PM, Peter Fraser wrote: >> A charity that I support has been having trouble with its internet >> provider (Rogers). >> The problem I have is that Roger is the only supplier that is >> available that will give a fixed IP address. >> >> I want the fixed IP address so I don't have to drive there to fix problems. >> >> It occurred to me that if I could get a VPN set up automatically when >> their OpenBSD firewall boots. >> I could then use the VPN to reach back into their computer. >> >> Having never set up a VPN using OpenBSD I started by reading, and I >> was left very confused. >> >> I came up with: >> >> On my firewall I have /etc/ipsec.conf >> >> ike passive from egress to 192.168.254/24 peer 192.168.254.1 srcid >> thinkage.ca dstid kwaccessability.ca tag ipsec-kwa ike passive from >> 192.102.11.0/24 to 192.168.254.0/24 peer 192.168.254.1 srcid >> thinkage.ca dstid kwaccessability.ca tag ipsec-kwa >> >> on their firewall >> >> ike from egress to 192.102.11/24 peer 192.102.11.1 srcid >> kwaccessability.ca dstid thinkage.ca tag ipsec-kwa ike from >> 192.168.254/24 to 192.102.11/24 peer 192.102.11.1 srcid >> kwaccessability.ca dstid thinkage.ca tag ipsec-kwa >> >> I also opened up the firewall to allow packed in from both networks >> without restrictions, something I will have to clean up later >> >> On both system I have isakmpd_flags=-K -v -D A=10 >> >> because of some of the readings I also put on both systems into >> /etc/hostname.enc0 >> up >> >> when I try to start isakmpd on the remote system I get only a message >> about privilege droping. >> >> on my local system I get >> >> Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event >> ui_conn_reinit(0x0) added last, expiration in 5s Jan 2 16:23:55 >> gateway isakmpd[71980]: timer_remove_event: removing event >> ui_conn_reinit(0x0) >> Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event >> ui_conn_reinit(0x0) added last, expiration in 5s gateway:/etc # Jan 2 >> 16:24:00 gateway isakmpd[71980]: >> timer_handle_expirations: event ui_conn_reinit(0x0) Jan 2 16:24:00 >> gateway isakmpd[71980]: ipsec_get_id: invalid section >> to-192.168.254/24 network 192.168.254 >> Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not >> record passive connection "from-ste0-to-192.168.254/24" &g
Re: isakmpd set up
Yes I did try with the extra .0 it made no difference -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Denis Fondras Sent: Tuesday, January 3, 2017 1:56 AM To: Peter Fraser Cc: 'misc@openbsd.org' Subject: Re: isakmpd set up > ike from egress to 192.102.11/24 peer 192.102.11.1 srcid > kwaccessability.ca dstid thinkage.ca tag ipsec-kwa ike from > 192.168.254/24 to 192.102.11/24 peer 192.102.11.1 srcid > kwaccessability.ca dstid thinkage.ca tag ipsec-kwa > Have you tried to replace 192.102.11/24 with 192.102.11.0/24 and 192.168.254/24 with 192.168.254.0/24 ?
Re: isakmpd set up
The charity uses Office 365, which for charities a great deal, Microsoft charges them $1US per user per month up to 75 users, but a result, Microsoft control their DNS. I also expect that they will be NATed and given a 10/8 address. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Steve Williams Sent: Monday, January 2, 2017 6:57 PM To: Peter Fraser ; 'misc@openbsd.org' Subject: Re: isakmpd set up Hi, I have been using OpenBSD on a dynamic IP address for 10+ years. I have an account with dynamic dns provider Zoneedit and use the ddclient package. I run a SMTP daemon, HTTP, SSH and in those 10+ years, I have never had a situation where I could not reach my server. I access it from all over the world using putty (ssh), imap (dovecot), webmail (roundcubemail) and access my web server for various purposes. When I first got my server going, I was a paranoid & had a modem connected to the serial port of my server so I could get to my server in the case of loosing Internet access. I used the modem exactly 0 times and finally got rid of the landline. Since I am paranoid, I had a backup to the backup & received an email every 2 hours (initially) that had the IP address of the interface. I had a filter so the email just went into a folder. I never had to use it... If you feel tied to an ISP because of static IP, I would not hesitate to go the dynamic route. Cheers, Steve Williams On 02/01/2017 3:05 PM, Peter Fraser wrote: > A charity that I support has been having trouble with its internet > provider (Rogers). > The problem I have is that Roger is the only supplier that is > available that will give a fixed IP address. > > I want the fixed IP address so I don't have to drive there to fix problems. > > It occurred to me that if I could get a VPN set up automatically when > their OpenBSD firewall boots. > I could then use the VPN to reach back into their computer. > > Having never set up a VPN using OpenBSD I started by reading, and I > was left very confused. > > I came up with: > > On my firewall I have /etc/ipsec.conf > > ike passive from egress to 192.168.254/24 peer 192.168.254.1 srcid > thinkage.ca dstid kwaccessability.ca tag ipsec-kwa ike passive from > 192.102.11.0/24 to 192.168.254.0/24 peer 192.168.254.1 srcid > thinkage.ca dstid kwaccessability.ca tag ipsec-kwa > > on their firewall > > ike from egress to 192.102.11/24 peer 192.102.11.1 srcid > kwaccessability.ca dstid thinkage.ca tag ipsec-kwa ike from > 192.168.254/24 to 192.102.11/24 peer 192.102.11.1 srcid > kwaccessability.ca dstid thinkage.ca tag ipsec-kwa > > I also opened up the firewall to allow packed in from both networks > without restrictions, something I will have to clean up later > > On both system I have isakmpd_flags=-K -v -D A=10 > > because of some of the readings I also put on both systems into > /etc/hostname.enc0 > up > > when I try to start isakmpd on the remote system I get only a message > about privilege droping. > > on my local system I get > > Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event > ui_conn_reinit(0x0) added last, expiration in 5s Jan 2 16:23:55 > gateway isakmpd[71980]: timer_remove_event: removing event > ui_conn_reinit(0x0) > Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event > ui_conn_reinit(0x0) added last, expiration in 5s gateway:/etc # Jan 2 > 16:24:00 gateway isakmpd[71980]: > timer_handle_expirations: event ui_conn_reinit(0x0) Jan 2 16:24:00 > gateway isakmpd[71980]: ipsec_get_id: invalid section > to-192.168.254/24 network 192.168.254 > Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not > record passive connection "from-ste0-to-192.168.254/24" > Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section > from-192.102.11/24 network 192.102.11 > Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not > record passive connection "from-192.102.11/24-to-192.168.254/24" > JaJan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event > ui_conn_reinit(0x0) added last, expiration in 5s Jan 2 16:23:55 > gateway isakmpd[71980]: timer_remove_event: removing event > ui_conn_reinit(0x0) > Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event > ui_conn_reinit(0x0) added last, expiration in 5s gateway:/etc # Jan 2 > 16:24:00 gateway isakmpd[71980]: > timer_handle_expirations: event ui_conn_reinit(0x0) Jan 2 16:24:00 > gateway isakmpd[71980]: ipsec_get_id: invalid section > to-192.168.254/24 network 192.168.254 > Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not > record passive connection "from-ste0-to-192.168.254/24" > Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section > from-192.102.11/24 network 192.102.11 > Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not > record passive connection "from-192.102.11/24-to-192.168.254/24" > > > any hint as to what I am doing wrong?
Re: isakmpd set up
> ike from egress to 192.102.11/24 peer 192.102.11.1 srcid kwaccessability.ca > dstid thinkage.ca tag ipsec-kwa > ike from 192.168.254/24 to 192.102.11/24 peer 192.102.11.1 srcid > kwaccessability.ca dstid thinkage.ca tag ipsec-kwa > Have you tried to replace 192.102.11/24 with 192.102.11.0/24 and 192.168.254/24 with 192.168.254.0/24 ?
Re: isakmpd set up
Hi, I have been using OpenBSD on a dynamic IP address for 10+ years. I have an account with dynamic dns provider Zoneedit and use the ddclient package. I run a SMTP daemon, HTTP, SSH and in those 10+ years, I have never had a situation where I could not reach my server. I access it from all over the world using putty (ssh), imap (dovecot), webmail (roundcubemail) and access my web server for various purposes. When I first got my server going, I was a paranoid & had a modem connected to the serial port of my server so I could get to my server in the case of loosing Internet access. I used the modem exactly 0 times and finally got rid of the landline. Since I am paranoid, I had a backup to the backup & received an email every 2 hours (initially) that had the IP address of the interface. I had a filter so the email just went into a folder. I never had to use it... If you feel tied to an ISP because of static IP, I would not hesitate to go the dynamic route. Cheers, Steve Williams On 02/01/2017 3:05 PM, Peter Fraser wrote: A charity that I support has been having trouble with its internet provider (Rogers). The problem I have is that Roger is the only supplier that is available that will give a fixed IP address. I want the fixed IP address so I don't have to drive there to fix problems. It occurred to me that if I could get a VPN set up automatically when their OpenBSD firewall boots. I could then use the VPN to reach back into their computer. Having never set up a VPN using OpenBSD I started by reading, and I was left very confused. I came up with: On my firewall I have /etc/ipsec.conf ike passive from egress to 192.168.254/24 peer 192.168.254.1 srcid thinkage.ca dstid kwaccessability.ca tag ipsec-kwa ike passive from 192.102.11.0/24 to 192.168.254.0/24 peer 192.168.254.1 srcid thinkage.ca dstid kwaccessability.ca tag ipsec-kwa on their firewall ike from egress to 192.102.11/24 peer 192.102.11.1 srcid kwaccessability.ca dstid thinkage.ca tag ipsec-kwa ike from 192.168.254/24 to 192.102.11/24 peer 192.102.11.1 srcid kwaccessability.ca dstid thinkage.ca tag ipsec-kwa I also opened up the firewall to allow packed in from both networks without restrictions, something I will have to clean up later On both system I have isakmpd_flags=-K -v -D A=10 because of some of the readings I also put on both systems into /etc/hostname.enc0 up when I try to start isakmpd on the remote system I get only a message about privilege droping. on my local system I get Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event ui_conn_reinit(0x0) added last, expiration in 5s Jan 2 16:23:55 gateway isakmpd[71980]: timer_remove_event: removing event ui_conn_reinit(0x0) Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event ui_conn_reinit(0x0) added last, expiration in 5s gateway:/etc # Jan 2 16:24:00 gateway isakmpd[71980]: timer_handle_expirations: event ui_conn_reinit(0x0) Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section to-192.168.254/24 network 192.168.254 Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not record passive connection "from-ste0-to-192.168.254/24" Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section from-192.102.11/24 network 192.102.11 Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not record passive connection "from-192.102.11/24-to-192.168.254/24" JaJan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event ui_conn_reinit(0x0) added last, expiration in 5s Jan 2 16:23:55 gateway isakmpd[71980]: timer_remove_event: removing event ui_conn_reinit(0x0) Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event ui_conn_reinit(0x0) added last, expiration in 5s gateway:/etc # Jan 2 16:24:00 gateway isakmpd[71980]: timer_handle_expirations: event ui_conn_reinit(0x0) Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section to-192.168.254/24 network 192.168.254 Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not record passive connection "from-ste0-to-192.168.254/24" Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section from-192.102.11/24 network 192.102.11 Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not record passive connection "from-192.102.11/24-to-192.168.254/24" any hint as to what I am doing wrong?
isakmpd set up
A charity that I support has been having trouble with its internet provider (Rogers). The problem I have is that Roger is the only supplier that is available that will give a fixed IP address. I want the fixed IP address so I don't have to drive there to fix problems. It occurred to me that if I could get a VPN set up automatically when their OpenBSD firewall boots. I could then use the VPN to reach back into their computer. Having never set up a VPN using OpenBSD I started by reading, and I was left very confused. I came up with: On my firewall I have /etc/ipsec.conf ike passive from egress to 192.168.254/24 peer 192.168.254.1 srcid thinkage.ca dstid kwaccessability.ca tag ipsec-kwa ike passive from 192.102.11.0/24 to 192.168.254.0/24 peer 192.168.254.1 srcid thinkage.ca dstid kwaccessability.ca tag ipsec-kwa on their firewall ike from egress to 192.102.11/24 peer 192.102.11.1 srcid kwaccessability.ca dstid thinkage.ca tag ipsec-kwa ike from 192.168.254/24 to 192.102.11/24 peer 192.102.11.1 srcid kwaccessability.ca dstid thinkage.ca tag ipsec-kwa I also opened up the firewall to allow packed in from both networks without restrictions, something I will have to clean up later On both system I have isakmpd_flags=-K -v -D A=10 because of some of the readings I also put on both systems into /etc/hostname.enc0 up when I try to start isakmpd on the remote system I get only a message about privilege droping. on my local system I get Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event ui_conn_reinit(0x0) added last, expiration in 5s Jan 2 16:23:55 gateway isakmpd[71980]: timer_remove_event: removing event ui_conn_reinit(0x0) Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event ui_conn_reinit(0x0) added last, expiration in 5s gateway:/etc # Jan 2 16:24:00 gateway isakmpd[71980]: timer_handle_expirations: event ui_conn_reinit(0x0) Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section to-192.168.254/24 network 192.168.254 Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not record passive connection "from-ste0-to-192.168.254/24" Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section from-192.102.11/24 network 192.102.11 Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not record passive connection "from-192.102.11/24-to-192.168.254/24" JaJan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event ui_conn_reinit(0x0) added last, expiration in 5s Jan 2 16:23:55 gateway isakmpd[71980]: timer_remove_event: removing event ui_conn_reinit(0x0) Jan 2 16:23:55 gateway isakmpd[71980]: timer_add_event: event ui_conn_reinit(0x0) added last, expiration in 5s gateway:/etc # Jan 2 16:24:00 gateway isakmpd[71980]: timer_handle_expirations: event ui_conn_reinit(0x0) Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section to-192.168.254/24 network 192.168.254 Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not record passive connection "from-ste0-to-192.168.254/24" Jan 2 16:24:00 gateway isakmpd[71980]: ipsec_get_id: invalid section from-192.102.11/24 network 192.102.11 Jan 2 16:24:00 gateway isakmpd[71980]: connection_init: could not record passive connection "from-192.102.11/24-to-192.168.254/24" any hint as to what I am doing wrong?
Re: OpenBSD isakmpd and OS X El Capitan client
Evgeniy Sudyr gmail.com> writes: > > I'm trying to establish IPSEC tunnel (for future usage with npppd > L2TP) between -snapshot and OS X El Captain 10.11.5 and have issues > when establishing phase1. > > I searched in archives and suggestions doesn't work for me. I tried > main/quick combinations from dumps (below), which make sense. > > Current config is: > > ipsec.conf > > ike passive esp proto from x.x.x.x to any port 1701 \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha1 enc 3des \ > psk "XXX" ... > I tried all proposals from dump I got from both client packets and > server site with no luck. > > Anybody have success with OS X client and isakmpd? It will be nice to > see working main and quick config parts. > this is an older configuration, but worked for me: ike passive esp transport \ proto udp from x.x.x.x to any port 1701 \ main auth "hmac-sha1" enc "aes" group modp1024 \ quick auth "hmac-sha1" enc "aes" group modp1024 \ psk "psk goes here"
OpenBSD isakmpd and OS X El Capitan client
I'm trying to establish IPSEC tunnel (for future usage with npppd L2TP) between -snapshot and OS X El Captain 10.11.5 and have issues when establishing phase1. I searched in archives and suggestions doesn't work for me. I tried main/quick combinations from dumps (below), which make sense. Current config is: ipsec.conf ike passive esp proto from x.x.x.x to any port 1701 \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des \ psk "XXX" x.x.x.x - openbsd server IP y.y.y.y - client IP When connecting in daemon logs: Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_2048, expected MODP_3072 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA, expected SHA2_256 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_2048, expected MODP_3072 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_2048, expected MODP_1024 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA2_256 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_512, expected SHA2_256 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_512, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_512, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_1536, expected MODP_3072 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA, expected SHA2_256 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_1536, expected MODP_3072 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_1536, expected MODP_1024 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA2_256 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_1024, expected MODP_3072 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA2_256, expected SHA Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: HASH_ALGORITHM: got SHA, expected SHA2_256 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: GROUP_DESCRIPTION: got MODP_1024, expected MODP_3072 Jul 9 17:25:43 vpn isakmpd[88568]: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC Jul 9 17:25:43 vpn isakmpd[88568]: message_parse_payloads: reserved field non-zero: 8a Jul 9 17:25:43 vpn isakmpd[88568]: dropped message from y.y.y.y port 36990 due to notification type PAYLOAD_MALFORMED Jul 9 17:25:46 vpn isakmpd[88568]: message_parse_payloads: reserved field non-zero: 8a Jul 9 17:25:46 vpn isakmpd[88568]: dropped message from y.y.y.y port 36990 due to notification type PAYLOAD_MALFORMED Jul 9 17:25:49 vpn isakmpd[88568]: message_parse_payloads: reserved field non-zero: 8a Jul 9 17:25:49 vpn isakmpd[88568]: dropped message from y.y.y.y port 36990 due to notification type PAYLOAD_MALFORMED Jul 9 17:25:
Re: rdomains, isakmpd, keep state (if-bound)
i'd really appreciate any help on this topic to understand what's going on. from my understanding packets received on enc0 create the state, and after some rdomain handling via pf return traffic should also leave on enc0, so the state matches. i can see via tcpdump packets on enc0 -> rdomain 15 -> $ntp reached and return traffic $ntp -> rdomain 10 ->but nothing leaves via enc0 again thanks for any help 2016-05-18 21:30 GMT+02:00 utob : > hi, > > i'm using a carp+vlan+trunk setup and isakmpd. > after migrating to rdomains, i've planned to have $ext_if > and isakmpd+enc0 in different rdomains, but that didn't > work out, as nothing would listen on $ext_if:500 then. > > the main thing is, that communication via enc0 is only > possible if i drop the (if-bound) option. > > # not able to reach ntp > pass in on enc0 proto udp from $remote to $ntp \ > port 123 keep state (if-bound) rtable 15 > > # works > pass in on enc0 proto udp from $remote to $ntp \ > port 123 rtable 15 > > i'd like to understand the technical reason (or what > to change if needed) why you cannot use if-bound with > rdomains. > > thanks
rdomains, isakmpd, keep state (if-bound)
hi, i'm using a carp+vlan+trunk setup and isakmpd. after migrating to rdomains, i've planned to have $ext_if and isakmpd+enc0 in different rdomains, but that didn't work out, as nothing would listen on $ext_if:500 then. the main thing is, that communication via enc0 is only possible if i drop the (if-bound) option. # not able to reach ntp pass in on enc0 proto udp from $remote to $ntp \ port 123 keep state (if-bound) rtable 15 # works pass in on enc0 proto udp from $remote to $ntp \ port 123 rtable 15 i'd like to understand the technical reason (or what to change if needed) why you cannot use if-bound with rdomains. thanks
isakmpd peculiarities, ipsec.conf manpage inaccuracy
Hi all, I'm running OpenBSD 5.8-stable. The ipsec.conf manpage indicates that if no srcid is present in an automatic keying IKE statement, then the value in the identification should be the host IP address, and be an IP address type. I've found this to be incorrect; if no srcid is specified, my system makes the type in the identification payload an FQDN, and sets the value to the machine's hostname. In order to pass just the IP address (and be an IP address type), I had to explicity set srcid to the IP address in the ike statement. Moving on, I am troubleshooting an issue where I'm able to connect a Macbook running OS X to a remote access VPN service (L2TP + IPsec) I pay for, but my seemingly identically-configured OpenBSD 5.8-stable workstation cannot connect. Specifically the IPsec negotiation fails. The failure occurs in the very beginning of the phase 2 negotiation, when the OpenBSD system sends the first Quick Mode message with its ID payloads. The remote peer always responds to this message with an "INVALID ID RECEIVED" notification, despite the ID payloads being identical to what my OS X system sends. After decrypting the IKE exchange from both my OpenBSD system and my OS X system, while I find the identification payload in the first quick mode message to be the same, I actually discovered a difference in the final segment of the main mode Identity Protection phase: In 3rd and final exchange in IKE phase 1 (Identity protection, main mode): *isakmpd appends an "INITIAL-CONTACT" Notification payload to the end of its message *The Identification payload contains zero-values for the port and protocol ID This is in contrast to my Mac OS X system which does not include the notification payload, and in the ID payload, it indicates a protocol of UDP and port 500. To be fair, the IETF IPSec DoI for ISAKMP actually does indicate that both the behavior of my Mac and of OpenBSD are acceptable. That being the case, these are the only meaningful differences I've been able to identify between OS X and OpenBSD, and ultimately I'd really like to be able to connect to the VPN. Does anybody know if there are any settings I can use to modify the behavior of isakmpd to be in line with what OS X does? I would greatly value any input. I have to say, decrypting the IKE exchange from OS X was a fairly annoying and tedius process. I love how with isakmpd I can just pass it the -L parameter and it will automatically dump a capture of the decrypted exchange. Warm regards, Andrew
Re: PPPoE / isakmpd race
On Wed, Feb 17, 2016 at 1:38 AM, Stuart Henderson
wrote:
>
> A more generic (but more complicated) approach would be to use ifstated
> to wait until the interface is up before running isakmpd.
Stu,
Thanks a bunch for this suggestion. This turned out to be the ticket! It
works like a champ.
For anyone who may stumble upon this in the mail archive, looking for a
solution, here's what works for me:
First, remove isakmpd_flags=<...> from your /etc/rc.conf.local. We want
ifstated(8) to start isakmpd(8), not rc(8) directly.
Next, add this to your rc.conf.local to start ifstated:
ifstated_flags=""
Finally, create an /etc/ifstated.conf. Mine is simple. It looks for
"status: active" in the ifconfig output, and it pings a router two hops up
from me that should always be online:
init-state pppoe_status
pppoe_check = '( "ifconfig pppoe0 | grep \"status: active\" && ping -q -c 1
-w 2 NNN.NNN.NNN.NNN > /dev/null" every 10)'
# Check to see if we're online.
state pppoe_status {
if $pppoe_check {
set-state pppoe_online
}
if ! $pppoe_check {
set-state pppoe_offline
}
}
state pppoe_online {
init {
run "ifconfig pppoe0 | mail -s 'PPPoE is UP' root@localhost"
run "pkill isakmpd; sleep 2; isakmpd -K; sleep 1; ipsecctl -f
/etc/ipsec.conf"
}
if ! $pppoe_check {
set-state pppoe_offline
}
}
state pppoe_offline {
init {
run "ifconfig pppoe0 | mail -s 'PPPoE is down' root@localhost"
}
if $pppoe_check {
set-state pppoe_online
}
}
Re: How does isakmpd determine which config stanza to use?
Am 19.02.2016 15:31 schrieb Christopher Sean Hilton: * Am I right to assume that when connecting to isakmpd the soekris box will match to the "Remote router" stanza because it's trying to build a tunnel from "srcid <-> dstid" or is isakmpd using the "local <-> peer" to choose the stanza? Somewhat both. If no srcid/dstid is defined, the local/peer will be taken as default as ipv4_addr ID. Run isakmpd with -L and check the isakmpd.pcap for what's being send/received. -- pb
How does isakmpd determine which config stanza to use?
I have an ipsec setup using certificate/ca based authentication. The
config looks like this:
# $OpenBSD: ipsec.conf,v 1.5 2006/09/14 15:10:43 hshoexer Exp $
#
my_fqdn="dynamic-0.example.com"
my_v4_ip="192.168.1.1"
my_v4_net="10.0.0.0/23"
remote_fqdn="dynamic-1.example.com"
remote_v4_net="10.0.2.0/24"
## -- Remote router
ike passive esp from { $my_v4_ip, $my_v4_net } to { $remote_fqdn,
$remote_v4_net } \
local $my_v4_ip peer $remote_fqdn \
main auth hmac-sha256 enc aes-128 group modp1024 lifetime 1800 \
quick auth hmac-sha256 enc aes-128 group none \
srcid $my_fqdn dstid $remote_fqdn
## -- Laptop(s)
ike passive esp from { $my_v4_ip, $my_v4_net } to any \
local $my_v4_ip peer any \
main auth hmac-sha256 enc aes-128 group modp1024 lifetime 1800 \
quick auth hmac-sha256 enc aes-128 group none \
srcid $my_fqdn
I'm trying to configure for two kinds of tunnels. One to a small
soekris box that provides it's own network, and one for laptop(s) that
connect ad-hoc from a coffee shops or clients work sites.
The soekris box as a fqdn certificate. The laptops have user-fqdn
certs. My question is:
* Am I right to assume that when connecting to isakmpd the soekris
box will match to the "Remote router" stanza because it's trying
to build a tunnel from "srcid <-> dstid" or is isakmpd using the
"local <-> peer" to choose the stanza?
I ask the question to get a better understanding of how isakmpd choses
the configuration stanza in case I have to expand on this
config. Also, I find this a little tricky because both sides of the
tunnel are on dynamic IPs although one side changes very very rarely.
Another question I have is:
* Would it be worth my while to move this config out of
isakmpd/ikev1 into ike/ikev2?
With the soekris, I'm tunnelling IPv6 traffic over a gif v4/v6
tunnel. While this works, it's a tremendous kludge. And my ipv6 mtu
ends up being something like 1320 bytes after all the overhead from
UDP NAT-T and ESP overhead. I'd heard that ikev2 lowers the overhead
but if it's just in the negotiation exchange it may not be worth the
work.
Thanks
--
Chris
__o "All I was trying to do was get home from work."
_`\<,_ -Rosa Parks
___(*)/_(*).___o..___..o...ooO..._
Christopher Sean Hilton[chris/at/vindaloo/dot/com]
Re: PPPoE / isakmpd race
On 2016/02/16 20:04, Christopher Snell wrote: > Yes, the Listen-on is static. Unfortunately, changing the 0.0.0.0 in > hostname.pppoe0 breaks PPPoE. That will be ISP-dependent then, you can definitely hardcode it with some providers. > I think I could work around this in netstart by simply sleeping until > the link comes up (or a pre-defined timer elapses) but I'm struggling > to come up with a more generic approach. There might be more than one > PPPoE interface and more than one tunnel/PPP dependency that needs to > be accounted for. > > Perhaps another approach is to rework netstart to block up to > [configurable] seconds after bringing up any PPPoE connection before > continuing. This could default to no blocking but a maximum block > period could be defined in rc.conf.local for those who have PPPoE > dependencies. You could add "!sleep 5" or something to hostname.pppoe0 but obviously this would be racy and won't help if the connection is down when you boot. A more generic (but more complicated) approach would be to use ifstated to wait until the interface is up before running isakmpd.
Re: PPPoE / isakmpd race
Yes, the Listen-on is static. Unfortunately, changing the 0.0.0.0 in hostname.pppoe0 breaks PPPoE. I think I could work around this in netstart by simply sleeping until the link comes up (or a pre-defined timer elapses) but I'm struggling to come up with a more generic approach. There might be more than one PPPoE interface and more than one tunnel/PPP dependency that needs to be accounted for. Perhaps another approach is to rework netstart to block up to [configurable] seconds after bringing up any PPPoE connection before continuing. This could default to no blocking but a maximum block period could be defined in rc.conf.local for those who have PPPoE dependencies. Chris On Tue, Feb 16, 2016 at 7:46 AM, Stuart Henderson wrote: > Is the address in "Listen-on" a static address for this connection? > > If so, you should be able to use it directly in hostname.pppoe0 > instead of 0.0.0.0, and that might well solve this.
