Support for the enc(4) pseudo-interface

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for the enc(4) pseudo-interface

lists-5
Hi all,

I've just set up IPsec between two FreeBSD 11-RELEASE hosts with security/openiked.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

lists-5
Sorry for the noise: the webmail ate my message. Here is the full version:

Hi all,

I set up IPsec between several FreeBSD 11-RELEASE hosts. IKEv2 is managed by
security/openiked.

I use pf to filter the traffic, and the rulesets include several references
to the enc0 pseudo-interface, which allow inbound traffic filtering
*after* IPsec decryption. So far, the whole configuration works fine.

I noticed that the enc0 pseudo-interface was not shown in the output of the
`ifconfig` command, whereas it is on OpenBSD. AFAIK, the GENERIC kernel
does not include the enc pseudo-device, since I could not fine a "device
enc" line in the kernel config file. The lack of such adevice would
explain why it is not manageable as a network interface, and why  
`ifconfig enc0 create` fails.

Yet, it appears that pf is able to handle references to enc(4) in its ruleset
even if the kernel does not support it. Is it expected behaviour? Is it
safe to use such a configuration on a production machine ?

Thanks,

Marin.

20 mars 2017 14:20 "Marin Bernard"  a écrit:

>  Hi all,
>  
>  I've just set up IPsec between two FreeBSD 11-RELEASE hosts with security/openiked.
>  
>  
>  _______________________________________________
>  [hidden email] mailing list
>  https://lists.freebsd.org/mailman/listinfo/freebsd-pf 
>  To unsubscribe, send any mail to "[hidden email]"
>  



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Kristof Provost-3
On 20 Mar 2017, at 23:08, Marin Bernard wrote:
> Yet, it appears that pf is able to handle references to enc(4) in its
> ruleset
> even if the kernel does not support it. Is it expected behaviour? Is
> it
> safe to use such a configuration on a production machine ?
>
pf accepts rules for interfaces that don’t exist (yet), so this is
expected,
but it won’t do what you want it to do.

Regards,
Kristof
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

lists-5
In reply to this post by lists-5
Hi,

Thanks for answering. Yes, I know that pf accepts rules mentioning inexistent
interfaces. What puzzles me here is that my ruleset is actually working.
With peer0 = 1.2.3.4 and peer1 = 5.6.7.8, the following ruleset works as
expected:

-----
peers = "{1.2.3.4, 5.6.7.8}"

set skip on lo
block all

# Allow IKE
pass  in proto {tcp, udp} from $peers to self   port isakmp
pass out proto {tcp, udp} from self   to $peers port isakmp

# Allow ICMPv4 echo requests only through IPsec
pass in on enc0 proto icmp from $peers to self icmp-type echoreq
-----

If there is no SA, it is impossible for a peer to ping another. As soon
as IKE creates a SA, however, ping starts working. As you can see,
the last rule is explicitely bound to the inexistent enc0 interface, and
yet is working fine.

Thanks,

Marin.

21 mars 2017 03:30 "Kristof Provost"  a écrit:

>  On 20 Mar 2017, at 23:08, Marin Bernard wrote:
>  > Yet, it appears that pf is able to handle references to enc(4) in its
>  > ruleset
>  > even if the kernel does not support it. Is it expected behaviour? Is
>  > it
>  > safe to use such a configuration on a production machine ?
>  >
>  pf accepts rules for interfaces that don’t exist (yet), so this is
>  expected,
>  but it won’t do what you want it to do.
>
>  Regards,
>  Kristof



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Kristof Provost-3
On 21 Mar 2017, at 9:43, Marin Bernard wrote:

> Thanks for answering. Yes, I know that pf accepts rules mentioning
> inexistent
> interfaces. What puzzles me here is that my ruleset is actually
> working.
> With peer0 = 1.2.3.4 and peer1 = 5.6.7.8, the following ruleset works
> as
> expected:
>
> -----
> peers = "{1.2.3.4, 5.6.7.8}"
>
> set skip on lo
> block all
>
> # Allow IKE
> pass  in proto {tcp, udp} from $peers to self   port isakmp
> pass out proto {tcp, udp} from self   to $peers port isakmp
>
> # Allow ICMPv4 echo requests only through IPsec
> pass in on enc0 proto icmp from $peers to self icmp-type echoreq
> -----
>
> If there is no SA, it is impossible for a peer to ping another. As
> soon
> as IKE creates a SA, however, ping starts working. As you can see,
> the last rule is explicitely bound to the inexistent enc0 interface,
> and
> yet is working fine.
>
Can you try without the enc0 rule? I suspect that what’s happening
here is that
the IPSec traffic is bypassing the firewall altogether. If that's the
case the
your traffic will still flow, even without the pass on enc0 rule.

