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
> >
> > 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
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
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
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
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
> > >
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
> > >
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
>
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
>
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
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
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
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/
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
14 matches
Mail list logo
