Re: OpenBSD as an IKEv2 IPsec client with L/P authent

2018-02-21 Thread Igor V. Gubenko
I am far from an expert; having issues myself at the moment, but maybe
if we get all of the iked experimenters together, we can figure it out
:) 

First, try "-dvv" ... an extra "v" might give more info. 

Next, from the existing trace it looks like your endpoint responds,
which is good, but your OpenBSD side doesn't seem to like it. 

My (uneducated) guess is that you should see what encryption pairs for
both phases are configured on the endpoint, and try to explicitly
specify them in your configuration. 

Also make sure that you are not firewall'ing ESP, et al. Check the docs
on what to allow in PF. "tcpdump" the egress interface (and/or pflog0)
to check whether you have anything going to /dev/null.

---
Igor V. Gubenko 

System Engineer 

On 2018-02-15 09:14, Joel Carnat wrote:

> Hi,
> 
> My FTTH home-box provides IKEv2 server support.
> I connected my iPhone, via 3G, to it. I can now access my internal home-LAN. 
> So I know it works.
> 
> I want to do the same with an OpenBSD server hosted in "the Cloud" ; in 
> transport mode as far as I understood the docs.
> I've struggled with ipsec.conf(5), ipsecctl(8) and iked(8) for a couple of 
> hours now but I can't connect OpenBSD to the box.
> 
> The home-box is using IKEv2 and User/Password authentication mode.
> The OpenBSD machine in 6.2/amd64.
> 
> I have configured iked.conf(5) like this:
> ikev2 active esp \
> from egress to 192.168.0.0/24 \
> peer 78.192.10.15
> 
> And running iked(8) goes:
> # iked -dv
> set_policy: could not find pubkey for /etc/iked/pubkeys/ipv4/78.192.10.15
> ikev2 "policy1" active esp inet from 108.61.176.54 to 192.168.0.0/24 local 
> any peer 78.192.10.15 ikesa enc aes-256,aes-192,aes-128,3des prf 
> hmac-sha2-256,hmac-sha1 auth hmac-sha2-256,hmac-sha1 group 
> modp2048,modp1536,modp1024 childsa enc aes-256,aes-192,aes-128 auth 
> hmac-sha2-256,hmac-sha1 lifetime 10800 bytes 536870912 rfc7427
> ikev2_msg_send: IKE_SA_INIT request from 0.0.0.0:500 to 78.192.10.15:500 
> msgid 0, 510 bytes
> ikev2_recv: IKE_SA_INIT response from responder 78.192.10.15:500 to 
> 108.61.176.54:500 policy 'policy1' id 0, 456 bytes
> 
> And that's all :(
> 
> Is there a way to use l/p authent with iked(8)?
> Or am I just not using the right software? In which case, what would the 
> proper tool be?
> 
> Thanks for help.


Re: iked and letsencrypt certs

2018-02-21 Thread Igor V. Gubenko
I have an issue using certs as well, though I am not 100% sure whether
it has to do with a CA cert chain (why did you come to this
conclusion?). Do you have a config and a debug trace to share?

---
Igor V. Gubenko 

System Engineer 

On 2018-02-21 20:14, Stuart Henderson wrote:

> Has anyone already figured out how to, or know whether it's possible
> to, get iked working with letsencrypt certs? (Or indeed any CA with
> chain certs?)
> 
> Use case: "standard" clients (Windows/iOS/StrongSwan), EAP auth,
> not particularly technical users so trying to avoid the need for them
> to manually install certs.
> 
> Most of it should be straightforward (at least for FQDN), the server
> cert has SAN, I think the main issue seems to be due to the chain cert.
> 
> If I place only the "CN=Let's Encrypt Authority X3" in iked/ca/ca.crt
> iked doesn't startup properly ("unable to get issuer certificate" for my
> own cert and "unable to get local issuer certificate" for the LE CA).
> 
> If I place only the "DST Root CA X3" in ca.crt I get "did not find
> subjectAltName" and "no valid local certificate found".
> 
> If I place both ca and chain certs in ca.crt it looks like it starts
> up ok:
> 
> ca_reload: loaded ca file ca.crt
> ca_reload: loaded crl file ca.crl
> ca_reload: /O=Digital Signature Trust Co./CN=DST Root CA X3
> ca_reload: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
> ca_reload: loaded 2 ca certificates
> ca_reload: loaded cert file blahblahblah.com.crt
> 
> but then actually connecting fails (at least from strongswan, I need to
> dig out the other test devices again..).