If you want to filter on it it should work if you add ‘device enc’
to your
kernel config. The man page suggests that should then allow you to
filter IPSec
traffic on enc0.

Regards,
Kristof
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

lists-5
In reply to this post by lists-5
Hi again Kristof,

It appears you were right. ICMP flows through even with no rule set. I'm afraid
I'll have to build a custom kernel.

Thank you for your help,

Marin.

21 mars 2017 10:18 "Kristof Provost"  a écrit:

>  On 21 Mar 2017, at 9:43, Marin Bernard wrote:
>  > Thanks for answering. Yes, I know that pf accepts rules mentioning
>  > inexistent
>  > interfaces. What puzzles me here is that my ruleset is actually
>  > working.
>  > With peer0 = 1.2.3.4 and peer1 = 5.6.7.8, the following ruleset works
>  > as
>  > expected:
>  >
>  > -----
>  > peers = "{1.2.3.4, 5.6.7.8}"
>  >
>  > set skip on lo
>  > block all
>  >
>  > # Allow IKE
>  > pass  in proto {tcp, udp} from $peers to self   port isakmp
>  > pass out proto {tcp, udp} from self   to $peers port isakmp
>  >
>  > # Allow ICMPv4 echo requests only through IPsec
>  > pass in on enc0 proto icmp from $peers to self icmp-type echoreq
>  > -----
>  >
>  > If there is no SA, it is impossible for a peer to ping another. As
>  > soon
>  > as IKE creates a SA, however, ping starts working. As you can see,
>  > the last rule is explicitely bound to the inexistent enc0 interface,
>  > and
>  > yet is working fine.
>  >
>  Can you try without the enc0 rule? I suspect that what’s happening
>  here is that
>  the IPSec traffic is bypassing the firewall altogether. If that's the
>  case the
>  your traffic will still flow, even without the pass on enc0 rule.
>  
>  If you want to filter on it it should work if you add ‘device enc’
>  to your
>  kernel config. The man page suggests that should then allow you to
>  filter IPSec
>  traffic on enc0.
>  
>  Regards,
>  Kristof



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Miroslav Lachman
In reply to this post by Kristof Provost-3
Kristof Provost wrote on 2017/03/21 10:18:
> On 21 Mar 2017, at 9:43, Marin Bernard wrote:

>> If there is no SA, it is impossible for a peer to ping another. As soon
>> as IKE creates a SA, however, ping starts working. As you can see,
>> the last rule is explicitely bound to the inexistent enc0 interface, and
>> yet is working fine.
>>
> Can you try without the enc0 rule? I suspect that what’s happening here
> is that
> the IPSec traffic is bypassing the firewall altogether. If that's the
> case the
> your traffic will still flow, even without the pass on enc0 rule.
>
> If you want to filter on it it should work if you add ‘device enc’ to your
> kernel config. The man page suggests that should then allow you to
> filter IPSec
> traffic on enc0.

Shouldn't it be included in GENERIC if IPSec is now part of it? It seems
illogical to build own kernel for IPsec if IPSec was included in GENERIC
for 11.0 ... but without enc.

Miroslav Lachman
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Kurt Jaeger-14
Hi!

> > If you want to filter on it it should work if you add ???device enc??? to your
> > kernel config. The man page suggests that should then allow you to
> > filter IPSec
> > traffic on enc0.
>
> Shouldn't it be included in GENERIC if IPSec is now part of it?

Yes, please include enc in the GENERIC kernel.

--
[hidden email]            +49 171 3101372                         3 years to go !
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Bjoern A. Zeeb
On 21 Mar 2017, at 11:46, Kurt Jaeger wrote:

> Hi!
>
>>> If you want to filter on it it should work if you add ???device
>>> enc??? to your
>>> kernel config. The man page suggests that should then allow you to
>>> filter IPSec
>>> traffic on enc0.
>>
>> Shouldn't it be included in GENERIC if IPSec is now part of it?
>
> Yes, please include enc in the GENERIC kernel.

I thought the entire idea of making ipsec loadable was that we don’t
have to ship it in the kernel and have it available?

/bz
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Kurt Jaeger-14
Hi!

> >> Shouldn't it be included in GENERIC if IPSec is now part of it?

> > Yes, please include enc in the GENERIC kernel.

> I thought the entire idea of making ipsec loadable was that we don???t
> have to ship it in the kernel and have it available?

