[Openswan Users] Right - Not working

Dominic Wiersma d.wiersma at dwits.nl
Fri Nov 28 05:21:12 EST 2014


Hi all,.

 

Thanks for the feedback.

While testing the new configuration, the firewall (iptables) is set to the
default values, allowing all data in and out.

I have also added the right subnet option (rightsubnet=192.168.0.0/24) , the
situation doesn't change in any way.

 

Any more ideas?

 

Greetz,

 

Dominic

 

Van: Gerhard Reuter [mailto:gerhard.reuter at bayer.com] 
Verzonden: Friday, November 28, 2014 7:10 AM
Aan: Dominic Wiersma; users at lists.openswan.org
Onderwerp: AW: [Openswan Users] Right - Not working

 

Hi Dominic,

 

have had a similar issue - could get it back to work by adding "rightsubnet"
parameter.

 

hope that  helps

 

greetings

Gerhard

 

 

 

Von: users-bounces at lists.openswan.org
[mailto:users-bounces at lists.openswan.org] Im Auftrag von Dominic Wiersma
Gesendet: Freitag, 28. November 2014 00:26
An: users at lists.openswan.org
Betreff: [Openswan Users] Right - Not working

 

Hi All,

 

I have openswan running and all is working well.

Due to a design change, I want only specific hosts to be able to connect.

So in my ipsec.conf I have changed right=%any to right=1.2.3.4, which is the
public ip of the remote client that must connect.

But then nothing happens, no errors in the logs, no nothing. On the client
the connection simply times out. I am  troubleshooting this problem for
hours now.

What can cause this behavior?

 

config setup

        dumpdir=/var/run/pluto/

        #in what directory should things started by setup (notably the Pluto
daemon) be allowed to dump core?

        nat_traversal=yes

        #whether to accept/offer to support NAT (NAPT, also known as "IP
Masqurade")workaround for IPsec

        virtual_private=%v4:10.254.168.0/24

        #contains the networks that are allowed as subnet= for the remote
client. In other words, the address ranges that may live behind a NAT router
through which a client connects.

        protostack=netkey

        #decide which protocol stack is going to be used.

        force_keepalive=yes

        keep_alive=60

        # Send a keep-alive packet every 60 seconds.

 

conn L2TP-PSK-noNAT

        authby=secret

        #shared secret. Use rsasig for certificates.

        pfs=no

        #Disable pfs

        auto=add

        #the ipsec tunnel should be started and routes created when the
ipsec daemon itself starts.

        keyingtries=3

        #Only negotiate a conn. 3 times.

        ikelifetime=8h

        keylife=1h

        ike=aes256-sha1,aes128-sha1,3des-sha1

        phase2alg=aes256-sha1,aes128-sha1,3des-sha1

        # https://lists.openswan.org/pipermail/users/2014-April/022947.html

        # specifies the phase 1 encryption scheme, the hashing algorithm,
and the diffie-hellman group. The modp1024 is for Diffie-Hellman 2. Why
'modp' instead of dh? DH2is a 1028 bit encryption $

        type=tunnel

        #because we use l2tp as tunnel protocol

        left=x.x.x.x

        leftsubnet=10.10.10.0/24

        #fill in server IP above

        leftprotoport=17/%any

        right=1.2.3.4

        rightprotoport=17/%any

        #dpddelay=10

        # Dead Peer Dectection (RFC 3706) keepalives delay

        #dpdtimeout=20

        # length of time (in seconds) we will idle without hearing either an
R_U_THERE poll from our peer, or an R_U_THERE_ACK reply.

        #dpdaction=clear

        # When a DPD enabled peer is declared dead, what action should be
taken. clear means the eroute and SA with both be cleared.

        #aggrmode=yes

        ikev2=propose

 

Best regards,

 

Dominic Wiersma

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20141128/94136379/attachment.html>


More information about the Users mailing list