Re: another iked issue

2017-06-06 Thread Igor V. Gubenko
This indeed does help. Moved the policy to be the first. 

Thank you, 

- Igor 

On 2017-06-06 05:56, Zé Loff wrote:

> On Mon, Jun 05, 2017 at 07:50:01PM -0400, Igor V. Gubenko wrote: 
> 
>> Hello all,
>> 
>> I am continuing my assault on iked :)
>> 
>> Here is a perfectly working configuration that uses PSK's:
>> 
>> ###
>> 
>> local_ip = "A.B.1.153"
>> local_net = "172.16.0.0/20"
>> 
>> ikev2 "KBweb" \
>> passive ipcomp esp \
>> from $local_net to 10.33.33.0/27 \
>> local $local_ip \
>> peer C.D.65.236 \
>> ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \
>> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
>> srcid $local_ip \
>> dstid web01.domain.org \
>> psk thepsk
>> 
>> ikev2 "KBDB" \
>> passive ipcomp esp \
>> from $local_net to 10.34.34.0/27 \
>> local $local_ip \
>> peer C.D.65.237 \
>> ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \
>> childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
>> srcid $local_ip \
>> dstid db01.domain.org \
>> psk thepsk
>> 
>> ###
>> 
>> Now, I am adding a third connection, using certificates (presumably):
>> 
>> ##
>> 
>> user "igor" "thepassword"
>> 
>> ikev2 "roaming" \
>> passive esp \
>> from $local_net to 192.168.200.0/26 \
>> local $local_ip \
>> peer any \
>> eap "mschap-v2" \
>> config address 192.168.200.1 \
>> tag "$name-$id"
>> 
>> ##
>> 
>> This results in the first 2 connections never working anymore:
>> 
>> ikev2_msg_auth: responder auth data length 525
>> ikev2_msg_auth: initiator auth data length 488
>> ikev2_msg_authverify: method SHARED_KEY_MIC keylen 32 type NONE
>> ikev2_msg_authverify: authentication successful
>> sa_state: AUTH_REQUEST -> AUTH_SUCCESS
>> sa_stateflags: 0x0028 -> 0x0038 auth,authvalid,sa (required 0x0079
>> cert,auth,authvalid,sa,eapvalid)
>> ikev2_sa_negotiate: score 4
>> sa_stateflags: 0x0038 -> 0x0038 auth,authvalid,sa (required 0x0079
>> cert,auth,authvalid,sa,eapvalid)
>> sa_stateok: VALID flags 0x0038, require 0x0079
>> cert,auth,authvalid,sa,eapvalid
>> sa_state: cannot switch: AUTH_SUCCESS -> VALID
>> ikev2_ike_auth: no CERTREQ, using default
>> ikev2_policy2id: srcid IPV4/A.B.1.153 length 8
>> sa_stateflags: 0x0038 -> 0x003c certreq,auth,authvalid,sa (required
>> 0x0079 cert,auth,authvalid,sa,eapvalid)
>> config_free_proposals: free 0x23ee58d3f80
>> ca_getreq: found CA /C=US/ST=New Jersey/O=Gubenko/OU=IT/CN=cainter.dom.com
>> ca_x509_subjectaltname: unsupported subjectAltName type 34
>> ca_getreq: found CA /C=US/ST=New
>> Jersey/L=Livingston/O=Gubenko/OU=IT/CN=caroot.dom.com
>> ca_getreq: no valid local certificate found
>> ikev2_getimsgdata: imsg 19 rspi 0xbd166184c4d2d33b ispi
>> 0xd7fc1a37a3acdec4 initiator 0 sa valid type 0 data length 0
>> ikev2_dispatch_cert: cert type NONE length 0, ignored
>> 
>> As a side note, the certificate does contain several subjectAltName's:
>> 
>> X509v3 Subject Alternative Name:
>> DNS:ip6.dom.com, DNS:www.dom.com [1], DNS:www.ip6.dom.com [2],
>> DNS:mail.dom.com, DNS:imap.dom.com, DNS:smtp.dom.com, DNS:proxy.dom.com,
>> DNS:vpn.dom.com, DNS:pbx.dom.com
>> 
>> As soon as the third section is commented out, and iked restarted, the
>> first two connections come back up.
>> 
>> Please help.
> 
> RTFM
> 
> From iked.conf(5):
> 
> For incoming connections from remote peers, the policies are evaluated
> in sequential order, from first to last.  The last matching policy
> decides what action is taken; if no policy matches the connection, the
> default action is to ignore the connection attempt or to use the
> default policy, if set.  Please also see the EXAMPLES section for a
> detailed example of the policy evaluation.
> 
> (...)
> 
> EXAMPLES
> 
> (...)
> 
> The following example illustrates the last matching policy evaluation
> for incoming connections on an IKEv2 gateway.  The peer 192.168.1.34
> will always match the first policy because of the quick keyword;
> connections from the peers 192.168.1.3 and 192.168.1.2 will be matched
> by one of the last two policies; any other connections from
> 192.168.1.0/24 will be matched by the 'subnet' policy; and any other
> connection will be matched by the 'catch all' policy.
> 
> ikev2 quick esp from 10.10.10.0/24 to 10.20.20.0/24 \
> peer 192.168.1.34
> ikev2 "catch all" esp from 10.0.1.0/24 to 10.0.2.0/24 \
> peer any ikev2 "subnet" esp from 10.0.3.0/24 to 10.0.4.0/24 \
> peer 192.168.1.0/24
> ikev2 esp from 10.0.5.0/30 to 10.0.5.4/30 peer 192.168.1.2
> ikev2 esp from 10.0.5.8/30 to 10.0.5.12/30 peer 192.168.1.3
> 
> In summary you have a "last matching policy" and a "peer any" on the
> last rule.  Does it work if you move it upwards or add "quick" to the
> other rules?
> 
>> Many thanks,
>> 
>> - Igor
 