You are right. kldload if_enc seems to work on 12a and 11a. So
ignore my plea for enc in GENERIC 8-}

--
[hidden email]            +49 171 3101372                         3 years to go !
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Miroslav Lachman
In reply to this post by Bjoern A. Zeeb
Bjoern A. Zeeb wrote on 2017/03/21 12:56:

> On 21 Mar 2017, at 11:46, Kurt Jaeger wrote:
>
>> Hi!
>>
>>>> If you want to filter on it it should work if you add ???device
>>>> enc??? to your
>>>> kernel config. The man page suggests that should then allow you to
>>>> filter IPSec
>>>> traffic on enc0.
>>>
>>> Shouldn't it be included in GENERIC if IPSec is now part of it?
>>
>> Yes, please include enc in the GENERIC kernel.
>
> I thought the entire idea of making ipsec loadable was that we don’t
> have to ship it in the kernel and have it available?

Then sorry for the noise.

Miroslav Lachman
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Kristof Provost-3
In reply to this post by Miroslav Lachman
On 21 Mar 2017, at 12:44, Miroslav Lachman wrote:

> Kristof Provost wrote on 2017/03/21 10:18:
>> On 21 Mar 2017, at 9:43, Marin Bernard wrote:
>
>>> If there is no SA, it is impossible for a peer to ping another. As
>>> soon
>>> as IKE creates a SA, however, ping starts working. As you can see,
>>> the last rule is explicitely bound to the inexistent enc0 interface,
>>> and
>>> yet is working fine.
>>>
>> Can you try without the enc0 rule? I suspect that what’s happening
>> here
>> is that
>> the IPSec traffic is bypassing the firewall altogether. If that's the
>> case the
>> your traffic will still flow, even without the pass on enc0 rule.
>>
>> If you want to filter on it it should work if you add ‘device
>> enc’ to your
>> kernel config. The man page suggests that should then allow you to
>> filter IPSec
>> traffic on enc0.
>
> Shouldn't it be included in GENERIC if IPSec is now part of it? It
> seems
> illogical to build own kernel for IPsec if IPSec was included in
> GENERIC for
> 11.0 ... but without enc.
>
Yeah, perhaps it should be.

I’ve not used it myself, so I don’t know if/how well it works now,
but unless
it breaks things or introduces significant performance regressions we
should
probably turn it on too.

Martin, could you give us an idea of how well this works for you when
you’ve
got the time to set it up?

Regards,
Kristof
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Bjoern A. Zeeb
In reply to this post by Miroslav Lachman
On 21 Mar 2017, at 12:12, Miroslav Lachman wrote:

> Bjoern A. Zeeb wrote on 2017/03/21 12:56:
>> On 21 Mar 2017, at 11:46, Kurt Jaeger wrote:
>>
>>> Hi!
>>>
>>>>> If you want to filter on it it should work if you add ???device
>>>>> enc??? to your
>>>>> kernel config. The man page suggests that should then allow you to
>>>>> filter IPSec
>>>>> traffic on enc0.
>>>>
>>>> Shouldn't it be included in GENERIC if IPSec is now part of it?
>>>
>>> Yes, please include enc in the GENERIC kernel.
>>
>> I thought the entire idea of making ipsec loadable was that we don’t
>> have to ship it in the kernel and have it available?
>
> Then sorry for the noise.

well, it was a question;  Cc:ing ae@

/bz
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Andrey V. Elsukov
On 21.03.2017 16:23, Bjoern A. Zeeb wrote:

> On 21 Mar 2017, at 12:12, Miroslav Lachman wrote:
>
>> Bjoern A. Zeeb wrote on 2017/03/21 12:56:
>>> On 21 Mar 2017, at 11:46, Kurt Jaeger wrote:
>>>
>>>> Hi!
>>>>
>>>>>> If you want to filter on it it should work if you add ???device
>>>>>> enc??? to your
>>>>>> kernel config. The man page suggests that should then allow you to
>>>>>> filter IPSec
>>>>>> traffic on enc0.
>>>>>
>>>>> Shouldn't it be included in GENERIC if IPSec is now part of it?
>>>>
>>>> Yes, please include enc in the GENERIC kernel.
>>>
>>> I thought the entire idea of making ipsec loadable was that we don’t
>>> have to ship it in the kernel and have it available?
>>
>> Then sorry for the noise.
>
> well, it was a question;  Cc:ing ae@
if_enc(4) was made loadable a more than 15 months ago. I don't see the
need to add it into GENERIC.

--
WBR, Andrey V. Elsukov


