[Swan-dev] Integrating Libreswan for IKEv2 and IPsec

[Balaji Thoguluva]

Please ignore my question in my previous email. I found that it is in
/usr/local/sbin.

Thanks,
Balaji

On Sat, May 23, 2020 at 1:23 PM Balaji Thoguluva <tbbalaji at gmail.com> wrote:

> Hi Paul,
>
> Thanks for the continued support.
>
> I have integrated Libreswan source code with my Linux-based project and
> integrated binaries of the Libreswan's dependencies and I am able to build
> the project.
>
> Can I access the ipsec executable in the built Linux project? If so, where
> does the ipsec executable typically reside? I could not find it under
> /usr/sbin, /usr/libexec/ipsec.
>
> Any suggestions.
>
> Thanks,
> Balaji
>
> On Mon, May 18, 2020 at 3:05 PM Paul Wouters <paul at nohats.ca> wrote:
>
>> On Mon, 18 May 2020, Balaji Thoguluva wrote:
>>
>> > I have some general security-policies that just allow the traffic to
>> pass through the system (i.e., no IPsec is applied to those traffic). Say
>> for example, allow all traffic
>> > of of certain source and destination IP and source and destination port
>> as 5060 (SIP traffic) not processed by IPsec.
>> >
>> > In that case, how do I convey this security-policy behavior to
>> Libreswan via the script? What parameters need to be configured? Should I
>> create a separate connection section?
>>
>> I would still recommend you do not do this. Double encryption isn't the
>> worst these days. Excluding will allow people to see things even if not
>> encrypted. For example, TLS still leaks SNI in cleartext.
>>
>> That said, you can simply create the exceptions by doing:
>>
>> Individual conn solutions:
>>
>> conn skip-tls-out
>>         left=%defaultroute
>>         right=0.0.0.0
>>         leftprotoport=tcp/0
>>         rightprotoport=tcp/443
>>         authby=never
>>         auto=route
>>
>> You would do something similar but flipped for incoming TLS. If there is
>> a mismatch of these between hosts, all communication will fail because
>> whoever does not have the "cleartext hole" will drop the received clear
>> text traffic.
>>
>> Mesh solution:
>>
>> When using mesh encryption (Oportunistic IPsec), you can also specify
>> the nodes for specific "clear" using protocols and ports. In general,
>> longest prefix first wins with these type of rule matchines
>>
>> # /etc/ipsec.d/policies/private
>> 10.0.0.0/8
>>
>> # /etc/ipsec.d/policies/clear
>> 10.0.0.0/24  tcp  0  443
>> 1.0.0.0/0    tcp  443  0
>>
>>
>> Paul
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20200523/1e86b7e7/attachment.html>