[Swan] IPSec secure messages.

Madhan Raj madhanrajrm at gmail.com
Wed May 15 18:05:11 UTC 2019


Hi Paul & andrew,


> *Which version?*
>
> *The below is debug output, it should only appear when debugging is*
> *enabled.  Can you check /etc/ipsec.conf to see if there is a line*
> *like:*
> *    plutodebug=...*
> *for instance:*
> *    plutodebug=lifecycle**(these all appear to be controlled by that
> flag)  *


<MADHAN> Sry i was using this openswan-2.6.32-37.el6.x86_64  version
            This is my ipsec.conf file.

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
        # For Red Hat Enterprise Linux, leave protostack=netkey
        protostack=netkey
        # plutodebug=crypt control controlmore pfkey dpd
        plutodebug=all
        klipsdebug=all
        nat_traversal=yes
        virtual_private=
        oe=off
        # Enable this if you see failed to find any available worker
        nhelpers=0
        plutorestartoncrash=yes
        # NSS DB Storage
        plutoopts="--ipsecdir /usr/local/platform/.security/ipsec"
        # Pluto core file if it cores...
        dumpdir=/var/log/active/core
        # For redirecting pluto logs, use plutostderrlog=directory of our
choice
conn block
        auto=ignore
conn private
        auto=ignore
conn private-or-clear
        auto=ignore
conn clear-or-private
        auto=ignore
conn clear
        auto=ignore
conn packetdefault
        auto=ignore

>   2.  I have configured an Ipsec policy on one of my server pointing to
> other server. but i didn't configure the policies on
>
> > other side to point this server.
> > will network ping be successful?
> > other side to point this server.
> > will network ping be successful?
> If you use auto=add, then yes because libreswan would not initiate
> IPsec.
>
> If you use auto=ondemand or auto=start, then no because libreswan
> ,will block leaking packets until the IPsec connection is up.
>
>   <MADHAN> I have auto=start in my policy.conf file.
   conn 772007410_x509
        left=10.63.101.19
        leftcert=ipsec-db
        leftrsasigkey=%cert
        leftprotoport=tcp/0
        leftid="C=RS, O=home, OU=cup, CN=esc-imppub-12.burren.pst,
ST=serbia, L=belgrade"
        right=10.63.101.18
        rightcert=esc-cucm-12.burren.pst
        rightrsasigkey=%cert
        rightprotoport=tcp/0
        rightid=""
        type=transport
        auth=esp
        authby=rsasig
        keyexchange=ike
        keyingtries=%forever
        rekey=yes
        ike=3des-sha1-modp1024
        esp=aes128-sha1
        ikelifetime=3600s
        salifetime=3600s
        pfs=no

* auto=startI can see still the ping to the normal server is working fine ?
so this means that openswan is not blocking any trafffic to the other
server if ipsec policy is not up ??*

> 3. Will the network between two servers will be intact if the ipsec
> policies are down ? .i just wanna know if the ping
> > command will work at least between two servers ?.
> No, unless you set failureshunt=passthrough, but I would not recommend
> that.
>
<MADHAN>  I have shared my policy  and ipsec.conf file above i am sure we
are not adding any failureshunt=passthrough anywhere. but i can see the
network connectivity is intact though the policies are still in PENDING
state . am i missing something here ?

On Tue, May 14, 2019 at 7:17 PM Paul Wouters <paul at nohats.ca> wrote:

> On Tue, 14 May 2019, Madhan Raj wrote:
>
> > 2.  I have configured an Ipsec policy on one of my server pointing to
> other server. but i didn't configure the policies on
> > other side to point this server.
> > will network ping be successful?
>
> If you use auto=add, then yes because libreswan would not initiate
> IPsec.
>
> If you use auto=ondemand or auto=start, then no because libreswan
> will block leaking packets until the IPsec connection is up.
>
> > 3. Will the network between two servers will be intact if the ipsec
> policies are down ? .i just wanna know if the ping
> > command will work at least between two servers ?.
>
> No, unless you set failureshunt=passthrough, but I would not recommend
> that.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20190515/47dbecc9/attachment.html>


More information about the Swan mailing list