signature.asc (565 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

lists-5
In reply to this post by lists-5
Hi,

I just got it working. Here is what I have done:

- Loaded the kernel module:

    # kldload if_enc

- Set the interface up:

    # ifconfig enc0 up

- Tweaked sysctl to enable tunnel filtering. Default value is 0 and
makes IPsec-related traffic bypass the firewall:

    # sysctl net.inet.ipsec.filtertunnel = 1

- Tweaked sysctl to configure the enc(4) device. According to the man
page, the mechanism used by enc(4) to inject packets into packet filters
is configurable with two sysctl values, one for each direction. Default
values are:

    # sysctl net.enc.out.ipsec_filter_mask
    1

    # sysctl net.enc.in.ipsec_filter_mask
    1
    
The default value of the second sysctl leads enc(4) devices to pass
encrypted traffic to packet filters. As suggested by the man page, I had
to set this sysctl to the recommended value of 2 to make enc(4) inject
decrypted packets instead:

    # sysctl net.enc.in.ipsec_filter_mask = 2

By the way, I still do not understand why the default value of this
sysctl is different from the suggested one.

- I modified the pf ruleset to add a rule for outbound traffic on enc0:

    # cat /etc/pf.conf
    peers = "{1.2.3.4, 5.6.7.8}"

    set skip on lo
    block all

    # Allow IKE
    pass  in proto {tcp, udp} from $peers to self   port isakmp
    pass out proto {tcp, udp} from self   to $peers port isakmp

    # Allow ICMPv4 echo requests only through IPsec
    pass  in on enc0 proto icmp from $peers to self   icmp-type echoreq
    pass out on enc0 proto icmp from self   to $peers icmp-type echoreq

IPsec filtering seems to work fine with this config. I can confirm that
ICMP traffic is encrypted. Furthermore, removing the last rules actually
blocks echo requests, which is what is expected.

Thanks for your help and for letting me know that the enc was available
as a kernel module!

Marin.

21 mars 2017 13:22 "Kristof Provost"  a écrit:

>  On 21 Mar 2017, at 12:44, Miroslav Lachman wrote:
>  > Kristof Provost wrote on 2017/03/21 10:18:
>  >> On 21 Mar 2017, at 9:43, Marin Bernard wrote:
>  >
>  >>> If there is no SA, it is impossible for a peer to ping another. As
>  >>> soon
>  >>> as IKE creates a SA, however, ping starts working. As you can see,
>  >>> the last rule is explicitely bound to the inexistent enc0 interface,
>  >>> and
>  >>> yet is working fine.
>  >>>
>  >> Can you try without the enc0 rule? I suspect that what’s happening
>  >> here
>  >> is that
>  >> the IPSec traffic is bypassing the firewall altogether. If that's the
>  >> case the
>  >> your traffic will still flow, even without the pass on enc0 rule.
>  >>
>  >> If you want to filter on it it should work if you add ‘device
>  >> enc’ to your
>  >> kernel config. The man page suggests that should then allow you to
>  >> filter IPSec
>  >> traffic on enc0.
>  >
>  > Shouldn't it be included in GENERIC if IPSec is now part of it? It
>  > seems
>  > illogical to build own kernel for IPsec if IPSec was included in
>  > GENERIC for
>  > 11.0 ... but without enc.
>  >
>  Yeah, perhaps it should be.
>  
>  I’ve not used it myself, so I don’t know if/how well it works now,
>  but unless
>  it breaks things or introduces significant performance regressions we
>  should
>  probably turn it on too.
>  
>  Martin, could you give us an idea of how well this works for you when
>  you’ve
>  got the time to set it up?
>  
>  Regards,
>  Kristof



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for the enc(4) pseudo-interface

Andrey V. Elsukov
In reply to this post by Bjoern A. Zeeb
On 21.03.2017 16:23, Bjoern A. Zeeb wrote:
> On 21 Mar 2017, at 12:12, Miroslav Lachman wrote:
>
>> Bjoern A. Zeeb wrote on 2017/03/21
>>> I thought the entire idea of making ipsec loadable was that we don’t
>>> have to ship it in the kernel and have it available?
>>
>> Then sorry for the noise.
>
> well, it was a question;  Cc:ing ae@

It seems the presence in the kernel another enc driver

cam/scsi/scsi_enc.c:PERIPHDRIVER_DECLARE(enc, encdriver);

prevents to automatic if_enc module loading when `ifconfig enc0 create`
is invoked.

--
WBR, Andrey V. Elsukov


signature.asc (565 bytes) Download Attachment
Loading...