Links:
--
[1] http://www.dom.com
[2] http://www.ip6.dom.com


another iked issue

2017-06-05 Thread Igor V. Gubenko
Hello all,

I am continuing my assault on iked :)

Here is a perfectly working configuration that uses PSK's:

###

local_ip = "A.B.1.153"
local_net = "172.16.0.0/20"

ikev2 "KBweb" \
passive ipcomp esp \
from $local_net to 10.33.33.0/27 \
local $local_ip \
peer C.D.65.236 \
ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \
childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
srcid $local_ip \
dstid web01.domain.org \
psk thepsk


ikev2 "KBDB" \
passive ipcomp esp \
from $local_net to 10.34.34.0/27 \
local $local_ip \
peer C.D.65.237 \
ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \
childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
srcid $local_ip \
dstid db01.domain.org \
psk thepsk

###

Now, I am adding a third connection, using certificates (presumably):

##

user "igor" "thepassword"

ikev2 "roaming" \
passive esp \
from $local_net to 192.168.200.0/26 \
local $local_ip \
peer any \
eap "mschap-v2" \
config address 192.168.200.1 \
tag "$name-$id"

##


This results in the first 2 connections never working anymore:

ikev2_msg_auth: responder auth data length 525
ikev2_msg_auth: initiator auth data length 488
ikev2_msg_authverify: method SHARED_KEY_MIC keylen 32 type NONE
ikev2_msg_authverify: authentication successful
sa_state: AUTH_REQUEST -> AUTH_SUCCESS
sa_stateflags: 0x0028 -> 0x0038 auth,authvalid,sa (required 0x0079
cert,auth,authvalid,sa,eapvalid)
ikev2_sa_negotiate: score 4
sa_stateflags: 0x0038 -> 0x0038 auth,authvalid,sa (required 0x0079
cert,auth,authvalid,sa,eapvalid)
sa_stateok: VALID flags 0x0038, require 0x0079
cert,auth,authvalid,sa,eapvalid
sa_state: cannot switch: AUTH_SUCCESS -> VALID
ikev2_ike_auth: no CERTREQ, using default
ikev2_policy2id: srcid IPV4/A.B.1.153 length 8
sa_stateflags: 0x0038 -> 0x003c certreq,auth,authvalid,sa (required
0x0079 cert,auth,authvalid,sa,eapvalid)
config_free_proposals: free 0x23ee58d3f80
ca_getreq: found CA /C=US/ST=New Jersey/O=Gubenko/OU=IT/CN=cainter.dom.com
ca_x509_subjectaltname: unsupported subjectAltName type 34
ca_getreq: found CA /C=US/ST=New
Jersey/L=Livingston/O=Gubenko/OU=IT/CN=caroot.dom.com
ca_getreq: no valid local certificate found
ikev2_getimsgdata: imsg 19 rspi 0xbd166184c4d2d33b ispi
0xd7fc1a37a3acdec4 initiator 0 sa valid type 0 data length 0
ikev2_dispatch_cert: cert type NONE length 0, ignored


