Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 10:06:49PM +0100, Tobias Heider wrote: > Try this This makes iked use the reverse record of the FQDN's IP (which IP?). I have peers with both IPv4 and IPv6 addreses, one of those peers has an incorrect reverse record, thus iked will not end up using the FQDN I used as `peer ...' but rather the FQDN it gets after name resolution back and forth. For peers with proper DNS in both ways this diff yields the correct `dstid' without explicitly specifying it, but that is not the right approach; iked should simply copy over the value from `peer' to `dstid' as is.
Re: iked.conf.5: Provide GRE tunnel in transport mode example
> >
> > We should rather fix the defaults to do what we expect them to do.
> > In your example case that would be using fqdn/D.example.com
> Agreed; do you take a stab at it? I'm happy to test.
>
Try this
Index: parse.y
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/parse.y,v
retrieving revision 1.89
diff -u -p -r1.89 parse.y
--- parse.y 21 Feb 2020 15:17:34 - 1.89
+++ parse.y 22 Feb 2020 21:04:16 -
@@ -1962,6 +1962,11 @@ set_policy(char *idstr, int type, struct
const char *prefix = NULL;
EVP_PKEY*key = NULL;
+ if (idstr == NULL) {
+ log_warnx("%s: can not set empty ID.", __func__);
+ return (-1);
+ }
+
switch (type) {
case IKEV2_ID_IPV4:
prefix = "ipv4";
@@ -2112,7 +2117,7 @@ host_dns(const char *s, int mask)
err(1, "%s", __func__);
copy_sockaddrtoipa(ipa, res->ai_addr);
error = getnameinfo(res->ai_addr, res->ai_addrlen, hbuf,
- sizeof(hbuf), NULL, 0, NI_NUMERICHOST);
+ sizeof(hbuf), NULL, 0, 0);
if (error)
err(1, "host_dns: getnameinfo");
ipa->name = strdup(hbuf);
@@ -2798,6 +2803,10 @@ create_ike(char *name, int af, uint8_t i
pol.pol_peer.addr_net = ipb->netaddress;
if (pol.pol_af == AF_UNSPEC)
pol.pol_af = ipb->af;
+ if (ipb->name) {
+ strlcpy(idstr, ipb->name, sizeof(idstr));
+ idtype = get_id_type(ipb->name);
+ }
}
if (ikelifetime)
@@ -2984,20 +2993,6 @@ create_ike(char *name, int af, uint8_t i
if (dstid) {
strlcpy(idstr, dstid, sizeof(idstr));
idtype = pol.pol_peerid.id_type;
- } else if (!pol.pol_peer.addr_net) {
- print_host((struct sockaddr *)_peer.addr, idstr,
- sizeof(idstr));
- switch (pol.pol_peer.addr.ss_family) {
- case AF_INET:
- idtype = IKEV2_ID_IPV4;
- break;
- case AF_INET6:
- idtype = IKEV2_ID_IPV6;
- break;
- default:
- log_warnx("%s: unknown address family", __func__);
- break;
- }
}
/* Make sure that we know how to authenticate this peer */
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 02:33:17PM +0100, Tobias Heider wrote: > Peer can not be "any" in an active policy, somehow the initiator must know > where to send the messages. In this case the default currently is what I've > described before: the IP of peer. But in `passive' policies which is the default unless `active' is specified explicitly; the manual already makes use of `peer any' in the EXAMPLES section. > In a passive policy the key is only needed when > the peer's ID has been exchanged in the IKE_AUTH message, > so (I think) the default is to use whatever ID was received. That does not match the manual wording, then. > I think this works pretty well in 90% of the cases and I've always been a > fan of a short default configuration, so i don't think requiring to > set dstid is a good idea. > > We should rather fix the defaults to do what we expect them to do. > In your example case that would be using fqdn/D.example.com Agreed; do you take a stab at it? I'm happy to test.
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 01:47:35PM +0100, Klemens Nanni wrote: > On Sat, Feb 22, 2020 at 01:18:13PM +0100, Tobias Heider wrote: > > It seems I was mistaken because I usually use IPs in local > > and peer. What I said is true for IPs. When using > > FQDNs for local/peer however, iked first does the name > > resolution and then uses the IP as default dstid value > > to lookup the key... > > > > I still think using the actual value of peer would be the > > better dstid default, so maybe we should fix it in the > > code. What do you think? > Rereading the manual: > >If srcid is omitted, the default is to use the hostname of the >local machine, see hostname(1) to set or print the hostname. > >dstid is similar to srcid, but instead specifies the ID to be used >by the remote peer. > k > So `srcid' is a string (hostname), but what does `dstid' default to? > `peer' can be "any": what then? > > About `peer', the manual says > >[...]. If it is not specified or if the keyword any is >given, the default peer is used. > > What is "the default peer"? No idea what the default peer is supposed to mean. > I'd expect `dstid' to always use the literal value of `peer' unless it > is "any", in which case I am not sure; perhaps require `dstid' to be > set explicitly? Peer can not be "any" in an active policy, somehow the initiator must know where to send the messages. In this case the default currently is what I've described before: the IP of peer. In a passive policy the key is only needed when the peer's ID has been exchanged in the IKE_AUTH message, so (I think) the default is to use whatever ID was received. I think this works pretty well in 90% of the cases and I've always been a fan of a short default configuration, so i don't think requiring to set dstid is a good idea. We should rather fix the defaults to do what we expect them to do. In your example case that would be using fqdn/D.example.com
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 01:18:13PM +0100, Tobias Heider wrote: > It seems I was mistaken because I usually use IPs in local > and peer. What I said is true for IPs. When using > FQDNs for local/peer however, iked first does the name > resolution and then uses the IP as default dstid value > to lookup the key... > > I still think using the actual value of peer would be the > better dstid default, so maybe we should fix it in the > code. What do you think? Rereading the manual: If srcid is omitted, the default is to use the hostname of the local machine, see hostname(1) to set or print the hostname. dstid is similar to srcid, but instead specifies the ID to be used by the remote peer. k So `srcid' is a string (hostname), but what does `dstid' default to? `peer' can be "any": what then? About `peer', the manual says [...]. If it is not specified or if the keyword any is given, the default peer is used. What is "the default peer"? I'd expect `dstid' to always use the literal value of `peer' unless it is "any", in which case I am not sure; perhaps require `dstid' to be set explicitly?
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 12:50:27PM +0100, Klemens Nanni wrote: > On Sat, Feb 22, 2020 at 12:24:36PM +0100, Klemens Nanni wrote: > > On Sat, Feb 22, 2020 at 10:19:27AM +0100, Tobias Heider wrote: > > > This is not what dstid does. When setting 'dstid D.example.com' the > > > policy still > > > only applies if the peer sends 'D.example.com' as it's identity in the ID > > > payload. > > > Not setting dstid explicitly means iked will fall back to the value of > > > "peer", > > > which in your case would be the same: "D.example.com". > > > > > > Setting dstid is only necessary if you are using the IP address in the > > > "peer" option but still want to use a FQDN as ID, which is really only the > > > case with certificate authentication where the ID must match the > > > subjectAltName. > > I can double check yet again, but I'm pretty sure that setting dstid > > was what made iked find the public key. So far, I have not used literal > > IPs in my configuration - that I know for sure. > Here is an example, you can verify what I observed by merely parsing > the configuration with and without the `dstitd' line. > > # find /etc/iked/pubkeys/ ! -type d -ls > 1044254 -rw-r--r--1 root wheel 800 Feb 10 19:36 > /etc/iked/pubkeys/fqdn/D.example.com > > # cat /etc/iked.conf > ikesa transport \ > proto gre > from A.example.com to D.example.com \ > peer D.example.com \ > dstid D.example.com > # iked -dnv > ikev2 "policy1" passive transport esp proto gre inet6 from 1.2.3.4 to > 5.6.7.8 from 2001::db8:1 to 2001::db8:2 local any peer 2001::db8:2 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 esn,noesn dstid > D.example.com lifetime 10800 bytes 536870912 rsa > configuration OK > > # cat /etc/iked.conf > ikesa transport \ > proto gre > from A.example.com to D.example.com \ > peer D.example.com > # iked -dnv > set_policy: could not find pubkey for /etc/iked/pubkeys/ipv6/2001::db8:2 > ikev2 "policy1" passive transport esp proto gre inet6 from 1.2.3.4 to > 5.6.7.8 from 2001::db8:1 to 2001::db8:2 local any peer 2001::db8:2 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 esn,noesn lifetime 10800 > bytes 536870912 rfc7427 > configuration OK > > So my proposed wording is misleading or rather wrong since I did not > set `dstid' due to whatever the peer sends but rather because iked is > not able to find the corresponding public key in the first place. > It seems I was mistaken because I usually use IPs in local and peer. What I said is true for IPs. When using FQDNs for local/peer however, iked first does the name resolution and then uses the IP as default dstid value to lookup the key... I still think using the actual value of peer would be the better dstid default, so maybe we should fix it in the code. What do you think?
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 12:41:12PM +0100, Landry Breuil wrote: > On Sat, Feb 22, 2020 at 12:24:36PM +0100, Klemens Nanni wrote: > > On Sat, Feb 22, 2020 at 10:19:27AM +0100, Tobias Heider wrote: > > > This is not what dstid does. When setting 'dstid D.example.com' the > > > policy still > > > only applies if the peer sends 'D.example.com' as it's identity in the ID > > > payload. > > > Not setting dstid explicitly means iked will fall back to the value of > > > "peer", > > > which in your case would be the same: "D.example.com". > > > > > > Setting dstid is only necessary if you are using the IP address in the > > > "peer" option but still want to use a FQDN as ID, which is really only the > > > case with certificate authentication where the ID must match the > > > subjectAltName. > > I can double check yet again, but I'm pretty sure that setting dstid > > was what made iked find the public key. So far, I have not used literal > > IPs in my configuration - that I know for sure. > > that was also my experience when working on faq17, srcid/dstid were used > to lookup the cert/key in /etc/iked... They are indeed used for the lookup. But IIRC iked should use the value of peer as dstid by default, so setting both to the same value should not be necessary.
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 12:24:36PM +0100, Klemens Nanni wrote: > On Sat, Feb 22, 2020 at 10:19:27AM +0100, Tobias Heider wrote: > > This is not what dstid does. When setting 'dstid D.example.com' the policy > > still > > only applies if the peer sends 'D.example.com' as it's identity in the ID > > payload. > > Not setting dstid explicitly means iked will fall back to the value of > > "peer", > > which in your case would be the same: "D.example.com". > > > > Setting dstid is only necessary if you are using the IP address in the > > "peer" option but still want to use a FQDN as ID, which is really only the > > case with certificate authentication where the ID must match the > > subjectAltName. > I can double check yet again, but I'm pretty sure that setting dstid > was what made iked find the public key. So far, I have not used literal > IPs in my configuration - that I know for sure. Here is an example, you can verify what I observed by merely parsing the configuration with and without the `dstitd' line. # find /etc/iked/pubkeys/ ! -type d -ls 1044254 -rw-r--r--1 root wheel 800 Feb 10 19:36 /etc/iked/pubkeys/fqdn/D.example.com # cat /etc/iked.conf ikesa transport \ proto gre from A.example.com to D.example.com \ peer D.example.com \ dstid D.example.com # iked -dnv ikev2 "policy1" passive transport esp proto gre inet6 from 1.2.3.4 to 5.6.7.8 from 2001::db8:1 to 2001::db8:2 local any peer 2001::db8:2 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 esn,noesn dstid D.example.com lifetime 10800 bytes 536870912 rsa configuration OK # cat /etc/iked.conf ikesa transport \ proto gre from A.example.com to D.example.com \ peer D.example.com # iked -dnv set_policy: could not find pubkey for /etc/iked/pubkeys/ipv6/2001::db8:2 ikev2 "policy1" passive transport esp proto gre inet6 from 1.2.3.4 to 5.6.7.8 from 2001::db8:1 to 2001::db8:2 local any peer 2001::db8:2 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 esn,noesn lifetime 10800 bytes 536870912 rfc7427 configuration OK So my proposed wording is misleading or rather wrong since I did not set `dstid' due to whatever the peer sends but rather because iked is not able to find the corresponding public key in the first place.
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 12:24:36PM +0100, Klemens Nanni wrote: > On Sat, Feb 22, 2020 at 10:19:27AM +0100, Tobias Heider wrote: > > This is not what dstid does. When setting 'dstid D.example.com' the policy > > still > > only applies if the peer sends 'D.example.com' as it's identity in the ID > > payload. > > Not setting dstid explicitly means iked will fall back to the value of > > "peer", > > which in your case would be the same: "D.example.com". > > > > Setting dstid is only necessary if you are using the IP address in the > > "peer" option but still want to use a FQDN as ID, which is really only the > > case with certificate authentication where the ID must match the > > subjectAltName. > I can double check yet again, but I'm pretty sure that setting dstid > was what made iked find the public key. So far, I have not used literal > IPs in my configuration - that I know for sure. that was also my experience when working on faq17, srcid/dstid were used to lookup the cert/key in /etc/iked...
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 10:19:27AM +0100, Tobias Heider wrote: > This is not what dstid does. When setting 'dstid D.example.com' the policy > still > only applies if the peer sends 'D.example.com' as it's identity in the ID > payload. > Not setting dstid explicitly means iked will fall back to the value of "peer", > which in your case would be the same: "D.example.com". > > Setting dstid is only necessary if you are using the IP address in the > "peer" option but still want to use a FQDN as ID, which is really only the > case with certificate authentication where the ID must match the > subjectAltName. I can double check yet again, but I'm pretty sure that setting dstid was what made iked find the public key. So far, I have not used literal IPs in my configuration - that I know for sure. Will test and verify before committing anything.
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 12:26:01AM +0100, Klemens Nanni wrote: > On Fri, Feb 21, 2020 at 10:28:50PM +, Jason McIntyre wrote: > > it should be "a gre tunnel", not "an" > Sure, leftover from previous wording/reshuffling. > > > > +.Xr gre 4 > > > +tunnel from the local machine A to peer D using FQDN based public key > > > > probably s/the local machine A/local machine A/ (as you do for peer D) > > maybe "FQDN-based", since similar instances exist in this page: > Both reads better, thanks. > > > you should try to not split a sentence with a comma. if it's a list you > > can do: > I went with a semicolon. > > > OK? I have a comment about the use of dstid inline, otherwise I think it's great you thought of documenting this use case. Thanks! > Index: iked.conf.5 > === > RCS file: /cvs/src/sbin/iked/iked.conf.5,v > retrieving revision 1.63 > diff -u -p -r1.63 iked.conf.5 > --- iked.conf.5 21 Feb 2020 15:17:34 - 1.63 > +++ iked.conf.5 21 Feb 2020 23:25:01 - > @@ -990,6 +990,23 @@ ikev2 "subnet" esp from 10.0.3.0/24 to 1 > 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 > .Ed > +.Pp > +This example encrypts a > +.Xr gre 4 > +tunnel from local machine A to peer D using FQDN-based public key > +authentication. > +.Ar transport > +mode is used to avoid duplicate encapsulation of GRE; > +.Ar dstid > +is set explicitly to the peer's FQDN such that its public key is looked up > even > +if the peer does not send its FQDN as peer ID: This is not what dstid does. When setting 'dstid D.example.com' the policy still only applies if the peer sends 'D.example.com' as it's identity in the ID payload. Not setting dstid explicitly means iked will fall back to the value of "peer", which in your case would be the same: "D.example.com". Setting dstid is only necessary if you are using the IP address in the "peer" option but still want to use a FQDN as ID, which is really only the case with certificate authentication where the ID must match the subjectAltName. > +.Bd -literal -offset indent > +ikev2 transport \e > + proto gre \e > + from A.example.com to D.example.com \e > + peer D.example.com \e > + dstid D.example.com > +.Ed > .Sh SEE ALSO > .Xr enc 4 , > .Xr ipsec 4 , >
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Sat, Feb 22, 2020 at 12:26:01AM +0100, Klemens Nanni wrote: > On Fri, Feb 21, 2020 at 10:28:50PM +, Jason McIntyre wrote: > > it should be "a gre tunnel", not "an" > Sure, leftover from previous wording/reshuffling. > > > > +.Xr gre 4 > > > +tunnel from the local machine A to peer D using FQDN based public key > > > > probably s/the local machine A/local machine A/ (as you do for peer D) > > maybe "FQDN-based", since similar instances exist in this page: > Both reads better, thanks. > > > you should try to not split a sentence with a comma. if it's a list you > > can do: > I went with a semicolon. > > > OK? > ok by me, yes. jmc > > Index: iked.conf.5 > === > RCS file: /cvs/src/sbin/iked/iked.conf.5,v > retrieving revision 1.63 > diff -u -p -r1.63 iked.conf.5 > --- iked.conf.5 21 Feb 2020 15:17:34 - 1.63 > +++ iked.conf.5 21 Feb 2020 23:25:01 - > @@ -990,6 +990,23 @@ ikev2 "subnet" esp from 10.0.3.0/24 to 1 > 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 > .Ed > +.Pp > +This example encrypts a > +.Xr gre 4 > +tunnel from local machine A to peer D using FQDN-based public key > +authentication. > +.Ar transport > +mode is used to avoid duplicate encapsulation of GRE; > +.Ar dstid > +is set explicitly to the peer's FQDN such that its public key is looked up > even > +if the peer does not send its FQDN as peer ID: > +.Bd -literal -offset indent > +ikev2 transport \e > + proto gre \e > + from A.example.com to D.example.com \e > + peer D.example.com \e > + dstid D.example.com > +.Ed > .Sh SEE ALSO > .Xr enc 4 , > .Xr ipsec 4 , >
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Fri, Feb 21, 2020 at 10:28:50PM +, Jason McIntyre wrote: > it should be "a gre tunnel", not "an" Sure, leftover from previous wording/reshuffling. > > +.Xr gre 4 > > +tunnel from the local machine A to peer D using FQDN based public key > > probably s/the local machine A/local machine A/ (as you do for peer D) > maybe "FQDN-based", since similar instances exist in this page: Both reads better, thanks. > you should try to not split a sentence with a comma. if it's a list you > can do: I went with a semicolon. OK? Index: iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.63 diff -u -p -r1.63 iked.conf.5 --- iked.conf.5 21 Feb 2020 15:17:34 - 1.63 +++ iked.conf.5 21 Feb 2020 23:25:01 - @@ -990,6 +990,23 @@ ikev2 "subnet" esp from 10.0.3.0/24 to 1 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 .Ed +.Pp +This example encrypts a +.Xr gre 4 +tunnel from local machine A to peer D using FQDN-based public key +authentication. +.Ar transport +mode is used to avoid duplicate encapsulation of GRE; +.Ar dstid +is set explicitly to the peer's FQDN such that its public key is looked up even +if the peer does not send its FQDN as peer ID: +.Bd -literal -offset indent +ikev2 transport \e + proto gre \e + from A.example.com to D.example.com \e + peer D.example.com \e + dstid D.example.com +.Ed .Sh SEE ALSO .Xr enc 4 , .Xr ipsec 4 ,
Re: iked.conf.5: Provide GRE tunnel in transport mode example
On Fri, Feb 21, 2020 at 11:12:24PM +0100, Klemens Nanni wrote: > tobhe recently committed transport mode support, so here's an example > that hopefully providea good starting point for users wanting to set up > encrypted tunnels. > > Feedback? OK? > hi. feedback inline. > > Index: iked.conf.5 > === > RCS file: /cvs/src/sbin/iked/iked.conf.5,v > retrieving revision 1.63 > diff -u -p -r1.63 iked.conf.5 > --- iked.conf.5 21 Feb 2020 15:17:34 - 1.63 > +++ iked.conf.5 21 Feb 2020 22:07:03 - > @@ -990,6 +990,23 @@ ikev2 "subnet" esp from 10.0.3.0/24 to 1 > 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 > .Ed > +.Pp > +This example encrypts an it should be "a gre tunnel", not "an" > +.Xr gre 4 > +tunnel from the local machine A to peer D using FQDN based public key probably s/the local machine A/local machine A/ (as you do for peer D) maybe "FQDN-based", since similar instances exist in this page: supports user-based authentication by tunneling the Extensible required to support different challenge-based EAP methods like or to support queue-based bandwidth control, authentication and additional challenge-based EAP-MSCHAPv2 password > +authentication. > +.Ar transport > +mode is used to avoid duplicate encapsulation of GRE, > +.Ar dstid > +is set explicitly to the peer's FQDN such that its public key is looked up > even > +if the peer does not send its FQDN as peer ID: you should try to not split a sentence with a comma. if it's a list you can do: one, two, and three but with two things you want a semi-colon, a joining word (to get technical), or to start a new sentence. i guess i'd go with a semi-colon in this case (it's a logical joining). > +.Bd -literal -offset indent > +ikev2 transport \e > + proto gre \e > + from A.example.com to D.example.com \e > + peer D.example.com \e > + dstid D.example.com > +.Ed > .Sh SEE ALSO > .Xr enc 4 , > .Xr ipsec 4 , > otherwise reads ok./ jmc
iked.conf.5: Provide GRE tunnel in transport mode example
tobhe recently committed transport mode support, so here's an example that hopefully providea good starting point for users wanting to set up encrypted tunnels. Feedback? OK? Index: iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.63 diff -u -p -r1.63 iked.conf.5 --- iked.conf.5 21 Feb 2020 15:17:34 - 1.63 +++ iked.conf.5 21 Feb 2020 22:07:03 - @@ -990,6 +990,23 @@ ikev2 "subnet" esp from 10.0.3.0/24 to 1 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 .Ed +.Pp +This example encrypts an +.Xr gre 4 +tunnel from the local machine A to peer D using FQDN based public key +authentication. +.Ar transport +mode is used to avoid duplicate encapsulation of GRE, +.Ar dstid +is set explicitly to the peer's FQDN such that its public key is looked up even +if the peer does not send its FQDN as peer ID: +.Bd -literal -offset indent +ikev2 transport \e + proto gre \e + from A.example.com to D.example.com \e + peer D.example.com \e + dstid D.example.com +.Ed .Sh SEE ALSO .Xr enc 4 , .Xr ipsec 4 ,
