This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ASL4: cannot respond to IPsec SA request because n

Hello everybody, 

I am a new user to ASL 4.0 I am trying to setup up an IPSec tunnel between a SSH Sentinel client and ASL4

Config is 

host:/var/chroot-ipsec/etc # cat ipsec.conf         
#
# Default Configuration File for FreeS/WAN IPSEC
#

config setup
        interfaces="ipsec0=eth0"
        klipsdebug=none
        plutodebug=none
        dumpdir=
        manualstart=
        fragicmp=no
        packetdefault=drop
        hidetos=yes
        uniqueids=yes
        overridemtu=16260
        nocrsend=yes
        nat_traversal=yes
        keep_alive=60

conn %default
        rekeymargin=9m
        rekeyfuzz=100%
        keyingtries=0

conn test_1
        type="tunnel"
        keyexchange="ike"
        pfsgroup="modp1024"
        pfs="no"
        ike="3des-md5-modp1024"
        esp="3des-md5"
        keylife="3600"
        ikelifetime="7800"
        compress="no"
        left="139.79.71.100"
        right="0.0.0.0"
        auto="add"
        leftupdown="/opt/_updown 2>/tmp/log 1>/tmp/log"
        rightupdown="/opt/_updown 2>/tmp/log 1>/tmp/log"
        leftsubnet="0.0.0.0/0.0.0.0"
        leftid="139.79.71.100"
        rightid="0.0.0.0"
        authby="secret"



Phase one completes, phase two as well but at the end, I see the message:



Mar  9 08:12:39 (none) pluto[22575]: "test_1"[1] 139.79.71.50 #18: responding to Main Mode from unknown peer 139.79.71.50
Mar  9 08:12:39 (none) pluto[22575]: "test_1"[1] 139.79.71.50 #18: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-00: no NAT detected
Mar  9 08:12:39 (none) pluto[22575]: "test_1"[1] 139.79.71.50 #18: ignoring informational payload, type IPSEC_INITIAL_CONTACT
Mar  9 08:12:39 (none) pluto[22575]: "test_1"[1] 139.79.71.50 #18: Peer ID is ID_IPV4_ADDR: '139.79.71.50'
Mar  9 08:12:39 (none) pluto[22575]: "test_1"[1] 139.79.71.50 #18: sent MR3, ISAKMP SA established
Mar  9 08:12:39 (none) pluto[22575]: "test_1"[1] 139.79.71.50 #18: cannot respond to IPsec SA request because no connection is known for 192.168.20.0/24===139.79.71.100:17/67...139.79.71.50:17/68
Mar  9 08:12:39 (none) pluto[22575]: "test_1"[1] 139.79.71.50 #18: sending encrypted notification INVALID_ID_INFORMATION to 139.79.71.50:500



on the ASL log, and the client deletes the SA. Reading messages from other users with the same problem, I noticed it is always somehow connected with wrong subnet mask definitions

On the ASL log, the line:

"test_1"[1] 139.79.71.50 #18: cannot respond to IPsec SA request because no connection is known for 192.168.20.0/24===139.79.71.100:17/67...139.79.71.50:17/68

is very bizzare, the network masks for bot ASL public address and SSH Sentinel public address are wrong.

it looks like ASL does not like something it finds in the phase 2 setup packets (connected to subnet masks)....

Any one has any experience with this problem.?

Thanks

Ricardo  


This thread was automatically locked due to age.
Parents Reply Children
  • Hi there, 

    could it be the case that you did enable virtual ip with dhcp over ipsec?

    Astaro V4 does not support dhcp over ipsec yet.
    therefor you must specify a virtual ip manually on both sides, 
    this should fix this issue.

    kind regards
    Gert