As a side note, the certificate does contain several subjectAltName's:

 X509v3 Subject Alternative Name:
DNS:ip6.dom.com, DNS:www.dom.com, DNS:www.ip6.dom.com,
DNS:mail.dom.com, DNS:imap.dom.com, DNS:smtp.dom.com, DNS:proxy.dom.com,
DNS:vpn.dom.com, DNS:pbx.dom.com


As soon as the third section is commented out, and iked restarted, the
first two connections come back up.


Please help.

Many thanks,

- Igor





iked/ikev2 road warrior setup

2017-05-25 Thread Igor V. Gubenko
Hello,

I have two OpenBSD 6.1-stable boxes in a CARP cluster. There are 3 carp
interfaces -

carp0 = Internal network (with its own separate ISP)

carp1 = Comcast

carp2 = Verizon


The interfaces are using 3 separate routing domains (the routing tables
below omit entries not of interest):

#

[Thu May 25 10:44:43 AM root@backupvpn2 (0 jobs) ~ ]# netstat -rn -f
inet -T0
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
defaultA.B.224.1  UGS 4295   348966 - 8 em0
A.B.224/21 A.B.226.53 UCn2 15056641 - 4 em0
A.B.224/21 A.B.226.56 Cn 00 -19 carp0
A.B.224.1  Y:Z:0c:9f:f6:a5  UHLch  3   648556 - 3 em0

##

[Thu May 25 10:47:36 AM root@backupvpn2 (0 jobs) ~ ]# netstat -rn -f
inet -T1
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
defaultC.D.173.150GS 017537 -23 carp1
C.D.173.144/29 C.D.173.146Cn 110932 -19 carp1
C.D.173.146W:X:5e:00:01:0a  UHLl   0  106 - 1 carp1
C.D.173.150link#8 HLch   1 6477 -18 carp1

##

[Thu May 25 10:47:47 AM root@backupvpn2 (0 jobs) ~ ]# netstat -rn -f
inet -T2
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio
Iface
defaultE.F.84.106  GS 067568 -23 carp2
E.F.84.104/29   E.F.84.107  Cn 111427 -19 carp2
E.F.84.106  link#10HLch   1 6674 -18 carp2
E.F.84.107  U:V:5e:00:01:14  UHLl   0 1204 - 1 carp2

###


I would like to setup an IKEv2 VPN for road warriors, so that they could
get in either via Verizon, or Comcast, whichever one is up.

I've setup the necessary certificates:

[Thu May 25 11:05:04 AM root@backupvpn2 (0 jobs) ~ ]# openssl rsa -in
/etc/iked/private/local.key -noout -check
RSA key ok

