Re: isakmpd ignoring contents of /etc/ipsec.conf
Am 2017-12-07 13:34, schrieb Jeremie Courreges-Anglas: On Thu, Dec 07 2017, Bernd <be...@kroenchenstadt.de> wrote: Am 2017-12-06 18:26, schrieb Jeremie Courreges-Anglas: On Wed, Dec 06 2017, Bernd <be...@kroenchenstadt.de> 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 <be...@kroenchenstadt.de> wrote: > Am 2017-12-06 18:26, schrieb Jeremie Courreges-Anglas: >> On Wed, Dec 06 2017, Bernd <be...@kroenchenstadt.de> 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 <be...@kroenchenstadt.de> 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 <be...@kroenchenstadt.de> 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
ipsec.conf
Hi all, i having ipsec.conf like this: ike esp from 10.200.136.0/21 to any \ local 10.64.135.246 peer 10.4.57.68 \ main auth hmac-sha1 enc aes group modp1024 \ quick auth hmac-sha1 enc aes group modp1024 \ psk b9278b3051cd17674305833971c22b11514eac51 and with ipsecctl -nvf ipsec.conf i'm getting C add [phase1-peer-10.4.57.68-local-10.64.135.246]:Transforms=phase1-transform-peer-10.4.57.68-local-10.64.135.246-RSA_SIG-SHA-AES128-MODP_3072 force C set [phase2-protocol-from-10.200.136.0/21-to-0.0.0.0/0]:Transforms=phase2-transform-from-10.200.136.0/21-to-0.0.0.0/0-AES128-SHA2_256-MODP_3072-TUNNEL force full output of ipsecctl -nvf in attachment but if i put psk before "main auth ..." i'm getting: C add [phase1-peer-10.4.57.68-local-10.64.135.246]:Transforms=phase1-transform-peer-10.4.57.68-local-10.64.135.246-PRE_SHARED-SHA-AES128-MODP_3072 force C set [phase2-protocol-from-10.200.136.0/21-to-0.0.0.0/0]:Transforms=phase2-transform-from-10.200.136.0/21-to-0.0.0.0/0-AES128-SHA2_256-MODP_3072-TUNNEL force but still i'm getting AES128-SHA2_256-MODP_3072 although i configured modp1024 or modp4096 and sha1 am i doing something wrong here? OpenBSD 6.1-current (GENERIC.MP) #10: Sun May 21 15:47:29 CEST 2017 hrv...@x3550m4.srce.hr:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34314383360 (32724MB) avail mem = 33268629504 (31727MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e67b000 (84 entries) bios0: vendor IBM version "-[D7E156DUS-2.30]-" date 11/09/2016 bios0: IBM IBM System x3550 M4 -[791425Z]- acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP TCPA ERST HEST HPET APIC MCFG OEM0 OEM1 SLIT SRAT SLIC SSDT SSDT SSDT SSDT DMAR acpi0: wakeup devices MRP1(S4) DCC0(S4) MRP3(S4) MRP5(S4) EHC2(S5) PEX0(S5) PEX7(S5) EHC1(S5) IP2P(S3) MRPB(S4) MRPC(S4) MRPD(S4) MRPF(S4) MRPG(S4) MRPH(S4) MRPI(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2100.31 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 2100305700 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2099.99 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2099.99 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2099.99 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2099.99 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 4, package 0 cpu5 at mainbus0: apid 10 (application processor) cpu5: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2099.99 MHz cpu5: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,C
Re: Flaw in ipsec.conf(5)?
On Fri, May 27, 2016 at 01:21:55PM +0200, Bruno Flueckiger wrote:
> After discussing this with Philipp Buehler off list I have reworked my
> diff to make things easier in the example.
>
> The paragraph which contains set skip on enc0 just before the ruleset
> is removed. All filtering in the rule set is done on sk0, skipping enc0
> entirely.
>
> The new rule set looks like this:
>
> block on sk0
> set skip on enc0
>
> pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
> port {500, 4500}
> pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
> port {500, 4500}
>
> pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
>
> pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \
> keep state (if-bound)
> pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \
> keep state (if-bound)
>
what then is the point of this section? to tell us to not filter
ipsec traffic?
what really needs to happen is for developers concerned with ipsec to
either recognise a change and adjust the filter rules accordingly, or
to say the idea of filtering enc traffic no longer makes sense and to
remove the section. or to tell you what's in ipsec.conf(5) is correct,
and why.
until that happens, the text will remain, i think.
jmc
>
> Index: sbin/ipsecctl/ipsec.conf.5
> =======
> RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
> retrieving revision 1.151
> diff -u -p -r1.151 ipsec.conf.5
> --- sbin/ipsecctl/ipsec.conf.59 Dec 2015 21:41:50 - 1.151
> +++ sbin/ipsecctl/ipsec.conf.527 May 2016 11:07:55 -
> @@ -493,20 +493,12 @@ Match traffic of phase 2 SAs using the
> keyword.
> .El
> .Pp
> -If the filtering rules specify to block everything by default,
> -the following rule
> -would ensure that IPsec traffic never hits the packet filtering engine,
> -and is therefore passed:
> -.Bd -literal -offset indent
> -set skip on enc0
> -.Ed
> -.Pp
> In the following example, all traffic is blocked by default.
> IPsec-related traffic from gateways {192.168.3.1, 192.168.3.2} and
> networks {10.0.1.0/24, 10.0.2.0/24} is permitted.
> .Bd -literal -offset indent
> block on sk0
> -block on enc0
> +set skip on enc0
>
> pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \e
> port {500, 4500}
> @@ -516,13 +508,9 @@ pass out on sk0 proto udp from 192.168.3
> pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
>
> -pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
> - keep state (if-bound)
> -pass out on enc0 proto ipencap from 192.168.3.1 to 192.168.3.2 \e
> - keep state (if-bound)
> -pass in on enc0 from 10.0.2.0/24 to 10.0.1.0/24 \e
> +pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \e
> keep state (if-bound)
> -pass out on enc0 from 10.0.1.0/24 to 10.0.2.0/24 \e
> +pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \e
> keep state (if-bound)
> .Ed
> .Pp
Re: Flaw in ipsec.conf(5)?
After discussing this with Philipp Buehler off list I have reworked my
diff to make things easier in the example.
The paragraph which contains set skip on enc0 just before the ruleset
is removed. All filtering in the rule set is done on sk0, skipping enc0
entirely.
The new rule set looks like this:
block on sk0
set skip on enc0
pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
port {500, 4500}
pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
port {500, 4500}
pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \
keep state (if-bound)
pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \
keep state (if-bound)
Index: sbin/ipsecctl/ipsec.conf.5
===
RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
retrieving revision 1.151
diff -u -p -r1.151 ipsec.conf.5
--- sbin/ipsecctl/ipsec.conf.5 9 Dec 2015 21:41:50 - 1.151
+++ sbin/ipsecctl/ipsec.conf.5 27 May 2016 11:07:55 -
@@ -493,20 +493,12 @@ Match traffic of phase 2 SAs using the
keyword.
.El
.Pp
-If the filtering rules specify to block everything by default,
-the following rule
-would ensure that IPsec traffic never hits the packet filtering engine,
-and is therefore passed:
-.Bd -literal -offset indent
-set skip on enc0
-.Ed
-.Pp
In the following example, all traffic is blocked by default.
IPsec-related traffic from gateways {192.168.3.1, 192.168.3.2} and
networks {10.0.1.0/24, 10.0.2.0/24} is permitted.
.Bd -literal -offset indent
block on sk0
-block on enc0
+set skip on enc0
pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \e
port {500, 4500}
@@ -516,13 +508,9 @@ pass out on sk0 proto udp from 192.168.3
pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
-pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
- keep state (if-bound)
-pass out on enc0 proto ipencap from 192.168.3.1 to 192.168.3.2 \e
- keep state (if-bound)
-pass in on enc0 from 10.0.2.0/24 to 10.0.1.0/24 \e
+pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \e
keep state (if-bound)
-pass out on enc0 from 10.0.1.0/24 to 10.0.2.0/24 \e
+pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \e
keep state (if-bound)
.Ed
.Pp
Re: Flaw in ipsec.conf(5)?
On Thu, May 26, 2016 at 08:41:49AM +0100, Jason McIntyre wrote:
> On Tue, May 24, 2016 at 10:53:16AM +0200, Bruno Flueckiger wrote:
> > Hi,
> >
> > I've tested IPsec connections in my lab. The setup looks like this:
> >
> > [cli] <-- vlan10 --> [gw1] <> [inet] <> [gw2] <-- vlan20 --> [srv]
> > IPsec=
>
> i think you should provide more details of your setup first. for
> example, ipsec.conf(5) shows pf rules for ipencap but you only provide a
> small snippet of your pf.conf. no vlan details. none of your tcpdump
> output that leads you to this conclusion. no routing details.
>
> then keep your fingers crossed. i think most people run for the hills
> when they see ipsec mail.
>
> jmc
>
The network config looks like this:
vlan10: [cli] .11 <- 10.19.1.0/24 -> .1 [gw1]
vlan20: [gw2] .1 <- 10.81.1.0/24 -> .11 [srv]
The simulated internet between the gateways is one OpenBSD box which
forwards packets between the two subnets 10.0.19.0/24 and 10.0.81.0/24:
[gw1] .2 <- 10.0.19.0/24 -> .1 [inet] .1 <- 10.0.81.0/24 -> .2 [gw2]
There are no vlans defined for the two subnets between the gateways and
the [inet] box. All machines are running OpenBSD 5.9-release on a
VMware ESXi 5.5. All network adapters are vmx, each adapter is connected
to a vSphere standard switch. There is one vSphere switch for each
subnet. None of the switches have physical nics assigned.
This is the ipsec.conf on [gw1]:
local_ip="10.0.19.2"
remote_ip="10.0.81.2"
local_net="10.19.1.0/24"
remote_net="10.81.1.0/24"
ike esp from $local_ip to $remote_ip
ike esp from $local_ip to $remote_net
ike esp from $local_net to $remote_net
This is the pf.conf on [gw1] in the version that blocks ipsec traffic on
interface enc0:
wan_if="vmx0"
local_net="10.19.1.0/24"
remote_ip="10.0.81.2"
remote_net="10.81.1.0/24"
icmp_types="{ echoreq unreach }"
ike_ports="{ isakmp ipsec-nat-t }"
set block-policy return
set skip on lo
match in all scrub (no-df random-id reassemble tcp)
block log all
pass in from (self)
pass out on $wan_if from (self) to any keep state
pass inet proto icmp all icmp-type $icmp_types keep state
pass in on vlan10 inet proto tcp from $local_net to vlan10 port ssh \
keep state (if-bound)
# Allow traffic for IPsec tunnel setup
pass in on $wan_if proto udp from $remote_ip to $wan_if \
port $ike_ports
pass out on $wan_if proto udp from $wan_ifto $remote_ip \
port $ike_ports
# Allow esp packets between tunnel endpoints
pass in on $wan_if proto esp from $remote_ip to $wan_if \
keep state (if-bound)
pass out on $wan_if proto esp from $wan_ifto $remote_ip \
keep state (if-bound)
# Allow encapsulated IP packets
pass in on enc0 proto ipencap from $remote_ip to $wan_if \
keep state (if-bound)
pass out on enc0 proto ipencap from $wan_ifto $remote_ip \
keep state (if-bound)
# Allow traffic between the subnets
pass in on vlan10 from $local_net to $remote_net keep state
pass out on enc0 from $local_net to $remote_net keep state (if-bound)
pass in on enc0 from $remote_net to $local_net keep state (if-bound)
pass out on vlan10 from $remote_net to $local_net keep state
I run tcpdump -nettti pflog0 on [gw1]. Then I try to connect from [cli]
to [srv] by running ssh 10.81.1.11. This is the output from tcpdump when
using the above pf.conf on [gw1]:
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
May 27 08:27:04.754155 rule 1/(match) block out on enc0: esp 10.0.19.2 >
10.0.81.2 spi 0x621d35d7 seq 8 len 120
May 27 08:27:10.743030 rule 1/(match) block out on enc0: esp 10.0.19.2 >
10.0.81.2 spi 0x621d35d7 seq 9 len 120
May 27 08:27:22.739668 rule 1/(match) block out on enc0: esp 10.0.19.2 >
10.0.81.2 spi 0x621d35d7 seq 10 len 120
May 27 08:27:46.732233 rule 1/(match) block out on enc0: esp 10.0.19.2 >
10.0.81.2 spi 0x621d35d7 seq 11 len 120
This made me include the interface enc0 in the two rules for esp
packets. After this the connection works as expected. That made me write
the patch.
If something is unclear in my description of even more details are
needed I'm happy to provide those.
Cheers,
Bruno
Re: Flaw in ipsec.conf(5)?
On Tue, May 24, 2016 at 10:53:16AM +0200, Bruno Flueckiger wrote:
> Hi,
>
> I've tested IPsec connections in my lab. The setup looks like this:
>
> [cli] <-- vlan10 --> [gw1] <> [inet] <> [gw2] <-- vlan20 --> [srv]
> IPsec=
>
> During the testing I think I've found a flaw in ipsec.conf(5). According
> to the man page the esp packets need to be passed on interface sk0:
>
> block on sk0
> block on enc0
>
> pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
> port {500, 4500}
> pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
> port {500, 4500}
>
> pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
>
> My test setup didn't allow communication between [cli] and [srv]. Checking
> the reason on [gw1] using tcpdump -nettti pflog0 shows that esp packets
> are blocked by pf on enc0. So I included the interface enc0 in the pass
> rules for esp packets. After this the connections work as expected.
>
> As a result of my tests I've created the diff below for ipsec.conf(5). Is
> this ok or did I miss something?
>
i think you should provide more details of your setup first. for
example, ipsec.conf(5) shows pf rules for ipencap but you only provide a
small snippet of your pf.conf. no vlan details. none of your tcpdump
output that leads you to this conclusion. no routing details.
then keep your fingers crossed. i think most people run for the hills
when they see ipsec mail.
jmc
> Cheers,
> Bruno
>
> Index: sbin/ipsecctl/ipsec.conf.5
> ===
> RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
> retrieving revision 1.151
> diff -u -p -r1.151 ipsec.conf.5
> --- sbin/ipsecctl/ipsec.conf.59 Dec 2015 21:41:50 - 1.151
> +++ sbin/ipsecctl/ipsec.conf.524 May 2016 08:24:49 -
> @@ -513,8 +513,8 @@ pass in on sk0 proto udp from 192.168.3
> pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \e
> port {500, 4500}
>
> -pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> -pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
> +pass in on {sk0 enc0} proto esp from 192.168.3.2 to 192.168.3.1
> +pass out on {sk0 enc0} proto esp from 192.168.3.1 to 192.168.3.2
>
> pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
> keep state (if-bound)
Re: Flaw in ipsec.conf(5)?
Am 24.05.2016 10:53 schrieb Bruno Flueckiger: As a result of my tests I've created the diff below for ipsec.conf(5). Is this ok or did I miss something? You missed the 'set skip on enc0' a bit up. -- pb
Flaw in ipsec.conf(5)?
Hi,
I've tested IPsec connections in my lab. The setup looks like this:
[cli] <-- vlan10 --> [gw1] <> [inet] <> [gw2] <-- vlan20 --> [srv]
IPsec=
During the testing I think I've found a flaw in ipsec.conf(5). According
to the man page the esp packets need to be passed on interface sk0:
block on sk0
block on enc0
pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
port {500, 4500}
pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
port {500, 4500}
pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
My test setup didn't allow communication between [cli] and [srv]. Checking
the reason on [gw1] using tcpdump -nettti pflog0 shows that esp packets
are blocked by pf on enc0. So I included the interface enc0 in the pass
rules for esp packets. After this the connections work as expected.
As a result of my tests I've created the diff below for ipsec.conf(5). Is
this ok or did I miss something?
Cheers,
Bruno
Index: sbin/ipsecctl/ipsec.conf.5
===
RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
retrieving revision 1.151
diff -u -p -r1.151 ipsec.conf.5
--- sbin/ipsecctl/ipsec.conf.5 9 Dec 2015 21:41:50 - 1.151
+++ sbin/ipsecctl/ipsec.conf.5 24 May 2016 08:24:49 -
@@ -513,8 +513,8 @@ pass in on sk0 proto udp from 192.168.3
pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \e
port {500, 4500}
-pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
-pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
+pass in on {sk0 enc0} proto esp from 192.168.3.2 to 192.168.3.1
+pass out on {sk0 enc0} proto esp from 192.168.3.1 to 192.168.3.2
pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
keep state (if-bound)
reference ipsec.conf in ipsec.4 under SEE ALSO?
I think it make sense for ipsec.4 to reference it's own configuration file under SEE ALSO. Index: ipsec.4 === RCS file: /cvs/src/share/man/man4/ipsec.4,v retrieving revision 1.83 diff -u -p -r1.83 ipsec.4 --- ipsec.4 16 Feb 2015 16:38:54 - 1.83 +++ ipsec.4 18 Mar 2016 20:51:05 - @@ -378,6 +378,7 @@ allocations). .\".Xr ipcomp 4 , .Xr options 4 , .Xr iked 8 , +.Xr ipsec.conf 5 , .Xr ipsecctl 8 , .Xr isakmpd 8 , .Xr sysctl 8
Re: reference ipsec.conf in ipsec.4 under SEE ALSO?
> From: "Jason McIntyre" <j...@kerhand.co.uk> > To: "misc" <misc@openbsd.org> > Sent: Friday, March 18, 2016 5:40:07 PM > Subject: Re: reference ipsec.conf in ipsec.4 under SEE ALSO? > On Fri, Mar 18, 2016 at 04:59:29PM -0400, Rob Pierce wrote: >> I think it make sense for ipsec.4 to reference it's own configuration file >> under > > SEE ALSO. > fixed, thanks. but note SEE ALSO is sorted by section first, so it should > be after the options Xr. > jmc I totally missed that, thanks! Rob
Re: reference ipsec.conf in ipsec.4 under SEE ALSO?
On Fri, Mar 18, 2016 at 04:59:29PM -0400, Rob Pierce wrote: > I think it make sense for ipsec.4 to reference it's own configuration file > under SEE ALSO. > fixed, thanks. but note SEE ALSO is sorted by section first, so it should be after the options Xr. jmc > Index: ipsec.4 > === > RCS file: /cvs/src/share/man/man4/ipsec.4,v > retrieving revision 1.83 > diff -u -p -r1.83 ipsec.4 > --- ipsec.4 16 Feb 2015 16:38:54 - 1.83 > +++ ipsec.4 18 Mar 2016 20:51:05 - > @@ -378,6 +378,7 @@ allocations). > .\".Xr ipcomp 4 , > .Xr options 4 , > .Xr iked 8 , > +.Xr ipsec.conf 5 , > .Xr ipsecctl 8 , > .Xr isakmpd 8 , > .Xr sysctl 8
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
ipsec.conf parsing
As far as I can tell, if a commented line on ipsec.conf ends with \ then the following line will also be considered a comment (if the next line also ends with \ the commenting is propagated). For example #ike esp from A.A.A.A to C.C.C.C \ ike esp from A.A.A.A to B.B.B.B \ srcid foo.example.com dstid bar.example.com is treated as a commented block, instead of setting up a tunnel from A.A.A.A to B.B.B.B. I find this a bit surprising... What should be fixed: the parser, ipsec.conf.5 or my expectations? All the best Zé --
Re: ipsec.conf parsing
On Wed, Mar 19, 2014 at 10:22:43AM +, Zé Loff wrote: As far as I can tell, if a commented line on ipsec.conf ends with \ then the following line will also be considered a comment (if the next line also ends with \ the commenting is propagated). For example #ike esp from A.A.A.A to C.C.C.C \ ike esp from A.A.A.A to B.B.B.B \ srcid foo.example.com dstid bar.example.com is treated as a commented block, instead of setting up a tunnel from A.A.A.A to B.B.B.B. I find this a bit surprising... What should be fixed: the parser, ipsec.conf.5 or my expectations? Don't know what should be fixed, but it's exactly the same thing in pf.conf -- mabla
Re: ipsec.conf parsing
On 2014-03-19, Zé Loff zel...@zeloff.org wrote: As far as I can tell, if a commented line on ipsec.conf ends with \ then the following line will also be considered a comment (if the next line also ends with \ the commenting is propagated). For example #ike esp from A.A.A.A to C.C.C.C \ ike esp from A.A.A.A to B.B.B.B \ srcid foo.example.com dstid bar.example.com is treated as a commented block, instead of setting up a tunnel from A.A.A.A to B.B.B.B. I find this a bit surprising... What should be fixed: the parser, ipsec.conf.5 or my expectations? Manpages for all the programs using parse.y were supposed to have unified text about multiline comment handling, but I missed ipsec.conf(5) when I changed the others (back in 2011). ipsec.conf(5) is now fixed, thanks.
Re: ipsec.conf parsing
On 3/19/14 6:22 AM, Zé Loff wrote: As far as I can tell, if a commented line on ipsec.conf ends with \ then the following line will also be considered a comment (if the next line also ends with \ the commenting is propagated). For example #ike esp from A.A.A.A to C.C.C.C \ ike esp from A.A.A.A to B.B.B.B \ srcid foo.example.com dstid bar.example.com is treated as a commented block, instead of setting up a tunnel from A.A.A.A to B.B.B.B. I find this a bit surprising... What should be fixed: the parser, ipsec.conf.5 or my expectations? All the best Zé In my totally-not-in-depth analysis (I don't have much time before I need to run to class), it seems to be because lgetc (src/sbin/pfctl/parse.y line 5556) pastes \\\n together, which happens before lines are evaluated for comments in yylex on line 5655, which calls the not-comment-aware lgetc which just blindly joins lines ending with \ making it appear to the comment-evaluating code that the whole thing is indeed one line that begins with a comment. I'm not sure if that's the desired behavior. fparseln(3) behaves in the way you probably expected, so I'm inclined to say that it isn't.
Multiple srcnat for one src in ipsec.conf
Hello, I've one question. Is it possible to configure two or more srcnat values for one tunnel? I've to hide two of our subnets behind one subnet in a tunnel to a customer. Example: ike esp from 10.30.172.32/29 (10.77.3.0/24,172.30.0.0/16) to 10.78.1.0/24 Is this possible? Thanks. Regards, Erwin
Re: Interface/IP limit on isakmpd, no listen-on in ipsec.conf, IPSec failover enhancement, IPSec tunnel rebuild enhancement
Hi,
Does anyone have any ideas on this? How can we configure isakmpd to
only listen on certain IP addresses to avoid this limitation when it
tries to listen on *every* IP address?
I see listen-on in isakmpd.conf, but we are using ipsec.conf and I
understand these are mutually-exclusive..
Cheers, Andy.
On Wed 12 Feb 2014 12:22:57 GMT, andy wrote:
Hi,
I think this is a fairly simple one.
Our firewalls are growing in complexity and the number of interfaces and
IPs as time goes on, and we recently hit an isakmpd limit.
When isakmpd starts it tries to bind to *every* single IP on the system.
We have a LOT of IPs and isakmpd now fails to initialise;
2014-02-12T10:40:29.386318+00:00 brfw1 isakmpd[404]: udp_encap_make:
socket (2, 2, 17): Too many open files
2014-02-12T10:40:29.386352+00:00 brfw1 isakmpd[404]: virtual_bind_if:
failed to create a socket on 10.2.8.254
2014-02-12T10:40:29.386657+00:00 brfw1 isakmpd[404]: virtual_init: could
not bind the ISAKMP port(s) on all interfaces: Too many open files
More log at bottom..
We only want isakmpd to listen on the CARP IP address on the external
interface (and probably the physical IPs on the external interface), not
*all* IPs.
The work around for now was to add '-4' to the isakmpd daemon to restrict
it to our v4 addresses. However we will very soon have even too many v4
addresses for isakmpd to cope and so need a way to instruct isakmpd to only
bind the necessary IPs.
This would also provide a security enhancement??
Others have reported this limitation before;
http://www.monkey.org/openbsd/archive2/misc/200502/msg00686.html
Also if someone else finds these useful (I will commit to source one
day..), I have two primitive but *very* effective enhancements I have made
to /etc/rc.d/sasyncd and /etc/rc.d/isakmpd to share when running IPSec on a
carp pair (I am absolutely sure these could be more elegant in
implementation, but they work and you should get the idea)..
First enhancement, when running isakmpd with carp and sasyncd, you must
use the -S and -K flags on isakmpd. This ensures isakmpd starts in passive
mode and does not start negotiating with the other side *unless* it is the
carp master. Makes perfect sense..
On the master, isakmpd starts in passive, discovers it is master and so
reads and loads ipsec.conf, and starts negotiating with other side
On the backup, isakmod starts in passive, does nothing more.
If a failover occurs however, the VPNs do not work for a lng time!
(this is because isakmpd on the backup never read the ipsec.conf file so
when it is made active it doesn't know what to do..)
/etc/rc.d/sasyncd;
#!/bin/sh
#
# $OpenBSD: sasyncd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon=/usr/sbin/sasyncd
. /etc/rc.d/rc.subr
pexp=sasyncd: \[priv\]
rc_start() {
sleep 10
${rcexec} ${daemon} ${daemon_flags} ${_bg}
sleep 5
ipsecctl -f /etc/ipsec.conf
}
rc_cmd $1
This fix simply ensures that the carp-backup isakmpd reads the ipsec.conf
after starting in passive mode and has settled. VPN failover's now happen
in ~2-3 seconds.
Second enhancement, when stopping isakmpd on the master or backup with
'/etc/rc.d/isakmpd' stop or restart, subsequent starting of the tunnels can
take a very long time. This seems to be because stopping isakmpd simply
tears the daemon down without deconstructing the trust keys / policies.
Leaving obsolete expiring policies on the remote side. So restarting
isakmpd can take a long time until the other side flushes or times out.
/etc/rc.d/isakmpd;
#!/bin/sh
#
# $OpenBSD: isakmpd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon=/sbin/isakmpd
. /etc/rc.d/rc.subr
pexp=isakmpd: monitor \[priv\]
rc_pre() {
[ X${sasyncd_flags} != XNO ] \
daemon_flags=-S ${daemon_flags}
return 0
}
rc_stop() {
if [ `ifconfig | grep status: master | wc -l` 0 ]; then ipsecctl
-d -f /etc/ipsec.conf; fi
sleep 1
if [ `ifconfig | grep status: master | wc -l` 0 ]; then ipsecctl
-d -f /etc/ipsec.conf; fi
if [ `ifconfig | grep status: master | wc -l` 0 ]; then ipsecctl
-F -f /etc/ipsec.conf; fi
pkill -f ^${pexp}
}
rc_cmd $1
This fix simply gracefully deletes the flows (and informs the other side
to do the same), and flushes the SPD's and SAD's cleanly before destroying
the daemon. Subsequent restarts now allow IPSec tunnels to come up
immediately..
Hope this helps someone :)
Cheers, Andy.
isakmpd binding error;
2014-02-12T10:40:29.382031+00:00 brfw1 isakmpd[404]: udp_encap_make:
transport 0x20615b500 socket 120 ip fe80:14::200:5eff:fe00:103 port 4500
2014-02-12T10:40:29.382242+00:00 brfw1 isakmpd[404]: udp_make: transport
0x20615bd00 socket 121 ip 10.0.1.254 port 500
2014-02-12T10:40:29.382423+00:00 brfw1 isakmpd[404]: udp_encap_make:
transport 0x20615ba80 socket 122 ip 10.0.1.254 port 4500
2014-02-12T10:40:29.382655+00:00 brfw1 isakmpd[404]: udp_make: transport
0x20615bc80 socket 123 ip 10.2.3.254 port 500
2014-02-12T10:40:29.382873+00:00 brfw1 isakmpd[404
Re: Interface/IP limit on isakmpd, no listen-on in ipsec.conf, IPSec failover enhancement, IPSec tunnel rebuild enhancement
Face-palm!!!
When I tried it before I only created /etc/isakmpd.conf
not;
/etc/isakmpd/isakmpd.conf
chmod 600 /etc/isakmpd/isakmpd.conf
isakmpd.conf
[general]
listen-on=pubip1,pubip2,pubip3
Dohh, Have to miss the obvious in a man page every now and then I guess..
Hopefully my fail-over stability tweaks help someone in return for the
misc@ noise Ha
Cheers, Andy.
Thanks Rogier...
On 17/02/14 17:10, Rogier Krieger wrote:
It's been a while since I tried, but I seem to recall my setup ran
happily with a (minimal) isakmpd.conf and ipsec.conf.
I kept my settings limited to the [General] section, but that should
cover your listen-on test.
Regards,
Rogier
On Mon, Feb 17, 2014 at 6:03 PM, Andy a...@brandwatch.com
mailto:a...@brandwatch.com wrote:
Hi,
Does anyone have any ideas on this? How can we configure isakmpd
to only listen on certain IP addresses to avoid this limitation
when it tries to listen on *every* IP address?
I see listen-on in isakmpd.conf, but we are using ipsec.conf and I
understand these are mutually-exclusive..
Cheers, Andy.
On Wed 12 Feb 2014 12:22:57 GMT, andy wrote:
Hi,
I think this is a fairly simple one.
Our firewalls are growing in complexity and the number of
interfaces and
IPs as time goes on, and we recently hit an isakmpd limit.
When isakmpd starts it tries to bind to *every* single IP on
the system.
We have a LOT of IPs and isakmpd now fails to initialise;
2014-02-12T10:40:29.386318+00:00 brfw1 isakmpd[404]:
udp_encap_make:
socket (2, 2, 17): Too many open files
2014-02-12T10:40:29.386352+00:00 brfw1 isakmpd[404]:
virtual_bind_if:
failed to create a socket on 10.2.8.254
2014-02-12T10:40:29.386657+00:00 brfw1 isakmpd[404]:
virtual_init: could
not bind the ISAKMP port(s) on all interfaces: Too many open files
More log at bottom..
We only want isakmpd to listen on the CARP IP address on the
external
interface (and probably the physical IPs on the external
interface), not
*all* IPs.
The work around for now was to add '-4' to the isakmpd daemon
to restrict
it to our v4 addresses. However we will very soon have even
too many v4
addresses for isakmpd to cope and so need a way to instruct
isakmpd to only
bind the necessary IPs.
This would also provide a security enhancement??
Others have reported this limitation before;
http://www.monkey.org/openbsd/archive2/misc/200502/msg00686.html
Also if someone else finds these useful (I will commit to
source one
day..), I have two primitive but *very* effective enhancements
I have made
to /etc/rc.d/sasyncd and /etc/rc.d/isakmpd to share when
running IPSec on a
carp pair (I am absolutely sure these could be more elegant in
implementation, but they work and you should get the idea)..
First enhancement, when running isakmpd with carp and sasyncd,
you must
use the -S and -K flags on isakmpd. This ensures isakmpd
starts in passive
mode and does not start negotiating with the other side
*unless* it is the
carp master. Makes perfect sense..
On the master, isakmpd starts in passive, discovers it is
master and so
reads and loads ipsec.conf, and starts negotiating with other side
On the backup, isakmod starts in passive, does nothing more.
If a failover occurs however, the VPNs do not work for a
lng time!
(this is because isakmpd on the backup never read the
ipsec.conf file so
when it is made active it doesn't know what to do..)
/etc/rc.d/sasyncd;
#!/bin/sh
#
# $OpenBSD: sasyncd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon=/usr/sbin/sasyncd
. /etc/rc.d/rc.subr
pexp=sasyncd: \[priv\]
rc_start() {
sleep 10
${rcexec} ${daemon} ${daemon_flags} ${_bg}
sleep 5
ipsecctl -f /etc/ipsec.conf
}
rc_cmd $1
This fix simply ensures that the carp-backup isakmpd reads the
ipsec.conf
after starting in passive mode and has settled. VPN failover's
now happen
in ~2-3 seconds.
Second enhancement, when stopping isakmpd on the master or
backup with
'/etc/rc.d/isakmpd' stop or restart, subsequent starting of
the tunnels can
take a very long time. This seems to be because stopping
isakmpd simply
tears the daemon down without deconstructing the trust keys /
policies.
Leaving obsolete expiring policies on the remote side
Re: Interface/IP limit on isakmpd, no listen-on in ipsec.conf, IPSec failover enhancement, IPSec tunnel rebuild enhancement
andy(a...@brandwatch.com) on 2014.02.12 12:22:57 +: Hi, I think this is a fairly simple one. Our firewalls are growing in complexity and the number of interfaces and IPs as time goes on, and we recently hit an isakmpd limit. When isakmpd starts it tries to bind to *every* single IP on the system. We have a LOT of IPs and isakmpd now fails to initialise; 2014-02-12T10:40:29.386318+00:00 brfw1 isakmpd[404]: udp_encap_make: socket (2, 2, 17): Too many open files 2014-02-12T10:40:29.386352+00:00 brfw1 isakmpd[404]: virtual_bind_if: failed to create a socket on 10.2.8.254 2014-02-12T10:40:29.386657+00:00 brfw1 isakmpd[404]: virtual_init: could not bind the ISAKMP port(s) on all interfaces: Too many open files More log at bottom.. We only want isakmpd to listen on the CARP IP address on the external interface (and probably the physical IPs on the external interface), not *all* IPs. The work around for now was to add '-4' to the isakmpd daemon to restrict it to our v4 addresses. However we will very soon have even too many v4 addresses for isakmpd to cope and so need a way to instruct isakmpd to only bind the necessary IPs. This would also provide a security enhancement?? Others have reported this limitation before; http://www.monkey.org/openbsd/archive2/misc/200502/msg00686.html maybe this works for you: # cat /etc/isakmpd/isakmpd.conf [General] Listen-on = em0
Interface/IP limit on isakmpd, no listen-on in ipsec.conf, IPSec failover enhancement, IPSec tunnel rebuild enhancement
Hi,
I think this is a fairly simple one.
Our firewalls are growing in complexity and the number of interfaces and
IPs as time goes on, and we recently hit an isakmpd limit.
When isakmpd starts it tries to bind to *every* single IP on the system.
We have a LOT of IPs and isakmpd now fails to initialise;
2014-02-12T10:40:29.386318+00:00 brfw1 isakmpd[404]: udp_encap_make:
socket (2, 2, 17): Too many open files
2014-02-12T10:40:29.386352+00:00 brfw1 isakmpd[404]: virtual_bind_if:
failed to create a socket on 10.2.8.254
2014-02-12T10:40:29.386657+00:00 brfw1 isakmpd[404]: virtual_init: could
not bind the ISAKMP port(s) on all interfaces: Too many open files
More log at bottom..
We only want isakmpd to listen on the CARP IP address on the external
interface (and probably the physical IPs on the external interface), not
*all* IPs.
The work around for now was to add '-4' to the isakmpd daemon to restrict
it to our v4 addresses. However we will very soon have even too many v4
addresses for isakmpd to cope and so need a way to instruct isakmpd to only
bind the necessary IPs.
This would also provide a security enhancement??
Others have reported this limitation before;
http://www.monkey.org/openbsd/archive2/misc/200502/msg00686.html
Also if someone else finds these useful (I will commit to source one
day..), I have two primitive but *very* effective enhancements I have made
to /etc/rc.d/sasyncd and /etc/rc.d/isakmpd to share when running IPSec on a
carp pair (I am absolutely sure these could be more elegant in
implementation, but they work and you should get the idea)..
First enhancement, when running isakmpd with carp and sasyncd, you must
use the -S and -K flags on isakmpd. This ensures isakmpd starts in passive
mode and does not start negotiating with the other side *unless* it is the
carp master. Makes perfect sense..
On the master, isakmpd starts in passive, discovers it is master and so
reads and loads ipsec.conf, and starts negotiating with other side
On the backup, isakmod starts in passive, does nothing more.
If a failover occurs however, the VPNs do not work for a lng time!
(this is because isakmpd on the backup never read the ipsec.conf file so
when it is made active it doesn't know what to do..)
/etc/rc.d/sasyncd;
#!/bin/sh
#
# $OpenBSD: sasyncd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon=/usr/sbin/sasyncd
. /etc/rc.d/rc.subr
pexp=sasyncd: \[priv\]
rc_start() {
sleep 10
${rcexec} ${daemon} ${daemon_flags} ${_bg}
sleep 5
ipsecctl -f /etc/ipsec.conf
}
rc_cmd $1
This fix simply ensures that the carp-backup isakmpd reads the ipsec.conf
after starting in passive mode and has settled. VPN failover's now happen
in ~2-3 seconds.
Second enhancement, when stopping isakmpd on the master or backup with
'/etc/rc.d/isakmpd' stop or restart, subsequent starting of the tunnels can
take a very long time. This seems to be because stopping isakmpd simply
tears the daemon down without deconstructing the trust keys / policies.
Leaving obsolete expiring policies on the remote side. So restarting
isakmpd can take a long time until the other side flushes or times out.
/etc/rc.d/isakmpd;
#!/bin/sh
#
# $OpenBSD: isakmpd,v 1.1 2011/07/06 18:55:36 robert Exp $
daemon=/sbin/isakmpd
. /etc/rc.d/rc.subr
pexp=isakmpd: monitor \[priv\]
rc_pre() {
[ X${sasyncd_flags} != XNO ] \
daemon_flags=-S ${daemon_flags}
return 0
}
rc_stop() {
if [ `ifconfig | grep status: master | wc -l` 0 ]; then ipsecctl
-d -f /etc/ipsec.conf; fi
sleep 1
if [ `ifconfig | grep status: master | wc -l` 0 ]; then ipsecctl
-d -f /etc/ipsec.conf; fi
if [ `ifconfig | grep status: master | wc -l` 0 ]; then ipsecctl
-F -f /etc/ipsec.conf; fi
pkill -f ^${pexp}
}
rc_cmd $1
This fix simply gracefully deletes the flows (and informs the other side
to do the same), and flushes the SPD's and SAD's cleanly before destroying
the daemon. Subsequent restarts now allow IPSec tunnels to come up
immediately..
Hope this helps someone :)
Cheers, Andy.
isakmpd binding error;
2014-02-12T10:40:29.382031+00:00 brfw1 isakmpd[404]: udp_encap_make:
transport 0x20615b500 socket 120 ip fe80:14::200:5eff:fe00:103 port 4500
2014-02-12T10:40:29.382242+00:00 brfw1 isakmpd[404]: udp_make: transport
0x20615bd00 socket 121 ip 10.0.1.254 port 500
2014-02-12T10:40:29.382423+00:00 brfw1 isakmpd[404]: udp_encap_make:
transport 0x20615ba80 socket 122 ip 10.0.1.254 port 4500
2014-02-12T10:40:29.382655+00:00 brfw1 isakmpd[404]: udp_make: transport
0x20615bc80 socket 123 ip 10.2.3.254 port 500
2014-02-12T10:40:29.382873+00:00 brfw1 isakmpd[404]: udp_encap_make:
transport 0x20615bf80 socket 124 ip 10.2.3.254 port 4500
2014-02-12T10:40:29.383485+00:00 brfw1 isakmpd[404]: udp_make: transport
0x20615b880 socket 127 ip fe80:15::200:5eff:fe00:104 port 500
2014-02-12T10:40:29.383524+00:00 brfw1 isakmpd[404]: udp_encap_make:
socket (24, 2, 17): Too many open files
2014-02-12T10:40:29.383549+00:00 brfw1 isakmpd[404
Re: how to compare ipsec.conf and isakmpd.conf settings?
Original message from Stuart Henderson at 26-9-2013 23:58 On 2013-09-26, Daniel Polak dan...@sys.nl wrote: I'd like to see how isakmpd interprets the settings in ipsec.conf and isakmpd.conf and would like to compare those interpretations. ipsecctl -nvf /etc/ipsec.conf shows the settings from ipsec.conf as they would be used by isakmpd but don't see how to do the same with isakmpd.conf. How can I get the settings from isakmpd.conf and ipsec.conf in the same format so I can compare them? isakmpd does not interpret settings in ipsec.conf *at all*; ipsecctl converts them into control commands which generate isakmpd.conf sections. to compare, you'll need to adjust the format manually; ipsecctl -nvf outputs a bunch of lines like this: C set [sectionname]:variable1=setting1 C set [sectionname]:variable2=setting2 C set [sectionname]:variable3=setting3 which equate to isakmpd.conf entries like this: [sectionname] variable1=setting1 variable2=setting2 variable3=setting3 Writing how isakmpd interprets the settings in ipsec.conf was slightly misleading, sorry about that. I do understand that ipsecctl reads ipsec.conf, generates control commands and thereby sets up isakmpd. I have now solved my immediate problem and things are working (I overlooked that the connection was set for passive mode in ipsec.conf and for active mode in isakmpd, and the connection only worked when the my side initiated it). What would have helped me solve this is a way to see what the current configuration of isakmpd looks like (irrespective of whether it was loaded from isakmpd.conf or from ipsec.conf). It appears there is no equivalent of a C get all command to the FIFO to get the configuration values of all sections in the running isakmpd configuration. In spite of having used isakmpd for many years I still don't find troubleshooting VPN issues easy :-( Daniel
Re: how to compare ipsec.conf and isakmpd.conf settings?
On 9/27/13 10:46 AM, Daniel Polak wrote: What would have helped me solve this is a way to see what the current configuration of isakmpd looks like (irrespective of whether it was loaded from isakmpd.conf or from ipsec.conf). It appears there is no equivalent of a C get all command to the FIFO to get the configuration values of all sections in the running isakmpd configuration. If you send isakmpd a SIGUSR1, it will generate /var/run/isakmpd.report which also has the running configuration in it.
how to compare ipsec.conf and isakmpd.conf settings?
On a computer running OpenBSD 5.3 system I am migrating from an isakmpd.conf based configuration to an ipsec.conf based configuration. The tunnel comes up and works correctly when using isakmpd.conf but I can't get the tunnel to come up when I use ipsec.conf. As far as I can see ipsec.conf contains the same settings as the settings that are in isakmpd.conf. The error message when using ipsec.conf is: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC. This means the proposal from the peer does not match the configuration added by ipsecctl and isakmpd is trying to use its default settings. I've double-checked the settings ipsec.conf and especially the IP addresses. I have also looked at the packets and the isakmpd debug output but all I can see is the peer offering a proposal that matches what is in ipsec.conf. I'd like to see how isakmpd interprets the settings in ipsec.conf and isakmpd.conf and would like to compare those interpretations. ipsecctl -nvf /etc/ipsec.conf shows the settings from ipsec.conf as they would be used by isakmpd but don't see how to do the same with isakmpd.conf. How can I get the settings from isakmpd.conf and ipsec.conf in the same format so I can compare them? Daniel
Re: how to compare ipsec.conf and isakmpd.conf settings?
As naddy@ answered this already for ipsec outgoing address translation question on this list, 'ipsecctl -nv' is the right way to go. //mxb On 26 sep 2013, at 18:04, Daniel Polak dan...@sys.nl wrote: On a computer running OpenBSD 5.3 system I am migrating from an isakmpd.conf based configuration to an ipsec.conf based configuration. The tunnel comes up and works correctly when using isakmpd.conf but I can't get the tunnel to come up when I use ipsec.conf. As far as I can see ipsec.conf contains the same settings as the settings that are in isakmpd.conf. The error message when using ipsec.conf is: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC. This means the proposal from the peer does not match the configuration added by ipsecctl and isakmpd is trying to use its default settings. I've double-checked the settings ipsec.conf and especially the IP addresses. I have also looked at the packets and the isakmpd debug output but all I can see is the peer offering a proposal that matches what is in ipsec.conf. I'd like to see how isakmpd interprets the settings in ipsec.conf and isakmpd.conf and would like to compare those interpretations. ipsecctl -nvf /etc/ipsec.conf shows the settings from ipsec.conf as they would be used by isakmpd but don't see how to do the same with isakmpd.conf. How can I get the settings from isakmpd.conf and ipsec.conf in the same format so I can compare them? Daniel
Re: how to compare ipsec.conf and isakmpd.conf settings?
On 2013-09-26, Daniel Polak dan...@sys.nl wrote: On a computer running OpenBSD 5.3 system I am migrating from an isakmpd.conf based configuration to an ipsec.conf based configuration. The tunnel comes up and works correctly when using isakmpd.conf but I can't get the tunnel to come up when I use ipsec.conf. As far as I can see ipsec.conf contains the same settings as the settings that are in isakmpd.conf. The error message when using ipsec.conf is: attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC. This means the proposal from the peer does not match the configuration added by ipsecctl and isakmpd is trying to use its default settings. I've double-checked the settings ipsec.conf and especially the IP addresses. I have also looked at the packets and the isakmpd debug output but all I can see is the peer offering a proposal that matches what is in ipsec.conf. I'd like to see how isakmpd interprets the settings in ipsec.conf and isakmpd.conf and would like to compare those interpretations. ipsecctl -nvf /etc/ipsec.conf shows the settings from ipsec.conf as they would be used by isakmpd but don't see how to do the same with isakmpd.conf. How can I get the settings from isakmpd.conf and ipsec.conf in the same format so I can compare them? isakmpd does not interpret settings in ipsec.conf *at all*; ipsecctl converts them into control commands which generate isakmpd.conf sections. to compare, you'll need to adjust the format manually; ipsecctl -nvf outputs a bunch of lines like this: C set [sectionname]:variable1=setting1 C set [sectionname]:variable2=setting2 C set [sectionname]:variable3=setting3 which equate to isakmpd.conf entries like this: [sectionname] variable1=setting1 variable2=setting2 variable3=setting3
Re: Trouble getting ipsec.conf 'tag' working in 5.3
A kind soul (thank you) suggested I add the following to my ruleset: pass quick on enc0 proto ipencap Unfortunately, that does still not allow the inner outbound traffic to pass. From what I can tell, the original ruleset already let ipencap traffic pass on enc0. I verified with tcpdump and by separately logging the pass rules. Had ipencap been the problem, tcpdump on pflog1 would show a match on rule #11 (instead of the 'tagged PBX' rule #12). Pinging or UDP traffic to the 172.24.8.0/24 subnet fails, whereas incoming traffic from the other side is matched to the 'tagged PBX' rule (#12). I've made sure the tagging in #14 does not occur for traffic to the PBX (I added its net to the internal table. I expected ipsec to automagically add the 'PBX' tag to traffic it gets handed (in this case, from $if_int) when that traffic fits its SAs. I further expected pf to need no more than a simple 'pass on enc0 tagged PBX' after that. If I was too optimistic or misunderstood ipsec.conf(5), a cluebat is more than welcome. If this is something that should work, I'll try with -current as well. Regards, Rogier # tcpdump -ni pflog0 -s1600 -eee -ttt -v Jun 11 13:36:47.049079 rule 0/(match) [uid 0, pid 17691] block out on enc0: 192.168.10.101.63617 172.24.8.56.5060: [udp sum ok] udp 593 (ttl 63, id 40730, len 621, bad cksum 5a08!) Jun 11 13:40:03.515813 rule 0/(match) [uid 0, pid 17691] block out on enc0: 192.168.10.102 172.24.8.55: icmp: echo request (id:0001 seq:411) (ttl 127, id 23969, len 60, bad cksum 5dc2!) # tcpdump -ni pflog1 -s1600 -eee -ttt Jun 11 13:39:28.142858 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request (encap) Jun 11 13:39:28.142883 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request Jun 11 13:39:29.149843 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request (encap) Jun 11 13:39:29.149865 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request Jun 11 13:39:30.159693 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request (encap) Jun 11 13:39:30.159715 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request # pfctl -sr -vv | grep -e '^@' @0 block return log all @1 match out on egress inet all tagged OUT nat-to (egress:0:1) round-robin @2 pass out on egress from (egress:3) to any flags S/SA @3 pass out on egress proto udp from (egress:3) to any port = 3740 @4 pass out on egress inet6 from (vlan801:network:1) to any flags S/SA @5 pass on egress proto udp from any to any port = 500 @6 pass on egress proto udp from any to any port = 4500 @7 pass on egress proto ipv6 all @8 pass on egress inet proto icmp all @9 pass on egress inet6 proto ipv6-icmp all @10 pass on egress proto esp all @11 pass log (all, to pflog1) on enc0 proto ipencap all @12 pass log (all, to pflog1) on enc0 all flags S/SA keep state (if-bound) tagged PBX @13 pass in on vlan801 proto tcp from (vlan801:network:5) to (vlan801:9) port = 22 flags S/SA @14 match in on vlan801 from (vlan801:network:5) to ! internal:7 tag OUT @15 pass on vlan801 all flags S/SA
Re: Trouble getting ipsec.conf 'tag' working in 5.3
Tried to tag pkts on $int_if ? Eg match in on $if_int from ($if_int:network) to $pbx_net tag PBX //mxb On 11 jun 2013, at 14:38, Rogier Krieger rkrie...@gmail.com wrote: A kind soul (thank you) suggested I add the following to my ruleset: pass quick on enc0 proto ipencap Unfortunately, that does still not allow the inner outbound traffic to pass. From what I can tell, the original ruleset already let ipencap traffic pass on enc0. I verified with tcpdump and by separately logging the pass rules. Had ipencap been the problem, tcpdump on pflog1 would show a match on rule #11 (instead of the 'tagged PBX' rule #12). Pinging or UDP traffic to the 172.24.8.0/24 subnet fails, whereas incoming traffic from the other side is matched to the 'tagged PBX' rule (#12). I've made sure the tagging in #14 does not occur for traffic to the PBX (I added its net to the internal table. I expected ipsec to automagically add the 'PBX' tag to traffic it gets handed (in this case, from $if_int) when that traffic fits its SAs. I further expected pf to need no more than a simple 'pass on enc0 tagged PBX' after that. If I was too optimistic or misunderstood ipsec.conf(5), a cluebat is more than welcome. If this is something that should work, I'll try with -current as well. Regards, Rogier # tcpdump -ni pflog0 -s1600 -eee -ttt -v Jun 11 13:36:47.049079 rule 0/(match) [uid 0, pid 17691] block out on enc0: 192.168.10.101.63617 172.24.8.56.5060: [udp sum ok] udp 593 (ttl 63, id 40730, len 621, bad cksum 5a08!) Jun 11 13:40:03.515813 rule 0/(match) [uid 0, pid 17691] block out on enc0: 192.168.10.102 172.24.8.55: icmp: echo request (id:0001 seq:411) (ttl 127, id 23969, len 60, bad cksum 5dc2!) # tcpdump -ni pflog1 -s1600 -eee -ttt Jun 11 13:39:28.142858 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request (encap) Jun 11 13:39:28.142883 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request Jun 11 13:39:29.149843 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request (encap) Jun 11 13:39:29.149865 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request Jun 11 13:39:30.159693 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request (encap) Jun 11 13:39:30.159715 rule 12/(match) pass in on enc0: 172.24.8.1 192.168.10.102: icmp: echo request # pfctl -sr -vv | grep -e '^@' @0 block return log all @1 match out on egress inet all tagged OUT nat-to (egress:0:1) round-robin @2 pass out on egress from (egress:3) to any flags S/SA @3 pass out on egress proto udp from (egress:3) to any port = 3740 @4 pass out on egress inet6 from (vlan801:network:1) to any flags S/SA @5 pass on egress proto udp from any to any port = 500 @6 pass on egress proto udp from any to any port = 4500 @7 pass on egress proto ipv6 all @8 pass on egress inet proto icmp all @9 pass on egress inet6 proto ipv6-icmp all @10 pass on egress proto esp all @11 pass log (all, to pflog1) on enc0 proto ipencap all @12 pass log (all, to pflog1) on enc0 all flags S/SA keep state (if-bound) tagged PBX @13 pass in on vlan801 proto tcp from (vlan801:network:5) to (vlan801:9) port = 22 flags S/SA @14 match in on vlan801 from (vlan801:network:5) to ! internal:7 tag OUT @15 pass on vlan801 all flags S/SA
Re: Trouble getting ipsec.conf 'tag' working in 5.3
On Tue, Jun 11, 2013 at 3:26 PM, mxb m...@alumni.chalmers.se wrote: Tried to tag pkts on $int_if ? Eg match in on $if_int from ($if_int:network) to $pbx_net tag PBX Yes and that works. But shouldn't it already be covered by the 'PBX' tag in ipsec.conf? That's what I expected and what I'm trying to figure out. Thanks for the suggestion, though. Regards, Rogier
Re: Trouble getting ipsec.conf 'tag' working in 5.3
From ipsec.conf(5): … Add a pf(4) tag to all packets of phase 2 SAs created for this connection. … As I understand it, in your case or any other cases, it is about tagging pkts from one peer to another. Eg. from one vpn_gw to another. But this is my understanding of this. I might be wrong here. On 11 jun 2013, at 15:37, Rogier Krieger rkrie...@gmail.com wrote: On Tue, Jun 11, 2013 at 3:26 PM, mxb m...@alumni.chalmers.se wrote: Tried to tag pkts on $int_if ? Eg match in on $if_int from ($if_int:network) to $pbx_net tag PBX Yes and that works. But shouldn't it already be covered by the 'PBX' tag in ipsec.conf? That's what I expected and what I'm trying to figure out. Thanks for the suggestion, though. Regards, Rogier
Trouble getting ipsec.conf 'tag' working in 5.3
Dear list,
after re-installing a machine with 5.3 (i386), I wanted to tighten up the
filtering rules. To that end, I added a 'block log' rule near the top of my
rules. This appears to be unexpectedly effective.
I'm having trouble with my IPsec VPN to a VoIP PBX. Although my SAs come up
as expected, outbound traffic appears to be blocked on enc0. What bugs me
is that the 'tag' and 'tagged' keywords do not seem to work as I'd expect
from ipsec.conf(5).
I created the SAs with the 'PBX' tag and would like to be so lazy as to
just use:
pass on enc keep state (if-bound) tagged PBX
Surprisingly, I can receive incoming pings from the PBX (172.24.8.0/24)
with this setup, but am unable to ping the address from my own net (
192.128.10.0/24). I get this with the fairly minimal ruleset added below.
Of course, I could add rules listing the address ranges in question, but I
had hoped to use the 'PBX' tag for that instead. Did I misread or
misunderstand ipsec.conf(5) or am I missing something else entirely?
Insight greatly appreciated,
Regards,
Rogier
# tcpdump -eee -ttt -ni pflog0
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Jun 10 22:42:39.513643 rule 0/(match) block out on enc0: 192.168.10.102
172.24.8.1: icmp: echo request
# cat /etc/pf.conf
if_int=vlan801
pbx_net=172.24.8.0/24
noc_net=172.24.10.0/24
table internal persist { $if_int:network, $pbx_net, $noc_net }
set block-policy return
block log
set skip on { lo sk0 }
# Outbound traffic
match out on egress inet nat-to (egress:0) tagged OUT
pass out on egress from (egress)
# IPv6 tunnel
pass out on egress proto tcp from (egress) to any port 3874 # TIC
pass out on egress proto udp from (egress) to any port 3740 # heartbeat
pass on egress proto ipv6
pass on egress inet proto icmp
pass on egress inet6 proto icmp6
# IPsec tunnel
pass on egress proto udp from any to any port { isakmp, ipsec-nat-t }
pass on egress proto esp
pass on enc0 keep state (if-bound) tagged PBX
# SSH
pass in on $if_int proto tcp from ($if_int:network) to ($if_int) \
port ssh
# Internal traffic
match in on $if_int from ($if_int:network) to !internal tag OUT
pass on $if_int
# cat /etc/ipsec.conf
id = b2
gw = fxp0
gw6 = gif6
net = 192.168.10.0/24
# PBX access
pbx_id = weber
pbx_gw = [removed]
pbx_net = 172.24.8.0/24
ike esp from $net to $pbx_net peer $pbx_gw srcid $id dstid $pbx_id tag PBX
# cat /var/run/dmesg.boot
OpenBSD 5.3 (GENERIC) #50: Tue Mar 12 18:35:23 MDT 2013
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) CPU 2.40GHz (GenuineIntel 686-class) 2.40 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,CNXT-ID,xTPR,PERF
real mem = 1071374336 (1021MB)
avail mem = 1042882560 (994MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 01/22/04, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.3 @ 0xfbe60 (76 entries)
bios0: vendor Intel Corp. version BF86510A.86A.0053.P13.0401220953 date
01/22/2004
bios0: Intel Corporation D865GBF
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC ASF! TCPA WDDT
acpi0: wakeup devices TANA(S4) P0P3(S4) AC97(S4) USB0(S4) USB1(S4) USB2(S4)
USB3(S4) USB7(S4) UAR1(S4) SLPB(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 99MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P1)
acpiprt2 at acpi0: bus -1 (P0P2)
acpiprt3 at acpi0: bus 1 (P0P3)
acpicpu0 at acpi0
acpipwrres0 at acpi0: URP1
acpipwrres1 at acpi0: FDDP
acpipwrres2 at acpi0: LPTP
acpibtn0 at acpi0: SLPB
bios0: ROM list: 0xc/0xa200! 0xca800/0x800 0xcb000/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82865G Host rev 0x02
vga1 at pci0 dev 2 function 0 Intel 82865G Video rev 0x02
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xf000, size 0x800
inteldrm0 at vga1: apic 1 int 16
drm0 at inteldrm0
uhci0 at pci0 dev 29 function 0 Intel 82801EB/ER USB rev 0x02: apic 1 int
16
uhci1 at pci0 dev 29 function 1 Intel 82801EB/ER USB rev 0x02: apic 1 int
19
uhci2 at pci0 dev 29 function 2 Intel 82801EB/ER USB rev 0x02: apic 1 int
18
uhci3 at pci0 dev 29 function 3 Intel 82801EB/ER USB rev 0x02: apic 1 int
16
ehci0 at pci0 dev 29 function 7 Intel 82801EB/ER USB2 rev 0x02: apic 1
int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb0 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xc2
pci1 at ppb0 bus 1
skc0 at pci1 dev 0 function 0 3Com 3c940 rev 0x10, Yukon (0x1): apic 1
int 21
sk0 at skc0 port A: address 00:0a:5e:54:48:99
eephy0 at sk0 phy 0: 88E1011 Gigabit
Possible to use UFQDN for peer in ipsec.conf?
Hello, I'm trying to do roadwarrior VPN between OSX (mobile) and OpenBSD (gateway) using certificates for peer identification. Is it possible to list a UFQDN as a peer? When I try something like this on the gateway: ike passive from any to any peer u...@host.tld \ main auth hmac-sha1 enc aes group modp2048 \ quick auth hmac-sha2-256 enc blowfish \ psk super secret string ipsecctl complains of a syntax error. If anyone has a link to an ipsec.conf that has an example of using UFQDNs to identify peers I would be eternally grateful. It seems nearly every example just uses PSK alone, or if a certificate is used it's by hostname. PS If I place the trusted certificates in /etc/isakmp/pubkeys/ufqdn do they absolutely have to have subjectAlternateName, or is having the email address in the CN sufficient (CN=u...@host.tld/emailAddress=u...@host.tld)? Any tips are immensely appreciated. -- chort
Defining two vpn's in ipsec.conf wich different crypto
hi, I've setup a roadwarrior ipsec/l2tp (undeadly guide) that worked fine until I made some new rules in ipsec.conf in order to get a vpn-connection to a FreeBSD machine to work. My ipsec.conf looks like this. When connecting from a roadwarrior ip I still goes to the crypto that it supposed to be for the obsd-fbsd connection.Is it possible two have two different crypto definitions like this? # cat /etc/ipsec.conf# macros#ext_if = em0local_net = 10.11.12.0/24remote_gw = 85.23.19.11remote_nets = 192.168.1.0/24 #win7 android etc.ike passive esp transport \proto udp from 98.10.x.x to any port 1701 \main auth hmac-sha1 enc 3des group modp2048 \ quick auth hmac-sha1 enc aes \psk lamas #obsd-freebsdike esp from $local_net to $remote_nets peer $remote_gw \ main auth hmac-sha1 enc aes-256 group modp2048 \quick auth hmac-sha2-256 enc aes-256 group modp2048 best regards
Re: ipsec.conf ,routers and endpoints - third try
firewall dual homed network facing static nic address = 5.5.5.4 (rfc1918/rfc6598) virgin media router facing static nic address = 3.3.3.2 (rfc1918/rfc6598) virgin media router static address = 3.3.3.3 (rfc1918/rfc6598) virgin media dynamic wan address = 1.1.1.1 (internet-routable) firewall default route = 3.3.3.3 network_a default route = 5.5.5.4 your local_gw address would be the router-facing rfc1918 address and remote_gw would be the dynamic internet-routable address of the other gateway. hi stuart thanks for your answer and advice, i am working on a modified ddns update script to signal a restart of isakmpd when the dynamic ip changes, will implement isakmpd else will follow your suggestion and use openvpn for my net to net link, i had already planned to use openvpn for my roadwarriors. shadrock The problem is that when the address of one side changes, it's the *other* side that yo uneed to restart. so you might want a regularly-run script to do a lookup to work out when this needs doing, although in practice I don't think VM change addresses all that often so it might be good enough to have the update script email/text you to tell you to update the other side... hi stuart having reread your first post on the subject, i now realize when the address of one side changes it's the*other* side that needs to update remote_gw in ipsec.conf and restart. i was considering each end running a script which used ping to check connectivity to the remote gateway like openvpn's method, if ping timed out then a dns hostname lookup would be used to resolve the ip, ipsec.conf would then be updated and restarted and an email sent to the manager of the network informing of the remote address change. this would be all scripted so there would be no need for me to get involved. shadrock
Re: ipsec.conf ,routers and endpoints - third try
On 2012-05-08, shadrock shadr...@ntlworld.com wrote: hi stuart thanks for your answer and advice, i am working on a modified ddns update script to signal a restart of isakmpd when the dynamic ip changes, will implement isakmpd else will follow your suggestion and use openvpn for my net to net link, i had already planned to use openvpn for my roadwarriors. shadrock The problem is that when the address of one side changes, it's the *other* side that you need to restart. so you might want a regularly-run script to do a lookup to work out when this needs doing, although in practice I don't think VM change addresses all that often so it might be good enough to have the update script email/text you to tell you to update the other side... (there is a 'static IP' option on VM business services but afaict they are just about as likely to change addresses on you as the standard service, just that they try and tell you about it beforehand).
Re: ipsec.conf ,routers and endpoints - third try
hi stuart thanks for your answer and advice, i am working on a modified ddns update script to signal a restart of isakmpd when the dynamic ip changes, will implement isakmpd else will follow your suggestion and use openvpn for my net to net link, i had already planned to use openvpn for my roadwarriors. shadrock
Re: ipsec.conf ,routers and endpoints - third try
On 2012-05-04, shadrock shadr...@ntlworld.com wrote: firewall dual homed network facing static nic address = 5.5.5.4 (rfc1918/rfc6598) virgin media router facing static nic address = 3.3.3.2 (rfc1918/rfc6598) virgin media router static address = 3.3.3.3 (rfc1918/rfc6598) virgin media dynamic wan address = 1.1.1.1 (internet-routable) firewall default route = 3.3.3.3 network_a default route = 5.5.5.4 So you have no static routable address on either side. This isn't going to work well with isakmpd, you really need a static address on at least one side to use it. DNS lookups are only done when the config is loaded so there's no way to automatically track changed addresses in isakmpd. If you can live with restarting things when the address changes then your local_gw address would be the router-facing rfc1918 address and remote_gw would be the dynamic internet-routable address of the other gateway. OpenVPN might be better in this situation, see the 'float' option and/or http://openvpn.net/index.php/open-source/faq/77-server/299-can-openvpn-handle-the-situation-where-both-ends-of-the-connection-are-dynamic.html
ipsec.conf ,routers and endpoints - third try
my apologies for my first post network topology home network remote network 3.3.3.3 1.1.1.12.2.2.2 4.4.4.4 -- router_a internet router_b - | | | | | | | | | 3.3.3.2 4.4.4.2| firewall_a firewall_b | 5.5.5.4 7.7.7.4| | | | | | | network_a network_b 5.5.5.0/24 7.7.7.0/24 --- network_a home network = 5.5.5.0/24 firewall dual homed network facing static nic address = 5.5.5.4 (rfc1918/rfc6598) virgin media router facing static nic address = 3.3.3.2 (rfc1918/rfc6598) virgin media router static address = 3.3.3.3 (rfc1918/rfc6598) virgin media dynamic wan address = 1.1.1.1 (internet-routable) firewall default route = 3.3.3.3 network_a default route = 5.5.5.4 network_b home network = 7.7.7.0/24 firewall dual homed network facing static nic address = 7.7.7.4 (rfc1918/rfc6598) virgin media router facing static nic address = 4.4.4.2 (rfc1918/rfc6598) virgin media router static address = 4.4.4.4 (rfc1918/rfc6598) virgin media dynamic wan address = 2.2.2.2(internet-routable) firewall default route = 4.4.4.4 network_a default route = 7.7.7.4 both firewalls run ipsec both firewalls run NAT both will have ddns for the internet-routable address both routers configured for vpn passthrough network_a connects to firewall_a via a switch firewall_a connects to router_a via a switch router_a connects to virgin media cable -- network_a ipsec.conf # Macros local_gw= local_addr # External interface local_net = 5.5.5.0/24 # Local private network remote_gw = remote_addr # Remote IPsec gateway remote_nets = 7.7.7.0/24 # Remote private networks # Set up the VPN between the gateway machines ike esp from $local_gw to $remote_gw # Between local gateway and remote networks ike esp from $local_gw to $remote_nets peer $remote_gw # Between the networks ike esp from $local_net to $remote_nets peer $remote_gw --- Q1: for my local_gw is local_addr 3.3.3.2 or 3.3.3.3 or 1.1.1.1 Q2: for my remote_gw is remote_addr 2.2.2.2 or 4.4.4.4 or 4.4.4.2
Re: ipsec.conf ,routers and endpoints
this is pretty much unreadable, use a reliable mail client if you're posting ascii-art and keep it to 75 columns or so. also your obfuscated IP addresses make it impossible to tell which addresses are real internet-routable addresses and which if any are rfc1918/rfc6598, and whether there's any NAT in place or not. On 2012-05-03, powell murlene shadr...@ntlworld.com wrote: network topology home network remote network ## 3.3.3.3 1.1.1.1# # 2.2.2.2 4.4.4.4 router_a --# internet #--- router_b --- |# #| | | 3.3.3.2 4.4.4.2 | | firewall_a firewall_b | | 5.5.5.4 7.7.7.4 | | | | network_a network_b 5.5.5.0/24 7.7.7.0/24 --- network_a home network = 5.5.5.0/24 firewall dual homed network facing static nic address = 5.5.5.4 virgin media router facing static nic address = 3.3.3.2 virgin media router static address = 3.3.3.3 virgin media dynamic wan address = 1.1.1.1 network_b remote network = 7.7.7.0/24 firewall dual homed network facing static nic address = 7.7.7.4 virgin media router facing static nic address = 4.4.4.2 virgin media router static address = 4.4.4.4 virgin media dynamic wan address = 2.2.2.2 both firewalls run ipsec both routers configured foe vpn passthrough -- network_a ipsec.conf # Macros local_gw= local_addr# External interface local_net = 5.5.5.0/24 # Local private network remote_gw = remote_addr # Remote IPsec gateway remote_nets = 7.7.7.0/24# Remote private networks # Set up the VPN between the gateway machines ike esp from $local_gw to $remote_gw # Between local gateway and remote networks ike esp from $local_gw to $remote_nets peer $remote_gw # Between the networks ike esp from $local_net to $remote_nets peer $remote_gw --- Q1: for my local_gw is local_addr 3.3.3.2 or 3.3.3.3 or 1.1.1.1 Q2: for my remote_gw is remote_addr 2.2.2.2 or 4.4.4.4 or 4.4.4.2
ipsec.conf ,routers and endpoints -- corrected
my apologies for my first post network topology home network remote network 3.3.3.3 1.1.1.1 2.2.2.2 4.4.4.4 -- router_a internet router_b - | | | | | | | | | 3.3.3.2 4.4.4.2 | firewall_a firewall_b | 5.5.5.4 7.7.7.4 | | | | | | | network_a network_b 5.5.5.0/24 7.7.7.0/24 --- network_a home network = 5.5.5.0/24 firewall dual homed network facing static nic address = 5.5.5.4 (rfc1918/rfc6598) virgin media router facing static nic address = 3.3.3.2 (rfc1918/rfc6598) virgin media router static address = 3.3.3.3 (rfc1918/rfc6598) virgin media dynamic wan address = 1.1.1.1 (internet-routable) firewall default route = 3.3.3.3 network_a default route = 5.5.5.4 network_b home network = 7.7.7.0/24 firewall dual homed network facing static nic address = 7.7.7.4 (rfc1918/rfc6598) virgin media router facing static nic address = 4.4.4.2 (rfc1918/rfc6598) virgin media router static address = 4.4.4.4 (rfc1918/rfc6598) virgin media dynamic wan address = 2.2.2.2(internet-routable) firewall default route = 4.4.4.4 network_a default route = 7.7.7.4 both firewalls run ipsec both firewalls run NAT both will have ddns for the internet-routable address both routers configured for vpn passthrough network_a connects to firewall_a via a switch firewall_a connects to router_a via a switch router_a connects to virgin media cable -- network_a ipsec.conf # Macros local_gw= local_addr# External interface local_net = 5.5.5.0/24 # Local private network remote_gw = remote_addr # Remote IPsec gateway remote_nets = 7.7.7.0/24 # Remote private networks # Set up the VPN between the gateway machines ike esp from $local_gw to $remote_gw # Between local gateway and remote networks ike esp from $local_gw to $remote_nets peer $remote_gw # Between the networks ike esp from $local_net to $remote_nets peer $remote_gw --- Q1: for my local_gw is local_addr 3.3.3.2 or 3.3.3.3 or 1.1.1.1 Q2: for my remote_gw is remote_addr 2.2.2.2 or 4.4.4.4 or 4.4.4.2
ipsec.conf ,routers and endpoints
network topology home network remote network ## 3.3.3.3 1.1.1.1# # 2.2.2.2 4.4.4.4 router_a --# internet #--- router_b --- |# #| | | 3.3.3.2 4.4.4.2 | | firewall_a firewall_b | | 5.5.5.4 7.7.7.4 | | | | network_a network_b 5.5.5.0/24 7.7.7.0/24 --- network_a home network = 5.5.5.0/24 firewall dual homed network facing static nic address = 5.5.5.4 virgin media router facing static nic address = 3.3.3.2 virgin media router static address = 3.3.3.3 virgin media dynamic wan address = 1.1.1.1 network_b remote network = 7.7.7.0/24 firewall dual homed network facing static nic address = 7.7.7.4 virgin media router facing static nic address = 4.4.4.2 virgin media router static address = 4.4.4.4 virgin media dynamic wan address = 2.2.2.2 both firewalls run ipsec both routers configured foe vpn passthrough -- network_a ipsec.conf # Macros local_gw= local_addr # External interface local_net = 5.5.5.0/24 # Local private network remote_gw = remote_addr # Remote IPsec gateway remote_nets = 7.7.7.0/24 # Remote private networks # Set up the VPN between the gateway machines ike esp from $local_gw to $remote_gw # Between local gateway and remote networks ike esp from $local_gw to $remote_nets peer $remote_gw # Between the networks ike esp from $local_net to $remote_nets peer $remote_gw --- Q1: for my local_gw is local_addr 3.3.3.2 or 3.3.3.3 or 1.1.1.1 Q2: for my remote_gw is remote_addr 2.2.2.2 or 4.4.4.4 or 4.4.4.2
V5.0 - ipsec -- lifetime dependencies between ipsec.conf (ipsecctl) and isakmpd.conf
Hello @misc, I'm lost in the documentation of isakmpd.conf and ipsec.conf :-( Situation: I have to set up several ipsec-connections on one system on my side (OBSD 5) to different sites with different VPN-hardware. All external sites offer only PSKs in configuration, no certificates. Problem: most of the sites use different key lifetimes (in phase 1/2), so I have do deal with a bunch of lifetime values. Question: is there any chance (perhaps in the future) to integrate lifetime parameters via ipsecctl -- ipsec.conf or will I be forced to keep on using isakmpd.conf? I don't need isakmpd.conf for other parameters ;-) best regards Andre Ruppert
Re: V5.0 - ipsec -- lifetime dependencies between ipsec.conf (ipsecctl) and isakmpd.conf
Andre Ruppert a...@in-telegence.net wrote: is there any chance (perhaps in the future) to integrate lifetime parameters via ipsecctl -- ipsec.conf or will I be forced to keep on using isakmpd.conf? There is lifetime code in ipsecctl. I don't know if its absence from the man page is an accidental omission or if the code is incomplete. -- Christian naddy Weisgerber na...@mips.inka.de
Re: V5.0 - ipsec -- lifetime dependencies between ipsec.conf (ipsecctl) and isakmpd.conf
On 2012-04-11, Christian Weisgerber na...@mips.inka.de wrote: Andre Ruppert a...@in-telegence.net wrote: is there any chance (perhaps in the future) to integrate lifetime parameters via ipsecctl -- ipsec.conf or will I be forced to keep on using isakmpd.conf? There is lifetime code in ipsecctl. I don't know if its absence from the man page is an accidental omission or if the code is incomplete. IIRC, it looks like it should work per-peer but can actually only be used to set lifetimes for the default peer. Examination of the output from ipsecctl -nvf /etc/ipsec.conf would confirm this.
Re: Manual IPsec setup with ipsec.conf
On Thu, Apr 05, 2012 at 05:53:27AM +0530, Girish Venkatachalam wrote: Dear all, Such a silly thing is not documented anywhere, no vpn(8) man page and not on the Internet. Subject: Manual IPsec setup with ipsec.conf have you looked at the manual page for ipsec.conf? jmc
Re: Manual IPsec setup with ipsec.conf
On Thu, Apr 5, 2012 at 11:37 AM, Jason McIntyre j...@kerhand.co.uk wrote: On Thu, Apr 05, 2012 at 05:53:27AM +0530, Girish Venkatachalam wrote: Dear all, Such a silly thing is not documented anywhere, no vpn(8) man page and not on the Internet. Subject: Manual IPsec setup with ipsec.conf have you looked at the manual page for ipsec.conf? jmc Sorry I did not mean to antagonize. I did read the section. But an example would be a great addition. -Girish -- G3 Tech Networking appliance company web: http://g3tech.in mail: gir...@g3tech.in
Re: Manual IPsec setup with ipsec.conf
On Thu, Apr 05, 2012 at 03:07:17PM +0530, Girish Venkatachalam wrote: On Thu, Apr 5, 2012 at 11:37 AM, Jason McIntyre j...@kerhand.co.uk wrote: On Thu, Apr 05, 2012 at 05:53:27AM +0530, Girish Venkatachalam wrote: Dear all, Such a silly thing is not documented anywhere, no vpn(8) man page and not on the Internet. Subject: Manual IPsec setup with ipsec.conf have you looked at the manual page for ipsec.conf? jmc Sorry I did not mean to antagonize. I did read the section. But an example would be a great addition. well, there are examples of both setting up flows manually and setting up SAs manually. it maybe doesn;t cover what you are trying to do though. jmc
Re: Manual IPsec setup with ipsec.conf
On Thu, Apr 05, 2012 at 03:07:17PM +0530, Girish Venkatachalam wrote: On Thu, Apr 5, 2012 at 11:37 AM, Jason McIntyre j...@kerhand.co.uk wrote: On Thu, Apr 05, 2012 at 05:53:27AM +0530, Girish Venkatachalam wrote: Dear all, Such a silly thing is not documented anywhere, no vpn(8) man page and not on the Internet. Subject: Manual IPsec setup with ipsec.conf have you looked at the manual page for ipsec.conf? jmc Sorry I did not mean to antagonize. I did read the section. But an example would be a great addition. Interesting, hasn't been somewhere posted that asking person is guru and reviewd OpenBSD IPSEC's code? :) jirib
Re: Manual IPsec setup with ipsec.conf
- Original Message - From: Girish Venkatachalam girishvenkatacha...@gmail.com To: OpenBSD general usage list misc@openbsd.org Sent: Wednesday, April 4, 2012 8:23:27 PM Subject: Manual IPsec setup with ipsec.conf Dear all, Such a silly thing is not documented anywhere, no vpn(8) man page and not on the Internet. I am forced to send this mail though it is embarrassing having worked on the internals of manual IPsec keying back in 2004. But well here goes. on peer A: remoteip=173.167.82.52 remotenet=10.1.23.0/24 flow esp from 59.99.242.167 to $remoteip flow esp from 192.168.1.0/24 to $remotenet peer $remoteip esp from 59.99.242.167 to $remoteip spi 0xdeadbeef:0xbeefdead auth hmac-sha1 \ authkey 0xeda8f06463b2d0fed008ccc474216dba8c463a7c:0x91c763de940ce1745215c84b7 535269acaef516d \ enckey 0xb341aa065c3850edd6a61e150d6a5fd3:0xf7795f6bdd697a43a4d28dcf1b79062d on peer B: localnet=192.168.0.0/16 remoteip=59.99.242.167 flow esp from 173.167.82.52 to 59.99.242.167 flow esp from 10.1.23.0/24 to 192.168.1.0/24 peer $remoteip esp from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead:0xdeadbeef auth hmac-sha1 \ authkey 0x91c763de940ce1745215c84b7535269acaef516d:0xeda8f06463b2d0fed008ccc47 4216dba8c463a7c \ enckey 0xf7795f6bdd697a43a4d28dcf1b79062d:0xb341aa065c3850edd6a61e150d6a5fd3 It is a test. I don't care about the keys and IP addresses. pf(4) is disabled both sides and here is the output of #ipsecctl -sa on peer B # ipsecctl -sa -v FLOWS: flow esp in from 192.168.1.0/24 to 10.1.23.0/24 peer 59.99.242.167 type require flow esp out from 10.1.23.0/24 to 192.168.1.0/24 peer 59.99.242.167 type require flow esp in from 59.99.242.167 to 173.167.82.52 peer 59.99.242.167 type require flow esp out from 173.167.82.52 to 59.99.242.167 peer 59.99.242.167 type require SAD: esp tunnel from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead auth hmac-sha1 enc aes sa: spi 0xbeefdead auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 0 add 1333585323 first 0 address_src: 173.167.82.52 address_dst: 59.99.242.167 esp tunnel from 59.99.242.167 to 173.167.82.52 spi 0xdeadbeef auth hmac-sha1 enc aes sa: spi 0xdeadbeef auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 0 add 1333585323 first 0 address_src: 59.99.242.167 address_dst: 173.167.82.52 And peer A: # ipsecctl -sa -v FLOWS: flow esp in from 10.1.23.0/24 to 192.168.1.0/24 peer 173.167.82.52 type require flow esp out from 192.168.1.0/24 to 10.1.23.0/24 peer 173.167.82.52 type require flow esp in from 173.167.82.52 to 59.99.242.167 peer 173.167.82.52 type require flow esp out from 59.99.242.167 to 173.167.82.52 peer 173.167.82.52 type require SAD: esp tunnel from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead auth hmac-sha1 enc aes sa: spi 0xbeefdead auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 0 add 1333585275 first 0 address_src: 173.167.82.52 address_dst: 59.99.242.167 esp tunnel from 59.99.242.167 to 173.167.82.52 spi 0xdeadbeef auth hmac-sha1 enc aes sa: spi 0xdeadbeef auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 196 add 1333585275 first 1333585277 address_src: 59.99.242.167 address_dst: 173.167.82.52 lifetime_lastuse: alloc 0 bytes 0 add 0 first 1333585277 I cannot ping between 192.168.1.50 and 10.1.23.2 What is going on? -Girish -- G3 Tech Networking appliance company web: http://g3tech.in mail: gir...@g3tech.in two very basic questions, both of which have bitten me at some point: 1) is ip forwarding enabled on both boxes? 2) do you have the appropriate routes setup on both sides?
Re: Manual IPsec setup with ipsec.conf
On 04/04/2012 08:23 PM, Girish Venkatachalam wrote: # ipsecctl -sa -v FLOWS: flow esp in from 10.1.23.0/24 to 192.168.1.0/24 peer 173.167.82.52 type require flow esp out from 192.168.1.0/24 to 10.1.23.0/24 peer 173.167.82.52 type require flow esp in from 173.167.82.52 to 59.99.242.167 peer 173.167.82.52 type require flow esp out from 59.99.242.167 to 173.167.82.52 peer 173.167.82.52 type require SAD: esp tunnel from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead auth hmac-sha1 enc aes sa: spi 0xbeefdead auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 0 add 1333585275 first 0 address_src: 173.167.82.52 address_dst: 59.99.242.167 esp tunnel from 59.99.242.167 to 173.167.82.52 spi 0xdeadbeef auth hmac-sha1 enc aes sa: spi 0xdeadbeef auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 196 add 1333585275 first 1333585277 address_src: 59.99.242.167 address_dst: 173.167.82.52 lifetime_lastuse: alloc 0 bytes 0 add 0 first 1333585277 I cannot ping between 192.168.1.50 and 10.1.23.2 Possibly just a routing issue (since the tunnels seem to be established). See this thread: http://comments.gmane.org/gmane.os.openbsd.misc/192986 It's kind of counter intuitive to have to specify a separate route for a tunnel, since it is adding no real information for the system to use, but it looks like it's a peculiarity of the current implementation. - Aner
Manual IPsec setup with ipsec.conf
Dear all, Such a silly thing is not documented anywhere, no vpn(8) man page and not on the Internet. I am forced to send this mail though it is embarrassing having worked on the internals of manual IPsec keying back in 2004. But well here goes. on peer A: remoteip=173.167.82.52 remotenet=10.1.23.0/24 flow esp from 59.99.242.167 to $remoteip flow esp from 192.168.1.0/24 to $remotenet peer $remoteip esp from 59.99.242.167 to $remoteip spi 0xdeadbeef:0xbeefdead auth hmac-sha1 \ authkey 0xeda8f06463b2d0fed008ccc474216dba8c463a7c:0x91c763de940ce1745215c84b7 535269acaef516d \ enckey 0xb341aa065c3850edd6a61e150d6a5fd3:0xf7795f6bdd697a43a4d28dcf1b79062d on peer B: localnet=192.168.0.0/16 remoteip=59.99.242.167 flow esp from 173.167.82.52 to 59.99.242.167 flow esp from 10.1.23.0/24 to 192.168.1.0/24 peer $remoteip esp from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead:0xdeadbeef auth hmac-sha1 \ authkey 0x91c763de940ce1745215c84b7535269acaef516d:0xeda8f06463b2d0fed008ccc47 4216dba8c463a7c \ enckey 0xf7795f6bdd697a43a4d28dcf1b79062d:0xb341aa065c3850edd6a61e150d6a5fd3 It is a test. I don't care about the keys and IP addresses. pf(4) is disabled both sides and here is the output of #ipsecctl -sa on peer B # ipsecctl -sa -v FLOWS: flow esp in from 192.168.1.0/24 to 10.1.23.0/24 peer 59.99.242.167 type require flow esp out from 10.1.23.0/24 to 192.168.1.0/24 peer 59.99.242.167 type require flow esp in from 59.99.242.167 to 173.167.82.52 peer 59.99.242.167 type require flow esp out from 173.167.82.52 to 59.99.242.167 peer 59.99.242.167 type require SAD: esp tunnel from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead auth hmac-sha1 enc aes sa: spi 0xbeefdead auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 0 add 1333585323 first 0 address_src: 173.167.82.52 address_dst: 59.99.242.167 esp tunnel from 59.99.242.167 to 173.167.82.52 spi 0xdeadbeef auth hmac-sha1 enc aes sa: spi 0xdeadbeef auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 0 add 1333585323 first 0 address_src: 59.99.242.167 address_dst: 173.167.82.52 And peer A: # ipsecctl -sa -v FLOWS: flow esp in from 10.1.23.0/24 to 192.168.1.0/24 peer 173.167.82.52 type require flow esp out from 192.168.1.0/24 to 10.1.23.0/24 peer 173.167.82.52 type require flow esp in from 173.167.82.52 to 59.99.242.167 peer 173.167.82.52 type require flow esp out from 59.99.242.167 to 173.167.82.52 peer 173.167.82.52 type require SAD: esp tunnel from 173.167.82.52 to 59.99.242.167 spi 0xbeefdead auth hmac-sha1 enc aes sa: spi 0xbeefdead auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 0 add 1333585275 first 0 address_src: 173.167.82.52 address_dst: 59.99.242.167 esp tunnel from 59.99.242.167 to 173.167.82.52 spi 0xdeadbeef auth hmac-sha1 enc aes sa: spi 0xdeadbeef auth hmac-sha1 enc aes state mature replay 0 flags 4 lifetime_cur: alloc 0 bytes 196 add 1333585275 first 1333585277 address_src: 59.99.242.167 address_dst: 173.167.82.52 lifetime_lastuse: alloc 0 bytes 0 add 0 first 1333585277 I cannot ping between 192.168.1.50 and 10.1.23.2 What is going on? -Girish -- G3 Tech Networking appliance company web: http://g3tech.in mail: gir...@g3tech.in
troubleshooting shrew vpn client with ipsec.conf
I am converting over to ipsec.conf from isakmpd.conf|policy. I have a default vpn configuration to allow people from their home pc to access. Under isakmpd.conf it works perfectly well. I can use any number of settings, including the desired aes-256 for both phase 1 and phase 2. My isakmpd.conf sections: [Phase 1] Default=ISAKMP-peer-default 61.62.63.64= ISAKMP-peer-default Passive-Connections=IPsec-default [ISAKMP-peer-default] Phase= 1 Transport= udp Local-address= 61.62.63.64 Configuration= AES-main-mode Authentication= redacted [IPsec-default] Phase= 2 ISAKMP-peer=ISAKMP-peer-default Configuration= Default-quick-mode Local-ID= Net-corp [Net-corp] ID-type=IPV4_ADDR_SUBNET Network=10.10.10.0 Netmask=255.255.255.0 [AES-main-mode] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= AES-SHA [Default-quick-mode] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-AES-SHA-PFS-SUITE I put the following into my ipsec.conf: ike dynamic from any to 10.10.10.0/24 \ main auth hmac-sha1 enc aes group modp1024 \ quick auth hmac-sha1 enc aes \ psk redacted I've tried changing the settings to hmac-sha2-256 and aes-256, I've tried changing the client settings to everything from auto through 128, 192 256. Nothing seems to work. The debug when I try to connect does show phase 1 done, but later says it's been told to delete the session. See below. It does not seem to matter what settings I change in the vpn client config, I cannot get it to maintain this connection. What is the difference between the ipsec.conf and isakmpd.conf tunnels? What is telling isakmpd to delete this SA? 040442.728781 Exch 10 exchange_finalize: phase 1 done: initiator id 192.168.1.9, responder id fw.example.com, src: 61.62.63.64 dst: 43.100.100.77 040442.728808 Timr 10 timer_add_event: event sa_soft_expire(0x8b057000) added last, expiration in 74131s 040442.728819 SA 80 sa_reference: SA 0x8b057000 now has 5 references 040442.728838 Timr 10 timer_add_event: event sa_hard_expire(0x8b057000) added last, expiration in 86400s 040442.728849 SA 80 sa_reference: SA 0x8b057000 now has 6 references 040442.728861 SA 80 sa_release: SA 0x8b057000 had 6 references 040442.770769 Trpt 70 transport_setup: added 0x87a3c0c0 to transport list 040442.770808 Trpt 70 transport_setup: added 0x87a3c1c0 to transport list 040442.770821 Trpt 50 virtual_clone: old 0x89f49e40 new 0x87a3c2c0 (main is 0x87a3c0c0) 040442.770832 Trpt 70 transport_setup: virtual transport 0x87a3c2c0 040442.770846 Mesg 90 message_alloc: allocated 0x86887100 040442.770858 Mesg 70 message_recv: message 0x86887100 040442.770871 Mesg 70 ICOOKIE: 864ee9d5f19da22f 040442.770885 Mesg 70 RCOOKIE: db55da1a362c3ba3 040442.770896 Mesg 70 NEXT_PAYLOAD: HASH 040442.770909 Mesg 70 VERSION: 16 040442.770920 Mesg 70 EXCH_TYPE: INFO 040442.770931 Mesg 70 FLAGS: [ ENC ] 040442.770943 Mesg 70 MESSAGE_ID: f09ac655 040442.770954 Mesg 70 LENGTH: 92 040442.770978 Mesg 70 message_recv: 864ee9d5 f19da22f db55da1a 362c3ba3 08100501 f09ac655 005c 2cf32098 040442.771002 Mesg 70 message_recv: df99aee4 72eb2103 30579627 a79aac92 3029017f 53433540 0af8aaea 2e464200 040442.771024 Mesg 70 message_recv: fa2d9ad3 1b156485 b4bcf4f2 4befc80a 68c3a13d 07a57a34 cbbfe575 040442.771036 SA 80 sa_reference: SA 0x8b057000 now has 6 references 040442.771053 Cryp 60 hash_get: requested algorithm 1 040442.771063 Cryp 80 ipsec_get_keystate: final phase 1 IV: 040442.771079 Cryp 80 e1859bae f2a4943b 98d51085 c2d0d538 040442.771089 Cryp 80 ipsec_get_keystate: message ID: 040442.771100 Cryp 80 f09ac655 040442.771117 Cryp 50 crypto_init_iv: initialized IV: 040442.771134 Cryp 50 1019151c c500b0c4 eedeef0b 890f3dfd 040442.771144 Cryp 80 ipsec_get_keystate: phase 2 IV: 040442.771161 Cryp 80 1019151c c500b0c4 eedeef0b 890f3dfd 040442.771171 Cryp 70 crypto_decrypt: before decryption: 040442.771194 Cryp 70 2cf32098 df99aee4 72eb2103 30579627 a79aac92 3029017f 53433540 0af8aaea 040442.771217 Cryp 70 2e464200 fa2d9ad3 1b156485 b4bcf4f2 4befc80a 68c3a13d 07a57a34 cbbfe575 040442.771231 Cryp 70 crypto_decrypt: after decryption: 040442.771255 Cryp 70 0c18 9d93aa16 924a5147 05435224 1f50245c 6bb1cfe2 001c 0001 040442.771279 Cryp 70 0111 864ee9d5 f19da22f db55da1a 362c3ba3 040442.771291 Mesg 50 message_parse_payloads: offset 28 payload HASH 040442.771303 Mesg 50 message_parse_payloads: offset 52 payload DELETE 040442.771316 Mesg 60 message_validate_payloads: payload HASH at 0x8688779c of message 0x86887100 040442.771326 Mesg 70 DATA: 040442.771337 Cryp 60 hash_get: requested algorithm 1 040442.771347 Misc 90 message_validate_hash: SKEYID_a: 040442.771365 Misc 90 540cb39d 7776c123 4049eda1
Re: troubleshooting shrew vpn client with ipsec.conf
On 2011-12-15, nuffnough nuffno...@gmail.com wrote: ike dynamic from any to 10.10.10.0/24 \ try: ike passive esp from 10.10.10.0/24 to any
Re: troubleshooting shrew vpn client with ipsec.conf
ps. ipsecctl -nvf /etc/ipsec.conf
need help converting to ipsec.conf
Hi, I am converting a bunch of VPNs from my isakmpd.[conf|policy] files to ipsec.conf mostly because it seems they're deprecated, but partly because I saw an old thread that spoke of functionality I want to explore. I figured I should work through them one by one. I got my own VPN from one site to another working fine, after I figured out that ipsec.conf doesn't handle a space in the psk. The next one is site to site vpn from a client. They are using (I think) a juniper device to terminate with teh following settings: Client side: IP Address: 10.10.10.66 Peer: 10.100.1.66 Phase1 DH Group 1 Encryption: AES-256 Authentication: SHA1 Lifetime: 28800 seconds Phase2 DH Group 2 Encryption: AES-256 Authentication: SHA1 Lifetime: 3600 seconds Preshared Key: Changed PFS: enabled So. I put into my ipsec.conf: ike esp from 172.18.18.0/24 to 172.20.20.0/24 \ local 10.100.1.66 peer 10.10.10.66 \ #main auth hmac-md5 enc aes-256 group modp768 \ #main auth hmac-sha1 enc aes-256 group modp768 \ main auth hmac-sha1 enc aes group modp768 \ quick auth hmac-sha1 enc aes-256 group modp768 \ srcid ca...@fw0.example.com \ psk Changed Then I start up isakmpd and dump debug to a file and I get weird messages. # cat ipsec.log | grep unac 044235.728559 Default attribute_unacceptable: ENCRYPTION_ALGORITHM: got AES_CBC, expected 3DES_CBC 044255.325011 Default attribute_unacceptable: GROUP_DESCRIPTION: got MODP_768, expected MODP_1024 044315.878550 Default attribute_unacceptable: AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG 044315.878641 Default attribute_unacceptable: HASH_ALGORITHM: got MD5, expected SHA As soon as I switch back to my beloved isakmpd.conf (was its syntax really so complicated?) it comes back up instantly. Why is ipsec expecting 3DES_CBC? There is no reference to 3des in my config... Why is it expecting MODP_1024? Or RSA_SIG? Where is it getting MD5 from? Changing the hash to md5 doesn't seem to make any difference. :( And finally... Does ipsec.conf still parse the policy file to secure the connections? Is there a better way? Or am I wrong in thinking this was a good thing to do? TIA nuffi
ipsec.conf macros
Hello!
In transitioning from isakmpd.conf to ipsec.conf I want to make the
configuration file simple and readable by using macros.
However, I seems like I can not make use of macros in the way that I want.
Example:
host_a=192.168.1.1
host_b=192.168.2.2
host_list={ $host_a $host_b }
host_a_copy=$host_a
list_copy=$host_list
Gives errors:
# ipsecctl -vnf ipsec_hosts.conf
ipsec_hosts.conf: 5: syntax error
ipsecctl: Syntax error in config file: ipsec rules not loaded
host_a = 192.168.1.1
host_b = 192.168.2.2
host_list = { 192.168.1.1 192.168.2.2 }
host_a_copy = 192.168.1.1
It gives me even more problem when I use macros with lists of networks:
network_a=192.168.1.0/24
network_b=192.168.2.0/24
network_a_copy=$network_a
network_list={ 192.168.1.0/24 192.168.2.0/24 }
network_list_copy=$network_list
network_list_1={ $network_a $network_b }
network_list_1_copy=$network_list_1
# ipsecctl -vnf ipsec_networks.conf
ipsec_networks.conf: 3: syntax error
ipsec_networks.conf: 5: syntax error
ipsec_networks.conf: 6: syntax error
ipsec_networks.conf: 7: macro 'network_list_1' not defined
ipsec_networks.conf: 7: syntax error
ipsecctl: Syntax error in config file: ipsec rules not loaded
network_a = 192.168.1.0/24
network_b = 192.168.2.0/24
network_list = { 192.168.1.0/24 192.168.2.0/24 }
Is is supposed to work, or is it a bug? Or is there another way of doing it,
am I doing it wrong?
Thank you,
Jakob Alvermark
jakob.alverm...@bsdlabs.com
BSDLabs AB
Solna, Sweden
556759-7652
Re: Ipsec/NAT rules in ipsec.conf
On 2011-06-20, Marko Viitanen ma...@avoltus.net wrote:
Hi,
I'm running an OpenBSD 4.8 firewall cluster doing ipsec and packet
filtering. Due to customer requirements I've used IPSec outgoing network
address translation and it does exactly what I want it to do. However
I've come to a situation where we need access to customer's network from
two internal networks. I added an ipsec rule identical to the working
one with the different local net defition (se the ipsec.conf sample
below) and discovered that only the second rule is actually applied.
You can only have one ipsec.conf rule per peer, the last one takes
effect.
ipsecctl -vvf /etc/ipsec.conf shows that both the rules are parsed
without errors. ipsecctl -sa shows only one flow according to the second
rule installed and only the traffic from LocalNet2 to RemoteNetCustomer
works. Changing the order of the rules causes again only the second rule
(from LocalNet1 in this case) to be applied. I've found out that
LocalNet definition only allows one network definition. Using shorter
netmask for LocalNet would be a solution if the network numbers were
chosen knowing this issue but for now it is not possible to combine them
under one definition.
ike esp from $LocalNetCustomer ($LocalNet1) to $RemoteNetCustomer \
local $LocalGw peer $RemoteGw \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des group none \
psk XYZ
ike esp from $LocalNetCustomer ($LocalNet2) to $RemoteNetCustomer \
local $LocalGw peer $RemoteGw \
main auth hmac-sha1 enc 3des group modp1024 \
quick auth hmac-sha1 enc 3des group none \
psk XYZ
I've also tried the configuration in OpenBSD 4.9 under Virtualbox with
the same results.
I wonder if this is a desired feature, bug or a configuration issue.
This is just not implemented yet. Would be handy though.
FWIW the following config style also isn't supported.
ike esp from { \
192.168.46.248 (10.15.5.0/24), \
192.168.46.248 (172.16.73.224/28) \
} to 192.168.40.0/21 peer $foo
Ipsec/NAT rules in ipsec.conf
Hi, I'm running an OpenBSD 4.8 firewall cluster doing ipsec and packet filtering. Due to customer requirements I've used IPSec outgoing network address translation and it does exactly what I want it to do. However I've come to a situation where we need access to customer's network from two internal networks. I added an ipsec rule identical to the working one with the different local net defition (se the ipsec.conf sample below) and discovered that only the second rule is actually applied. ipsecctl -vvf /etc/ipsec.conf shows that both the rules are parsed without errors. ipsecctl -sa shows only one flow according to the second rule installed and only the traffic from LocalNet2 to RemoteNetCustomer works. Changing the order of the rules causes again only the second rule (from LocalNet1 in this case) to be applied. I've found out that LocalNet definition only allows one network definition. Using shorter netmask for LocalNet would be a solution if the network numbers were chosen knowing this issue but for now it is not possible to combine them under one definition. ike esp from $LocalNetCustomer ($LocalNet1) to $RemoteNetCustomer \ local $LocalGw peer $RemoteGw \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group none \ psk XYZ ike esp from $LocalNetCustomer ($LocalNet2) to $RemoteNetCustomer \ local $LocalGw peer $RemoteGw \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group none \ psk XYZ I've also tried the configuration in OpenBSD 4.9 under Virtualbox with the same results. I wonder if this is a desired feature, bug or a configuration issue. Br, Marko
ipsecctl/ipsec.conf: number-only macros not dereferencing
in 4.2/i386, number-only macros in ipsec.conf worked fine/parsed OK, syntax-wise: --- # cat test.conf cat = dog cow = $cat cat = 1234abc cow = $cat cat = 1234 cow = $cat # uname -msr; ipsecctl -nvvf ./test.conf OpenBSD 4.2 i386 cat = dog cow = dog cat = 1234abc cow = 1234abc cat = 1234 cow = 1234 warning: macro 'cow' not used # --- in 4.7 -current/amd64, it fails: --- # uname -msr; ipsecctl -nf test.conf OpenBSD 4.7 amd64 cat = dog cow = dog cat = 1234abc cow = 1234abc cat = 1234 test.conf: 6: syntax error warning: macro 'cow' not used ipsecctl: Syntax error in config file: ipsec rules not loaded since i don't know for sure if this is a bug, i wanted to ask here, maybe this is intentional. -- jared
Re: ipsecctl/ipsec.conf: number-only macros not dereferencing
for what it's worth, pfctl in -current parses this situation fine, but ipsecctl does not: # cat cow.conf cow = 'moo' moo = $cow cow = '1234' moo = $cow cow = ' 1234 ' moo = $cow cow = '12a34' moo = $cow # ipsecctl -nvf ./cow.conf cow = moo moo = moo cow = 1234 ./cow.conf: 4: syntax error cow = 1234 ./cow.conf: 6: syntax error cow = 12a34 moo = 12a34 ipsecctl: Syntax error in config file: ipsec rules not loaded # pfctl -nvf ./cow.conf cow = moo moo = moo cow = 1234 moo = 1234 cow = 1234 moo = 1234 cow = 12a34 moo = 12a34 # i went on and tested '-nvf ./cow.conf' in each of: bgpd, ldapd, ldpd, ospfd, relayd, ripd, snmpd, smtpd, ypldap. they all errored out only exactly on lines 4 and 6 m4(1) seems to parse the file fine though. assuming these are all supposed to be consistent, is pfctl/m4 the way things should be, or are all these other things the way things should be? -- jared
Re: ipsecctl/ipsec.conf: number-only macros not dereferencing
i went on and tested '-nvf ./cow.conf' in each of: bgpd, ldapd, ldpd, ospfd, relayd, ripd, snmpd, smtpd, ypldap. they all errored out only exactly on lines 4 and 6 m4(1) seems to parse the file fine though. assuming these are all supposed to be consistent, is pfctl/m4 the way things should be, or are all these other things the way things should be? there may be consistancy problem's between our daemons, but our daemons ARE NOT M4. What next? sh doesn't parse them! Oh my god, mozilla hates them.
Re: ipsecctl/ipsec.conf: number-only macros not dereferencing
On Thu, Jul 22, 2010 at 08:05:55PM -0600, Theo de Raadt wrote: i went on and tested '-nvf ./cow.conf' in each of: bgpd, ldapd, ldpd, ospfd, relayd, ripd, snmpd, smtpd, ypldap. they all errored out only exactly on lines 4 and 6 m4(1) seems to parse the file fine though. assuming these are all supposed to be consistent, is pfctl/m4 the way things should be, or are all these other things the way things should be? there may be consistancy problem's between our daemons, but our daemons ARE NOT M4. What next? i checked m4 because i recall seeing reference to 'much like cpp(1) or m4(1), macros can be used...' comment i've seen in one or more of the manpages. sh doesn't parse them! Oh my god, mozilla hates them. i didn't know if the above i tested are meant to be built around the same parse.y model/framework, but i see the parse.y/yylex stuff in their source dirs, so that was the original nature of my question -- by virtue of ipsecctl parsing it fine in a previous version, but not in -current, is this specific behaviour the way of the future or accidental? -- jared
Re: ipsecctl/ipsec.conf: number-only macros not dereferencing
On Thu, Jul 22, 2010 at 07:43:55PM -0701, jared r r spiegel wrote: is this specific behaviour the way of the future or accidental? if it helps answer that, ipsecctl/parse.y r1.126 (first ipsecctl/parse.y of 4.2-current) is the first revision that all-number macros can't be used in macros. r1.125 (OPENBSD_4_2) parses them ok. just trying to understand if i need to be changing my configs (trying to upgrade some 4.2 machines) or submitting a bugreport. -- jared
Re: ipsec.conf syntax
On Mon, Jun 07, 2010 at 03:14:19PM -0400, Russell Sutherland wrote: I am trying to set up an ipsec bridge using the template and instructions found in the brconfig man page (OpenBSD 4.6): Create Security Associations (SAs) between the external IP address of each bridge and matching ingress flows by using the following ipsec.conf(5) file on bridge1: esp from 1.2.3.4 to 4.3.2.1 spi 0x4242:0x4243 \ authkey file auth1:auth2 enckey file enc1:enc2 flow esp proto etherip from 1.2.3.4 to 4.3.2.1 I was curious as to the exact meaning of the colon, specifically the auth1:auth2 and enc1:enc2 arguments. Do they mean references to the 4 keys, two on each of the machines? E.g. om 1.2.3.4 to 4.3.2.1 spi 0x4242:0x4243 \ authkey file /etc/keys/auth1:/etc/keys/auth2 enckey file /etc/keys/enc1:/etc/keys/enc2 flow esp proto etherip from 1.2.3.4 to 4.3.2.1 good question - to which i have no answer ;) i suspect that the filenames chosen simply reflect the same notation used for the spi number. certainly ipsec.conf(5) does not document anything special about the colon for filenames or spi numbers. maybe someone else has something more definite? jmc
ipsec.conf syntax
I am trying to set up an ipsec bridge using the template and instructions found in the brconfig man page (OpenBSD 4.6): Create Security Associations (SAs) between the external IP address of each bridge and matching ingress flows by using the following ipsec.conf(5) file on bridge1: esp from 1.2.3.4 to 4.3.2.1 spi 0x4242:0x4243 \ authkey file auth1:auth2 enckey file enc1:enc2 flow esp proto etherip from 1.2.3.4 to 4.3.2.1 I was curious as to the exact meaning of the colon, specifically the auth1:auth2 and enc1:enc2 arguments. Do they mean references to the 4 keys, two on each of the machines? E.g. om 1.2.3.4 to 4.3.2.1 spi 0x4242:0x4243 \ authkey file /etc/keys/auth1:/etc/keys/auth2 enckey file /etc/keys/enc1:/etc/keys/enc2 flow esp proto etherip from 1.2.3.4 to 4.3.2.1 --- Russell P. Sutherland Email: russ @ madhaus.cns.utoronto.ca 4 Bancroft Ave., Rm. 102Voice: +1.416.978.0470 University of Toronto Fax: +1.416.978.6620 Toronto, ON M5S 1C1 CANADA
ipsec.conf x509 ( was Re: /etc/ipsec.conf default peer psk/dstid mismatch)
Hi, I hope someone on-list can give me a few helpful pointers in the right direction. I've setup certs as per X509 AUTHENTICATION section of the isakmpd man page. However it is a bit unclear as to what I need to put in ipsec.conf to make this work. I've tried a bit of Google trawling, however the examples I come up with seem to relate to older OpenBSD implementations where hacking of isakmpd.conf was part of the process, even for psk (e.g. back in the late 3.x days). I've setup a FQDN cert and have tried changing the config as below : #ROAD WARRIOR ike passive from 10.1.2.3 to 10.9.8.0/24 \ peer any \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ quick auth hmac-sha2-256 enc aes-256 \ srcid 192.168.111.1 dstid certificate.fqdn.name.here \ tag RoadRunner However I've got a feeling I've probably missed a whole lot of config somewhere ! If anyone has some working examples that would be fantastic, otherwise a few pointers in the right direction would be just fine. Thanks !
/etc/ipsec.conf default peer psk/dstid mismatch
Hello List, I've got this config that is working beautifully : #ROAD WARRIOR ike passive from 10.1.2.3 to 10.9.8.0/24 \ peer any \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ quick auth hmac-sha2-256 enc aes-256 \ srcid 192.168.111.1 dstid a...@example.com \ psk some_very_long_and_complicated_key \ tag RoadRunner However, if I go and copy/paste that snipped in order to lazily create a second user : #ROAD WARRIOR ike passive from 10.1.2.4 to 10.9.8.0/24 \ peer any \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ quick auth hmac-sha2-256 enc aes-256 \ srcid 192.168.111.1 dstid b...@example.com \ psk another_very_long_and_complicated_key \ tag RoadRunner Changing only the from,dstid and psk parameters. in other words : --- one.txt2010-03-30 00:00:00.0 + +++ two.txt2010-03-30 00:00:00.0 + @@ -1,8 +1,8 @@ -#ROAD WARRIOR -ike passive from 10.1.2.3 to 10.9.8.0/24 \ +#ROAD HOG +ike passive from 10.1.2.4 to 10.9.8.0/24 \ peer any \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ quick auth hmac-sha2-256 enc aes-256 \ -srcid 192.168.111.1 dstid a...@example.com \ -psk some_very_long_and_complicated_key \ +srcid 192.168.111.1 dstid b...@example.com \ +psk another_very_long_and_complicated_key \ tag RoadRunner I am greeted with the following wise words : # ipsecctl -f /etc/ipsec.conf /etc/ipsec.conf: 50: default peer psk mismatch /etc/ipsec.conf: 50: default peer dstid mismatch Delete my newly added block and it's all happy again. What am I doing wrong ? Or perhaps more imporantly, what part of the man pages have I not FR'd ? ;-)
Re: /etc/ipsec.conf default peer psk/dstid mismatch
On 2010-03-30, a b rclo...@yahoo.co.uk wrote: Hello List, I've got this config that is working beautifully : #ROAD WARRIOR ike passive from 10.1.2.3 to 10.9.8.0/24 \ peer any \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ quick auth hmac-sha2-256 enc aes-256 \ srcid 192.168.111.1 dstid a...@example.com \ psk some_very_long_and_complicated_key \ tag RoadRunner However, if I go and copy/paste that snipped in order to lazily create a second user : #ROAD WARRIOR ike passive from 10.1.2.4 to 10.9.8.0/24 \ peer any \ main auth hmac-sha2-256 enc aes-256 group modp2048 \ quick auth hmac-sha2-256 enc aes-256 \ srcid 192.168.111.1 dstid b...@example.com \ psk another_very_long_and_complicated_key \ tag RoadRunner Changing only the from,dstid and psk parameters. in other words : you can only have one peer any configured. therefore if you want to have users connecting from unknown addresses, they must either use the same psk, or use keys instead. or, to put it another way, if you want each user to have a separate psk, you need to know IP addresses in advance. (you can have one psk per known address, and a fallback default psk for any other connections). to get a better understanding: try 'ipsecctl -nvf /etc/ipsec.conf' and compare the output with the two rules; notice which section the psk appears in and try setting an address with 'peer 1.1.1.1' instead of 'peer any' to see what happens.
Re: /etc/ipsec.conf default peer psk/dstid mismatch
Thanks for the wise words Stuart.makes sense now ! Stuart Henderson wrote : you can only have one peer any configured. therefore if you want to have users connecting from unknown addresses, they must either use the same psk, or use keys instead.
IPSEC: trying to understand ipsec.conf(5)
Hi,
I'm running an IPSEC setup using iskampd.conf + isakmpd.policy, and
would like to move to using ipsec.conf instead.
First off, I noticed that, if isakmpd is running w/o the '-K' switch,
running 'ipsecctl -f somefile' results in a problem accessing
/var/run/isakmpd.fifo, with a file does not exist error.
I have cobbled together a very simple configuration, derived from the
classic East-West style config files that I already use (and which work
great). In /etc/isakmpd/certs I have the public part of an X.509
certificate for all affected parties, esp. the IPSEC peers, named like
this:
1.2.3.4.crt for a peer with id type IPV4_ADDR and an IP number of
1.2.3.4. For mobile users, I have certificates in the same directory
named u...@example.com.crt for an UFQDN id of u...@example.com.
In /etc/isakmpd/private I have the machine's own private key file,
corresponding to their id (eg. 1.2.3.4.key for a VPN gateway).
The tunnels are all set up mostly the same way, using main mode, X.509
certificates for authentication, PFS, tunnel mode, and IKE
configuration in case of mobile users.
To test my new ipsec.conf file, I temporarily moved the
isakmpd.{conf,policy} files out of the way, restarted isakmpd with -K,
and ran ipsecctl -f my-ipsec.conf file, which reads like this,
following the example closely:
ike esp from 172.17.16.0/24 to 172.17.0/20 peer 1.2.3.4 \
srcid 1.2.3.5 dstid 1.2.3.4
ike esp from 1.2.3.5 to 1.2.3.4 \
srcid 1.2.3.5 dstid 1.2.3.4
The tunnel doesn't come up, and the log files (-DA=90) shows:
Default ike_phase_1_recv_ID: received remote ID other than expected 1.2.3.4
Collecting some packets I can see:
17:33:56.358776 1.2.3.4.500 1.2.3.5.500: [udp sum ok] isakmp v1.0 exchange
ID_PROT
cookie: 10e2114ec84c8a9d-2cd65760e925dc55 msgid: len: 1292
payload: ID len: 12 type: IPV4_ADDR = 1.2.3.4
payload: CERT len: 992
payload: SIG len: 260 [ttl 0] (id 1, len 1320)
The ID is both in the CN and the subjectAltName attribute of the
certificate involved.
I've also tried without the 'srcid' and 'dstid' specifiers, as the man
page says that, in this case, the IP number(s) are taken as IDs, but
still no luck.
What gives?
Kind regards,
--Toni++
Re: IPSEC: trying to understand ipsec.conf(5)
Hi, On Sun, 24.01.2010 at 17:47:22 +0100, Toni Mueller openbsd-m...@oeko.net wrote: First off, I noticed that, if isakmpd is running w/o the '-K' switch, running 'ipsecctl -f somefile' results in a problem accessing /var/run/isakmpd.fifo, with a file does not exist error. scratch that - this is bogus, and only a side effect of isakmpd not finding the file when running w/o -K. Sorry I forgot to delete it before sending the original message. -- Kind regards, --Toni++
Re: ipsec.conf ipsecctl isakmpd
On Aug 10, 2009, at 6:37 PM, Christopher Sean Hilton wrote: I have a couple of questions regarding setting up ipsec. I've read the 4 minutes page and modified the older setup to work with 2 OpenBSD 4.5 boxes. That's enough to get me going with an IPsec tunnel by IP addresses but one side of my connection is a consumer grade DSL line which wants to have it's address changed every 5 minutes (sigh). I obviously need to setup ipsec with FQDN. I initially tried to do this with certificates but I couldn't get things to work so I've rolled back to using public keys and everything appears to be okay. My question is this: When you use certficates does isakmpd still use /etc/isakmpd/private/local.key as the private key for the crypto negotiation or can that be changed. Thanks for the followups. IT looks like local.key is the key if you don't use the local tag in your configuration as in: ike passive esp from hisname.hisnet.histld to myname.mynet.mytld \ local my_identifier Thanks again. -- Chris Chris Hilton tildeChris -- http://myblog.vindaloo.com email -- chris/at/vindaloo/ dot/com .~ ~ .--.~ ~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~. I'm on the outside looking inside, What do I see? Much confusion, disillution, all around me. -- Ian McDonald / Peter Sinfield
ipsec.conf ipsecctl isakmpd
I have a couple of questions regarding setting up ipsec. I've read the 4 minutes page and modified the older setup to work with 2 OpenBSD 4.5 boxes. That's enough to get me going with an IPsec tunnel by IP addresses but one side of my connection is a consumer grade DSL line which wants to have it's address changed every 5 minutes (sigh). I obviously need to setup ipsec with FQDN. I initially tried to do this with certificates but I couldn't get things to work so I've rolled back to using public keys and everything appears to be okay. My question is this: When you use certficates does isakmpd still use /etc/isakmpd/private/local.key as the private key for the crypto negotiation or can that be changed. -- Chris Chris Hilton tildeChris -- http://myblog.vindaloo.com email -- chris/at/vindaloo/ dot/com .~ ~ .--.~ ~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~. I'm on the outside looking inside, What do I see? Much confusion, disillution, all around me. -- Ian McDonald / Peter Sinfield
Re: ipsec.conf ipsecctl isakmpd
On Mon, Aug 10, 2009 at 06:37:41PM -0400, Christopher Sean Hilton wrote: I have a couple of questions regarding setting up ipsec. I've read the 4 minutes page and modified the older setup to work with 2 OpenBSD 4.5 boxes. That's enough to get me going with an IPsec tunnel by IP addresses but one side of my connection is a consumer grade DSL line which wants to have it's address changed every 5 minutes (sigh). I obviously need to setup ipsec with FQDN. I initially tried to do this with certificates but I couldn't get things to work so I've rolled back to using public keys and everything appears to be okay. My question is this: When you use certficates does isakmpd still use /etc/isakmpd/private/local.key as the private key for the crypto negotiation or can that be changed. By default isakmpd will use local.key, if you wish to use more than one private key you can rename the key to match the value of your ISAKMP Phase1-ID. For example, if your Phase1-ID is ID-type=IPV4_ADDR and Address=10.10.10.10 the corresponding key file would be /etc/isakmpd/private/10.10.10.10 Hoep this helps -- Mathieu Sauve-Frankel
ipsec.conf + RoadWarrior
Hi, I'm trying to setup the following IPsec scenario. 1. Clients are either OS X or Windows connecting from arbitrary IPs and hostnames and sometimes behind NAT connections. 2. OpenBSD 4.4 server. I have certificates created and signed by our CA with the e-mail address used as the UFQDN in the subjectAltName field. Similarly I have a certificate for the firewall with its IP address in the subjectAltName. The internal network is the subnet 192.168.0/24 and I would like to have addresses in the 192.168.1/24 range assigned to the VPN connections. I was wondering how this would be done with ipsec.conf? I have previously configured a similar setup using isakmpd.conf, but the examples for ipsec.conf only seem to address cases where both ends have hostnames or IP addresses that are known. In this case I don't have any idea of the client (except the cert). Anyone know how to do this? I was also wondering if its somehow possible to assign IP addresses dynamically in the 192.168.1/24 net for the clients? Previously I had a hardcoded IP for each client. Best regards, Edvard Fagerholm
Re: ipsec.conf + RoadWarrior
On 2009-04-27, Edvard Fagerholm efage...@cc.hut.fi wrote: 1. Clients are either OS X or Windows connecting from arbitrary IPs and hostnames and sometimes behind NAT connections. 2. OpenBSD 4.4 server. I have certificates created and signed by our CA with the e-mail address used as the UFQDN in the subjectAltName field. Similarly I have a certificate for the firewall with its IP address in the subjectAltName. The internal network is the subnet 192.168.0/24 and I would like to have addresses in the 192.168.1/24 range assigned to the VPN connections. I was wondering how this would be done with ipsec.conf? I have previously configured a similar setup using isakmpd.conf, but the examples for ipsec.conf only seem to address cases where both ends have hostnames or IP addresses that are known. In this case I don't have any idea of the client (except the cert). you can use to any to do this, but you also need a keynote policy to restrict the addresses users are allowed to ask for (otherwise you can be in for a whole bunch of fun if somebody enters a bad address).
migrate from isakmpd.conf to ipsec.conf
I used to configure VPNs using isakmpd.conf, for 2 dozen VPNs, each with a hand crafted set of parameters ( encryption, hmac, key length etc. ). Now I tried to move this setup to ipsec.conf by spelling out the complete line for every VPN like this: ike active esp tunnel from a.b.c.d to e.f.g.h peer u.v.w.x main auth hmac-sha1 enc aes group modp1024 quick auth hmac-sha1 enc aes group modp1024 psk xyz When I start isakmpd and configure these VPNs with ipsecctl -f /etc/ipsec.conf, all VPNs come up properly. But: alter a while, some VPNs stop working. tcpdump of isakmpd.pcap shows that the remote end tries to establish phase-1 with the same parameters that were used when my side ( openBSD ) establishes phase-1. But is rejected with 'NO PROPOSAL CHOSEN'. After setting isaqkmpd debug level, daemon.log reveals: Jan 12 14:00:09 q-dsl isakmpd[31387]: exchange_setup_p1: 0x8a499400 peer-u.v.w.x Default-phase-1-configuration policy responder phase 1 doi 1 exchange 2 step 0 This seems to indicate that for the incoming IP_PROT exchange the Default-phase-1-configuration is used, and the info from ipsec.conf is ignored. I found other incidences in the logfile where the remote end re-established the phase-1 successfully by initiating a ID_PROT exchange. In these case the debug message looks like: Jan 12 14:00:05 q-dsl isakmpd[31387]: exchange_setup_p1: 0x841b2700 peer-u.v.w.x phase1-peer-u.v.w.x policy responder phase 1 doi 1 exchange 2 step 0 I'm with you if you think the above text is rather confused, I apologize for that, I tried my very best :-) But you could do me a favour if you answered the following question: 1. Is it ok that the remote end initiates a phase-1 ID_PROT exchange for a VPN which I have defined as 'active' in my ipsec.conf. 2. If the answer is yes, am I right to expect that isakmpd uses the parameters I have specified for this VPN in ipsec.conf, finding the line with peer u.v.x.x = sender's IP Thank you for your patience. Regards Christoph
isakmpd question (isakmpd.conf - ipsec.conf)
Hi, in my VPN setup, I want to authenticate sites to each other using X.509 certificates. In my classic isakmpd.conf, I have this: [IPSEC-mobile-clients] Phase= 2 Configuration= mobile-quick-mode Local-ID= default-route Remote-ID= dummy-remote [default-route] ID-type=IPV4_ADDR_SUBNET Network=0.0.0.0 Netmask=0.0.0.0 [dummy-remote] ID-type=IPV4_ADDR Address=0.0.0.0 In my isakmpd.policy, I delegate to the individual certs. This works ok for my few dozen clients, but they have to have all the same configuration (ie, the least common denominator wins). Since people recommend using ipsec.conf, I wanted to transform this setup to using ipsec.conf. In my ipsec.conf, I have: myip=1.2.3.4 ike passive esp tunnel from $myip to any \ main auth hmac-sha1 enc aes-256 group modp1536 \ quick auth hmac-sha1 enc aes-256 group modp1536 \ srcid $myip dstid [EMAIL PROTECTED] This keeps isakmpd looking in /etc/isakmpd/pubkeys//ufqdn/[EMAIL PROTECTED] for a public key that I presumably have to create using keynote (right)? In any case, I have the certificates in place that I want to use instead, but they don't get touched, ever. I'm testing this with 4.3 and a snapshot from August 25th on one (gateway) side, and Linux+isakmpd on the other side, configured as a road warrior, but in production, this would also have to work with existing counterparts of all kinds, most of them Windows boxen. Any help is very much appreciated! Kind regards, --Toni++
Question about tags and ipsec.conf
Hi list, I have a firewall using the - very elegant - ipsec.conf to build tunnels to various Cisco's, Watchguards and other OpenBSD machines. My /etc/ipsec.conf is autogenerated and contains lots of: # bla-bla.router.company.example - router for location bla-bla ike esp from 192.168.100.0/24 to 192.168.145.0/24 peer xxx.xxx.xxx.xxx \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group modp1024 \ psk IWouldLoveTheGoatThankYouVeryMuch tag bla-bla.router.company.example To identify the packets belonging to a particular VPN we assign a tag to each connection corresponding to its location name. Recently I had an IP address of a location change so I modified the IP address in ipsec.conf, carefully checked with -n and reloaded. This did not cause a new SA to be created to the new IP address. After much head-scratching I eventually changed the tag to something else and the tunnel was created right away. I thought tags were just tacked onto a packet by PF to facilitate further internal handling but apparently there is more to it than that. Is this by design and am I missing some important point about either ipsec.conf or tagging? (or states?) On a related note, it would be nice to have had a -K flow switch for ipsecctl to delete specific flows. But I imagine there is a good reason for its absence due to the change of requiring -k to show secret keying material. IPSec on this firewall has been absolutely rock-solid by the way, about 60 flows using a mix of 3DES and AES. Much better than the fancy Watchguard box that it replaced. -- Michiel van der Kraats
Re: ipsec.conf question
On Mon, May 05 2008 at 20:14, Prabhu Gurumurthy wrote: All, I have a question regarding ipsec.conf. Example: IPsec peers: 3.3.3.3, 3.3.3.2 Interesting traffic: 1.1.1.1 - 192.168.100.2 2.2.2.2 - 192.168.100.0/24 Main/Quick mode crypto/groups being: aes, sha1 and group2 PSK being test123 How can I define the above concisely? I can, for example, do the following: ike esp from 1.1.1.1 to 192.168.100.2 \ local 3.3.3.3 peer 3.3.3.2\ main auth hmac-sha1 enc aes group modp1024 \ quick auth hmac-sha1 enc aes group modp1024 \ psk test123 ike esp from 2.2.2.2 to 192.168.100.0/24 \ local 3.3.3.3 peer 3.3.3.2\ main auth hmac-sha1 enc aes group modp1024 \ quick auth hmac-sha1 enc aes group modp1024 \ psk test123 Is there any way to shorten it? since most of it seem to be redundant except for the interesting traffic part. You can simply use macro as in pf.conf. For example : LAN_priv = 192.168.100.0/24 Our_PSK = test123 IPSEC_peers = local 3.3.3.3 peer 3.3.3.2 IPSEC_crypto = main auth hmac-sha1 enc aes group modp1024 quick auth hmac-sha1 enc aes group modp1024 ike esp from $IP_pub_1 to $IP_priv $IPSEC_peers $IPSEC_crypto \ psk $Our_PSK ike esp from $IP_pub_2 to $LAN_priv $IPSEC_peers $IPSEC_crypto \ psk $Our_PSK With 4.3-current you can use includes. Sample from man page : Additional configuration files can be included with the include keyword, for example: include /etc/macros.conf Claer
ipsec.conf question
All, I have a question regarding ipsec.conf. Example: IPsec peers: 3.3.3.3, 3.3.3.2 Interesting traffic: 1.1.1.1 - 192.168.100.2 2.2.2.2 - 192.168.100.0/24 Main/Quick mode crypto/groups being: aes, sha1 and group2 PSK being test123 How can I define the above concisely? I can, for example, do the following: ike esp from 1.1.1.1 to 192.168.100.2 \ local 3.3.3.3 peer 3.3.3.2\ main auth hmac-sha1 enc aes group modp1024 \ quick auth hmac-sha1 enc aes group modp1024 \ psk test123 ike esp from 2.2.2.2 to 192.168.100.0/24 \ local 3.3.3.3 peer 3.3.3.2\ main auth hmac-sha1 enc aes group modp1024 \ quick auth hmac-sha1 enc aes group modp1024 \ psk test123 Is there any way to shorten it? since most of it seem to be redundant except for the interesting traffic part. FWIW, I am running 4.3-current: OpenBSD pgurumur-vm-openbsd.xxx.com 4.3 GENERIC#732 i386 Thanks Prabhu -
ipsec.conf and ipsecctl
Dear list, I have a firewall and an ipsec.conf with 42 ike esp connections: ike esp from 192.168.100.0/24 to 192.168.129.0/24 peer my.firewall \ main auth hmac-sha1 enc 3des group modp1024 \ quick auth hmac-sha1 enc 3des group modp1024 \ psk mekmitasdigoat tag yet.another.connection ISAkmpd is started with the -K -T. I am talking to lots of Watchguard Fireboxes by the way. All connections are established and traffic flows over enc0, all seems good. However, when I try to reload ipsec.conf due to a rule change, either isakmpd dies with nothing in the logs whatsoever and/or my /var/log/daemon is filling up with messages like these: Feb 25 14:00:41 evo-access isakmpd[27974]: attribute_unacceptable: AUTHENTICATION_METHOD: got PRE_SHARED, expected RSA_SIG Feb 25 14:00:41 evo-access isakmpd[27974]: message_negotiate_sa: no compatible proposal found Feb 25 14:00:41 evo-access isakmpd[27974]: dropped message from some.ipsec.peer port 500 due to notification type NO_PROPOSAL_ CHOSEN I would like to be using something other than shared keys but the Watchguard boxes only support fancy things like that through a Watchguard System Manager which I'd like to avoid. So for the moment I am stuck with preshared keys. If I do ipsecctl -F and do a kill and restart of isakmpd the connections seem to be established succesfully again. Am I missing something obvious in reloading/adding connections to ipsec.conf ? Is a simple ipsecctl -f /etc/ipsec.conf sufficient when adding a rule or do I need to give isakmpd a SIGHUP? Thanks in advance, -- Michiel van der Kraats
Re: Suggestion for ipsec.conf(5)
On Sun, Feb 10, 2008 at 10:43:36PM +0100, Aurilien wrote: In the [manual flows] section of the ipsec.conf man page, the [type modifier] parameter doesn't explain require, use, acquire and dontacq modifiers. The explanation from the old ipsecadm(8) should be use: fixed now. thanks for the mail, jmc
Suggestion for ipsec.conf(5)
In the [manual flows] section of the ipsec.conf man page, the [type modifier] parameter doesn't explain require, use, acquire and dontacq modifiers. The explanation from the old ipsecadm(8) should be use: A use flow, specify that packets matching this flow should try to use IPsec if possible. A acquire For flow specify that packets matching this flow should try to use IPsec and establish SAs dynamically if possible, but permit unencrypted traffic. A require flow specify that packets matching this flow must use IPsec, and establish SAs dynamically as needed. If no SAs are established, traffic is not allowed through. A dontacq flow specify that packets matching this flow must use IPsec. If such SAs are not present, simply drop the packets. Such a policy may be used to demand peers establish SAs before they can communicate with us, without going through the burden of initiating the SA ourselves (thus allowing for some denial of service attacks). This flow type is particularly suitable for security gateways. Aurilien.
ipsec.conf config for shrew.net client
does any have an example ipsec.conf config for a windows shrew.net ipsec client ? in particular, a roaming client? -- It is an old observation that the best writers sometimes disregard the rules of rhetoric. When they do, however, the reader will usually find in the sentence some compensating merit, attained at the cost of the violation. Unless he is certain of doing as well, he will probably do best to follow the rules. --William Strunk
ipsec.conf and AES 256
As far as I can tell, currently in ipsec.conf there is no way to use AES with KEY_LENGHT=256. Is anybody working on adding this? Otherwise I might try it when the time permits. I'm thinking that isakmpd should first learn about a new default transform, let's say AES256 - then adding that into ipsecctl/ipsec.conf should be pretty much trivial. The other route is not to add this new default transform to isakmpd, but to have ipsecctl generate a config with a non-default transform - this does not touch isakmpd at all, but is less than trivial in ipsecctl. Thoughts, anyone? Mitja
Re: ipsec.conf and AES 256
On Mon, Nov 19, 2007 at 12:26:16PM +0100, Mitja Mu?eni? wrote: As far as I can tell, currently in ipsec.conf there is no way to use AES with KEY_LENGHT=256. Is anybody working on adding this? Otherwise I might try it when the time permits. I'm thinking that isakmpd should first learn about a new default transform, let's say AES256 - then adding that into ipsecctl/ipsec.conf should be pretty much trivial. this sounds like a reasonable approach to me. The other route is not to add this new default transform to isakmpd, but to have ipsecctl generate a config with a non-default transform - this does not touch isakmpd at all, but is less than trivial in ipsecctl. Thoughts, anyone? Mitja
Re: Hoe to specify multiple transform suites in ipsec.conf(5)
From: Heinrich Rebehn [EMAIL PROTECTED]
Date: 29 October 2007 9:14:16 PM
To: OpenBSD misc@openbsd.org
Subject: Hoe to specify multiple transform suites in ipsec.conf(5)
Hello list,
I am trying to move my IPsec configuration from isakmpd.conf to
ipsec.conf.
However i cannot find a syntax to specify multiple transform suites
with ipsec.conf
I tried something like:
ike passive esp from any to any quick enc {aes,3des}
but it is rejected.
I want something like
Suites=QM-ESP-AES-SHA2-256-PFS-SUITE,QM-ESP-3DES-PFS-SUITE
as a result.
As a workaround i can stuff it into the running configuration using
isakmpd's fifo, but that is not a very robust solution.
Specifying
Default-phase-2-suites = QM-ESP-3DES-MD5-PFS-SUITE,QM-ESP-AES-
SHA2-256-PFS-SUITE
in isakmpd.conf
does not help, because ipsecctl overrides it. Is there a way to
tell ipsecctl to not specify a suite at all, so that the default is
used?
BTW, is ipsec.conf meant to ever become a full replacement for
isakmpd.conf?
Thanks for any hints.
--
Heinrich,
I've tried to do the same - see http://readlist.com/lists/openbsd.org/
misc/12/62613.html - as of 4.1 this is not supported by ipsec.conf(5).
Best wishes,
Damon
Re: Hoe to specify multiple transform suites in ipsec.conf(5)
Damon McMahon wrote:
From: Heinrich Rebehn [EMAIL PROTECTED]
Date: 29 October 2007 9:14:16 PM
To: OpenBSD misc@openbsd.org
Subject: Hoe to specify multiple transform suites in ipsec.conf(5)
Hello list,
I am trying to move my IPsec configuration from isakmpd.conf to
ipsec.conf.
However i cannot find a syntax to specify multiple transform suites
with ipsec.conf
I tried something like:
ike passive esp from any to any quick enc {aes,3des}
but it is rejected.
I want something like
Suites=QM-ESP-AES-SHA2-256-PFS-SUITE,QM-ESP-3DES-PFS-SUITE
as a result.
As a workaround i can stuff it into the running configuration using
isakmpd's fifo, but that is not a very robust solution.
Specifying
Default-phase-2-suites =
QM-ESP-3DES-MD5-PFS-SUITE,QM-ESP-AES-SHA2-256-PFS-SUITE
in isakmpd.conf
does not help, because ipsecctl overrides it. Is there a way to tell
ipsecctl to not specify a suite at all, so that the default is used?
BTW, is ipsec.conf meant to ever become a full replacement for
isakmpd.conf?
Thanks for any hints.
--
Heinrich,
I've tried to do the same - see
http://readlist.com/lists/openbsd.org/misc/12/62613.html - as of 4.1
this is not supported by ipsec.conf(5).
Best wishes,
Damon
Thanks for your reply, Damon. I missed your post when searching the
archives.
You wrote that isakmpd.conf is deprecated. Obviously this is not (yet)
quite so.
Kind regards,
Heinrich
Hoe to specify multiple transform suites in ipsec.conf(5)
Hello list,
I am trying to move my IPsec configuration from isakmpd.conf to ipsec.conf.
However i cannot find a syntax to specify multiple transform suites with
ipsec.conf
I tried something like:
ike passive esp from any to any quick enc {aes,3des}
but it is rejected.
I want something like
Suites=QM-ESP-AES-SHA2-256-PFS-SUITE,QM-ESP-3DES-PFS-SUITE
as a result.
As a workaround i can stuff it into the running configuration using
isakmpd's fifo, but that is not a very robust solution.
Specifying
Default-phase-2-suites =
QM-ESP-3DES-MD5-PFS-SUITE,QM-ESP-AES-SHA2-256-PFS-SUITE
in isakmpd.conf
does not help, because ipsecctl overrides it. Is there a way to tell
ipsecctl to not specify a suite at all, so that the default is used?
BTW, is ipsec.conf meant to ever become a full replacement for isakmpd.conf?
Thanks for any hints.
--
Heinrich Rebehn
University of Bremen
Physics / Electrical and Electronics Engineering
- Department of Telecommunications -
Phone : +49/421/218-4664
Fax :-3341
aes 256 in ipsec.conf ?
Hi, is AES 256 cipher supported in OBSD 4.1 ipsec implementation? If it is, how can I specify this as input to ipsecctl ( ipsec.conf )? regards Christoph
ipsec.conf - format of key specification
What is the proper format for entering manual keys directly into the ipsec.conf file? Test file ipsec.test: esp from 10.0.0.1 to 10.0.1.1 \ spi 0x1011:0x1010 \ auth hmac-sha1 enc aes \ authkey 1234567890123456789012345678901234567890 \ enckey 12345678901234567890123456789012 \ # ipsecctl -n -f ipsec.test ipsec.test: 5: no authentication key specified ipsecctl: Syntax error in config file: ipsec rules not loaded The same happens if the key is specified: 12345678901234567890123456789012 0x12345678901234567890123456789012 0x12345678901234567890123456789012 The man page only specifies a 'hexadecimal string'. The same thing happens if the key is entered into a file and the 'authkey file' directive is used. Any help would be appreciated. -- Jeff Simmons [EMAIL PROTECTED] Simmons Consulting - Network Engineering, Administration, Security You guys, I don't hear any noise. Are you sure you're doing it right? -- My Life With The Thrill Kill Kult
Re: ipsec.conf - format of key specification
On 2007/09/13 11:43, Jeff Simmons wrote: What is the proper format for entering manual keys directly into the ipsec.conf file? Test file ipsec.test: esp from 10.0.0.1 to 10.0.1.1 \ spi 0x1011:0x1010 \ auth hmac-sha1 enc aes \ authkey 1234567890123456789012345678901234567890 \ enckey 12345678901234567890123456789012 \ I think the doc is lacking here. When you use the spi 0x:0x format to setup bidirectional flows in one ipsec.conf rule, you need to specify one key for each spi, separated by a : See /usr/src/regress/sbin/ipsecctl/sa7.in for an example.
IPSEC.CONF with Dynamic IP address (parse HOST name) doesnt seem to work
Hello everyone, I have several VPN tunnels between OBSD 3.8 systems (LAN to LAN via VPN). These all have fixed IP addresses and all works fine :-) . However, now I have a OBSD 3.8 system that gets a Dynamic IP address. I mapped that address to a hostname using DynDNS.org Using ipcheck.py (a python program) it keeps the DynDns.org DNS servers up-to-date when a IP change occurs. So far, so good. I was hoping to simply use the DynDns host name in the IPSEC.CONF file, but that doesnt seem to work :-(( . For this mail I changed the name to remote5.dyndns.org. The real name pings ok can Ii can use it to SSH into the machine. # # IPSEC to remote location 5 # Active host, remote location is passive # ike esp from 172.17.0.0/16 to 192.168.76.0/22 peer remote5.dyndns.org ike esp from openbsd ip to 192.168.76.0/22 peer remote5.dyndns.org ike esp from openbsd ip to remote5.dyndns.org Note the remote5.dyndns.org instead of a IP address. When I load this config file I get : # ipsecctl -f /etc/ipsec.conf /etc/ipsec.conf: 46: could not parse host specification /etc/ipsec.conf: 47: could not parse host specification /etc/ipsec.conf: 48: could not parse host specification ipsecctl: Syntax error in config file: ipsec rules not loaded How to get around this, that is, get the host named 'parsed' inside the ipsec.conf file towards the correct IP address ? regards Wiljoh
Re: IPSEC.CONF with Dynamic IP address (parse HOST name) doesnt seem to work
Just use a recent snapshot. Support for names instead of ip addresses has been added, mh, at least a year ago. HJ. On Tue, Sep 04, 2007 at 12:32:55PM +0200, * VLGroup Forums wrote: Hello everyone, I have several VPN tunnels between OBSD 3.8 systems (LAN to LAN via VPN). These all have fixed IP addresses and all works fine :-) . However, now I have a OBSD 3.8 system that gets a Dynamic IP address. I mapped that address to a hostname using DynDNS.org Using ipcheck.py (a python program) it keeps the DynDns.org DNS servers up-to-date when a IP change occurs. So far, so good. I was hoping to simply use the DynDns host name in the IPSEC.CONF file, but that doesnt seem to work :-(( . For this mail I changed the name to remote5.dyndns.org. The real name pings ok can Ii can use it to SSH into the machine. # # IPSEC to remote location 5 # Active host, remote location is passive # ike esp from 172.17.0.0/16 to 192.168.76.0/22 peer remote5.dyndns.org ike esp from openbsd ip to 192.168.76.0/22 peer remote5.dyndns.org ike esp from openbsd ip to remote5.dyndns.org Note the remote5.dyndns.org instead of a IP address. When I load this config file I get : # ipsecctl -f /etc/ipsec.conf /etc/ipsec.conf: 46: could not parse host specification /etc/ipsec.conf: 47: could not parse host specification /etc/ipsec.conf: 48: could not parse host specification ipsecctl: Syntax error in config file: ipsec rules not loaded How to get around this, that is, get the host named 'parsed' inside the ipsec.conf file towards the correct IP address ? regards Wiljoh
ipsec.conf/ipsecctl interop with Windows XP
Has anyone got ipsec.conf/ipsecctl to interop with Windows XP? I had this working flawlessly with my isakmpd.conf, but rather like the new syntax and want to switch. I have it to the point of giving me this message when I start isakmpd with '-K -d -vvv' 090413.992346 Default isakmpd: phase 1 done: initiator id /C=CA/ST=Ontario/L=Sault Ste. Marie/O=Clean North/[EMAIL PROTECTED], responder id c0a82101: 192.168.33.1, src: 192.168.33.1 dst: 192.168.33.151 But no tunnels are created and no more messages are displayed. My ipsec.conf looks like this (tried with and without the 'quick...' line: ike passive esp from any to 0.0.0.0 main auth hmac-sha1 enc 3des-cbc \ quick auth hmac-sha1 enc 3des-cbc \ group modp1024 And the isakmpd.conf (working) it replaces looks like this: [Phase 1] Default=ISAKMP-peer-WI [Phase-1-ID] ID-type=USER_FQDN Name= [EMAIL PROTECTED] [ISAKMP-peer-WI] Phase= 1 Transport= udp Configuration= Default-main-mode ID= Phase-1-ID [Default-main-mode] DOI=IPSEC EXCHANGE_TYPE= ID_PROT Transforms= 3DES-SHA-RSA [Default-quick-mode] DOI=IPSEC EXCHANGE_TYPE= QUICK_MODE Suites= QM-ESP-AES-SHA-PFS-SUITE [3DES-SHA-RSA] ENCRYPTION_ALGORITHM= 3DES_CBC HASH_ALGORITHM= SHA AUTHENTICATION_METHOD= RSA_SIG GROUP_DESCRIPTION= MODP_1024 Life= LIFE_28800_SECS [LIFE_28800_SECS] LIFE_TYPE= SECONDS LIFE_DURATION= 28800,600:36000 Is there anyone who knows the magic sauce I'm failing to sprinkle on this setup? I would be grateful for any assistance. Thanks. -Dan -- Burnished gallows set with red Caress the fevered, empty mind Of man who hangs bloodied and blind To reach for wisdom, not for bread. -- Deoridhe Grimsdaughter