[Thu May 25 11:06:04 AM root@backupvpn2 (0 jobs) ~ ]# openssl rsa -in
/etc/iked/private/local.key -noout -modulus | md5
aa8152ada114ff81524dc91acb9dab1a
[Thu May 25 11:40:44 AM root@backupvpn2 (0 jobs) ~ ]# openssl rsa -in
/etc/iked/local.pub -pubin -noout -modulus | md5
aa8152ada114ff81524dc91acb9dab1a
[Thu May 25 11:06:24 AM root@backupvpn2 (0 jobs) ~ ]# openssl x509 -in
/etc/iked/certs/server.crt  -noout -modulus | md5
aa8152ada114ff81524dc91acb9dab1a

[Thu May 25 11:07:45 AM root@backupvpn2 (0 jobs) ~ ]# openssl crl -in
/etc/iked/crls/ca-inter-crl.pem -noout -verify -CAfile
/etc/iked/ca/ca-inter-cert.pem
verify OK
[Thu May 25 11:09:11 AM root@backupvpn2 (0 jobs) ~ ]# openssl crl -in
/etc/iked/crls/ca-root-crl.pem -noout -verify -CAfile
/etc/iked/ca/ca-root.pem
verify OK

[Thu May 25 11:33:24 AM root@backupvpn2 (0 jobs) ~ ]# openssl verify
-verbose -x509_strict -CApath /etc/iked/ca /etc/iked/certs/server.crt
/etc/iked/certs/server.crt: OK

[Thu May 25 11:44:56 AM root@backupvpn2 (0 jobs) ~ ]# openssl verify
-verbose -x509_strict -CApath /etc/iked/ca
/usr/local/monitoring/CA/Intermediate/certs/client-cert.pem
/usr/local/monitoring/CA/Intermediate/certs/client-cert.pem: OK


###

[Thu May 25 12:05:31 PM root@backupvpn2 (2 jobs) /etc/iked ]# pfctl -sr
| egrep "500|4500|ah|esp"
pass in on em1 inet proto udp from any to C.D.173.146 port = 500
pass in on em1 inet proto udp from any to C.D.173.146 port = 4500
pass in on em2 inet proto udp from any to E.F.84.107 port = 500
pass in on em2 inet proto udp from any to E.F.84.107 port = 4500
pass in on em2 inet proto ah from any to E.F.84.107
pass in on em2 inet proto esp from any to E.F.84.107
pass in on em1 inet proto ah from any to C.D.173.146
pass in on em1 inet proto esp from any to C.D.173.146



ikev2 "Comcast" \
passive esp \
from C.D.173.144/29 to 172.17.0.64/26 \
from A.B.0.0/16 to 172.17.0.64/26 \
local C.D.173.146 peer any \
srcid "/C=US/ST=New
Jersey/L=Princeton/O=MYORG/OU=EIS/CN=backupvpn.somedomain.com/emailAddress=network...@domain1.com"
\
config address 172.17.0.65


ikev2 "Verizon" \
passive esp \
from E.F.84.104/29 to 172.17.0.64/26 \
from A.B.0.0/16 to 172.17.0.64/26 \
local E.F.84.107 peer any \
srcid "/C=US/ST=New
Jersey/L=Princeton/O=MYORG/OU=EIS/CN=backupvpn.somedomain.com/emailAddress=network...@domain1.com"
\
config address 172.17.0.65

#

route -T2 exec iked -d -vv


ikev2_recv: IKE_SA_INIT request from initiator :60208 to
E.F.84.107:500 policy 'Verizon' id 0, 528 bytes
ikev2_recv: ispi 0xa37c52d1ac237b2f rspi 0x
ca_x509_name_parse: setting 'C' to 'US'
ca_x509_name_parse: setting 'ST' to 'New Jersey'
ca_x509_name_parse: setting 'L' to 'Princeton'
ca_x509_name_parse: setting 'O' to 'MYORG'

Re: iked/IKEv2 issue with 6.1

2017-04-21 Thread Igor V. Gubenko
Thanks again. The connections are all working.


On 4/20/17 8:54 PM, Igor V. Gubenko wrote:
> Thank you, the patch appears to work. I haven't fully tested
> connecting/establishing connections, so I'll send another update.
>
> Prior to the patch, iked also complained about lack of public keys for
> PSK connections 1 and 2 (in /etc/iked/pubkeys/fqdn/)
> It doesn't mind them being absent anymore though.
>
> - Igor
>
> On 4/20/17 5:44 PM, Reyk Floeter wrote:
>> --- sbin/iked/parse.y28 Mar 2017 16:56:39 -  1.64
>> +++ sbin/iked/parse.y20 Apr 2017 21:40:14 -
>> @@ -1807,7 +1807,7 @@ set_policy(char *idstr, int type, struct
>>  {
>>  char keyfile[PATH_MAX];
>>  const char  *prefix = NULL;
>> -EVP_PKEY*key;
>> +EVP_PKEY*key = NULL;
>>  
>>  switch (type) {
>>  case IKEV2_ID_IPV4:
>> @@ -1822,6 +1822,9 @@ set_policy(char *idstr, int type, struct
>>  case IKEV2_ID_UFQDN:
>>  prefix = "ufqdn";
>>  break;
>> +case IKEV2_ID_ASN1_DN:
>> +/* public key authentication is not supported with ASN.1 IDs */
>> +goto done;
>>  default:
>>  /* Unspecified ID or public key not supported for this type */
>>  log_debug("%s: unknown type = %d", __func__, type);
>> @@ -1841,6 +1844,7 @@ set_policy(char *idstr, int type, struct
>>  keyfile);
>>  }
>>  
>> + done:
>>  if (set_policy_auth_method(keyfile, key, pol) < 0) {
>>  EVP_PKEY_free(key);
>>  log_warnx("%s: failed to set policy auth method for %s",



Re: iked/IKEv2 issue with 6.1

2017-04-20 Thread Igor V. Gubenko
Thank you, the patch appears to work. I haven't fully tested
connecting/establishing connections, so I'll send another update.

Prior to the patch, iked also complained about lack of public keys for
PSK connections 1 and 2 (in /etc/iked/pubkeys/fqdn/)
It doesn't mind them being absent anymore though.

- Igor

On 4/20/17 5:44 PM, Reyk Floeter wrote:
> --- sbin/iked/parse.y 28 Mar 2017 16:56:39 -  1.64
> +++ sbin/iked/parse.y 20 Apr 2017 21:40:14 -
> @@ -1807,7 +1807,7 @@ set_policy(char *idstr, int type, struct
>  {
>   char keyfile[PATH_MAX];
>   const char  *prefix = NULL;
> - EVP_PKEY*key;
> + EVP_PKEY*key = NULL;
>  
>   switch (type) {
>   case IKEV2_ID_IPV4:
> @@ -1822,6 +1822,9 @@ set_policy(char *idstr, int type, struct
>   case IKEV2_ID_UFQDN:
>   prefix = "ufqdn";
>   break;
> + case IKEV2_ID_ASN1_DN:
> + /* public key authentication is not supported with ASN.1 IDs */
> + goto done;
>   default:
>   /* Unspecified ID or public key not supported for this type */
>   log_debug("%s: unknown type = %d", __func__, type);
> @@ -1841,6 +1844,7 @@ set_policy(char *idstr, int type, struct
>   keyfile);
>   }
>  
> + done:
>   if (set_policy_auth_method(keyfile, key, pol) < 0) {
>   EVP_PKEY_free(key);
>   log_warnx("%s: failed to set policy auth method for %s",



iked/IKEv2 issue with 6.1

2017-04-20 Thread Igor V. Gubenko
Hello everyone,

OpenIKED just doesn't seem to like me much.

I managed to get it working around 5.8 but from upgrade to upgrade I
encountered different issues.

I have 3 tunnels using IKEv2. 2 are using a PSK, and 1 is using cert/RSA
auth.

They were working fine on 6.0. However the same configuration now fails
with 6.1 - iked refuses to start.

Config follows below:

-

local_ip = "my_ext_ip"
local_net = "172.16.0.0/20"

ikev2 "KBweb" \
active ipcomp esp \
from $local_net to 10.33.33.0/27 \
local $local_ip \
peer A.B.C.D \
ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \
childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
srcid $local_ip \
dstid a.dns.addr \
psk "some psk"


ikev2 "KBDB" \
active ipcomp esp \
from $local_net to 10.34.34.0/27 \
local $local_ip \
peer E.F.G.H \
ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \
childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
srcid $local_ip \
dstid e.dns.addr \
psk "some psk"


ikev2 "PU" \
active ipcomp esp \
from $local_net to net1/mask1 \
from $local_net to net2/mask2 \
from $local_net to 10.6.0.0/16 \
local $local_ip \
peer I.J.K.L \
ikesa auth hmac-sha2-256 enc aes-192 group modp2048 \
childsa auth hmac-sha2-256 enc aes-256 group modp2048 \
srcid "/C=US/ST=New Jersey/L=Livingston/O=some org/OU=some
dept/CN=some_cn_fqdn" \
dstid "/C=US/ST=New Jersey/L=Princeton/O=some org2/OU=some
dept2/CN=some_cn_fqdn2"

--


root@HomatEsh2 (1 jobs) /usr/src # iked -6 -d -
local_ip = "my_ext_ip"

local_net = "172.16.0.0/20"

set_policy: found pubkey for /etc/iked/pubkeys/fqdn/a.dns.addr
ikev2 "KBweb" active esp inet from 172.16.0.0/20 to 10.33.33.0/27 local
my_ext_ip peer A.B.C.D ikesa enc aes-192 prf hmac-sha2-256,hmac-sha1
auth hmac-sha2-256 group modp2048 childsa enc aes-256 auth hmac-sha2-256
group modp2048 srcid my_ext_ip dstid A.B.C.D lifetime 10800 bytes
536870912 psk 0xlong_hex_num
set_policy: found pubkey for /etc/iked/pubkeys/fqdn/e.dns.addr
ikev2 "KBDB" active esp inet from 172.16.0.0/20 to 10.34.34.0/27 local
my_ext_ip peer E.F.G.H ikesa enc aes-192 prf hmac-sha2-256,hmac-sha1
auth hmac-sha2-256 group modp2048 childsa enc aes-256 auth hmac-sha2-256
group modp2048 srcid my_ext_ip dstid E.F.G.H lifetime 10800 bytes
536870912 psk 0xlong_hex_num
set_policy: unknown type = 9
create_ike: set_policy failed
/etc/iked.conf: 39: create_ike failed
/etc/iked.conf: loaded 2 configuration rules
ca exiting, pid 5607
ikev2 exiting, pid 80211
control exiting, pid 62559

So it seems to fail on parsing or using the x50? cert notation, which
still works on my primary 6.0 machine.


Thank you for any help,

- Igor




Re: two ip with carp

2017-02-28 Thread Igor V. Gubenko
Much clearer.

I've never tried CARP on an alias, but it should probably work.

However, I don't think that it can be an existing carp* interface. Use
carp3; i.e a different carp interface. Create "inet alias" in the .bnx0
file, and a new .carpX file with a different "vhid" (different from carp2).

On a side note, I've found out that the physical interfaces on WAN do
not necessarily need to have actual WAN (globally routed) IP's. So, if
you are low on globally routed IP's, you can try using RFC1918 IP's on
bnx0 (and it's aliases for DMZ). These IP's are merely needed to send
multicast for CARP.

If any of the esteemed OpenBSD developers want to call BS on the above,
please, have a go :)

Please let us know of the results.

- Igor


On 2/28/17 10:01 AM, Frank White wrote:
> ok.. I'll try.
> I use the google dns ip as example for my static public ip address.
> fw1 carp0 8.8.8.8  ## (internet shared ip <--  lan)
> fw1 carp1 192.168.1.1  ## (lan shared ip default gw)
> fw1 carp2 10.1.1.1  ## (dmz shared ip)
> fw1 bnx0 8.8.8.7  ## (internet)
> fw1 bge0 192.168.1.2  ## (lan)
> fw1 bnx1 10.1.1.2  ## (dmz)
> fw1 bge1 192.168.254.1 ## (pfsync)
>
> fw2 carp0 8.8.8.8
> fw2 carp1 192.168.1.1
> fw2 carp2 10.1.1.1
> fw2 bnx0 8.8.8.6
> fw2 bge0 192.168.1.3
> fw2 bnx1 10.1.1.3
> fw2 bge1 192.168.1.254.2 # (pfsync)
>
> Now I want add 8.8.8.10 static and public ip to flow the traffic to
> the dmz because 8.8.8.8 flow traffic to the lan.
> As I understand I have to add the following lines to IF configuration
> files:
>
> fw1 hostname.carp0:  inet alias 8.8.8.10 255.255.255.255. NONE
> fw1 hostname.bnx0: inet alias 8.8.8.11 255.255.255.255 NONE
>
> fw2 hostname.carp0:  inet alias 8.8.8.10 255.255.255.255. NONE
> fw2 hostname.bnx0: inet alias 8.8.8.12 255.255.255.255 NONE
>
> is that right ?
>
>
> 2017-02-28 15:07 GMT+01:00 Igor V. Gubenko <i...@gubenko.com
> <mailto:i...@gubenko.com>>:
>
> It's not completely clear -
>
> 4) - is the IP 10.1.1.2 on a separate interface? What did you
> configure
> carp2 on?
>
> Can you restate your question and/or describe how you want the traffic
> to flow, as well as your network topology?
>
> - Igor
>
>
> On 2/27/17 6:07 AM, Frank White wrote:
> > hi,
> > I have 2 firewall in cluster with carp. The following is my
> configuration
> > (8.x.x.x are examples for wan ip):
> > first firewall
> > 1) bnx0 8.8.8.7 (internet)
> > 2) bge0 192.168.100.2 (lan)
> > 3) bnx1 pfsync
> > 4) 10.1.1.2 dmz
> >
> > carp0 8.8.8.8 (internet)
> > carp1 192.168.100.1 (gateway for the lan)
> > carp2 10.1.1.1 (gateway for the dmz)
> >
> > now I want add the ip 8.8.8.10 to redirect all traffic from it
> to the dmz...
> > how should I configure it ?
> > I know how to redirect the traffic with pf.. my question concern
> how to
> > configure carp and the nic..
> > for example should I create a new carp with ip 8.8.8.10 and an
> alias for
> > the bnx0 with ip 8.8.8.11 ?



Re: two ip with carp

2017-02-28 Thread Igor V. Gubenko
It's not completely clear -

4) - is the IP 10.1.1.2 on a separate interface? What did you configure
carp2 on?

Can you restate your question and/or describe how you want the traffic
to flow, as well as your network topology?

- Igor


On 2/27/17 6:07 AM, Frank White wrote:
> hi,
> I have 2 firewall in cluster with carp. The following is my configuration
> (8.x.x.x are examples for wan ip):
> first firewall
> 1) bnx0 8.8.8.7 (internet)
> 2) bge0 192.168.100.2 (lan)
> 3) bnx1 pfsync
> 4) 10.1.1.2 dmz
>
> carp0 8.8.8.8 (internet)
> carp1 192.168.100.1 (gateway for the lan)
> carp2 10.1.1.1 (gateway for the dmz)
>
> now I want add the ip 8.8.8.10 to redirect all traffic from it to the dmz...
> how should I configure it ?
> I know how to redirect the traffic with pf.. my question concern how to
> configure carp and the nic..
> for example should I create a new carp with ip 8.8.8.10 and an alias for
> the bnx0 with ip 8.8.8.11 ?