Remote Access IPSEC - Remote Access IP

What kind of authentication mechanism are you using for the remote access connection in question?

Hi,

Authentication type X509 certificate. In the downloadable Configuration 
for IPSEC Remote Access the Parameter IpAddrAssign is 0:
...
XAUTH-Id=
IpAddrAssign=0
DNS1=0.0.0.0
DNS2=0.0.0.0
....

this does not work with a NAT-NAT connection.

if i change it in
...
XAUTH-Id=
IpAddrAssign=2
IpAddress=192.168.76.1      

IpAddrAssign=0 is actually the correct setting if the user has a static IP address assigned. Could you check the ipsec log when the client is connecting and see if a modecfg exchange is done after the ISAKMP SA is established?

I'll be interested to learn the result of d12fk's analysis, but I'm confused.  We normally set the remote client to request the IP from the Astaro when it connects, so the only place I need to record the assigned IP is in the User definition in the Astaro.  What am I not understanding?

Cheers - Bob

What am I not understanding?

Nothing really, that's exactly what I'd expect to happen in the setup from above. "IpAddrAssign=0" stands for "assign IP address using modecfg". Don't blame me for that one! =)

Something does not seem to work here, though. The first thing to check is if the IP address assignment is actually talking place. Hence, my request for modecfg traces from the log.

Hope that cleared it up a bit.

with IpAddrAssign=0

form the ipsec log:
...
2009:01:27-17:14:30 (none) pluto[15057]: "TEST_0"[1] X:X:X:X:4500 #31: sent MR3, ISAKMP SA established 
2009:01:27-17:14:30 (none) pluto[15057]: "TEST_0"[1] X:X:X:X:4500 #31: cannot respond to IPsec SA request because no connection is known for 192.168.4.0/24===Y:Y:Y:Y:4500[@gate.name.tld]...X:X:X:X:4500[jhiby@domain.tld]===10.2.120.1/32 
2009:01:27-17:14:30 (none) pluto[15057]: "TEST_0"[1] X:X:X:X:4500 #31: sending encrypted notification INVALID_ID_INFORMATION to X:X:X:X:4500 
2009:01:27-17:14:39 (none) pluto[15057]: "TEST_0"[1] X:X:X:X:4500 #31: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xc4d4c199 (perhaps this is a duplicated packet) 
2009:01:27-17:14:39 (none) pluto[15057]: "TEST_0"[1] X:X:X:X:4500 #31: sending encrypted notification INVALID_MESSAGE_ID to X:X:X:X:4500 
...


--Johannes

2009:01:27-17:14:30 (none) pluto[15057]: "TEST_0"[1] X:X:X:X:4500 #31: sent MR3, ISAKMP SA established 
2009:01:27-17:14:30 (none) pluto[15057]: "TEST_0"[1] X:X:X:X:4500 #31: cannot respond to IPsec SA request because no connection is known for 192.168.4.0/24===Y:Y:Y:Y:4500[@gate.name.tld]...X:X:X:X:4500[jhiby@domain.tld]===10.2.120.1/32

The modecfg exchange does not take place. It should follow right after the ISAKMP SA is established. It seems that ASC is not requesting a modecfg exchange. Pluto would complain if it received a modecfg request without being configured to handle it. Could you:

1) post the section of the connection in question from the file /var/sec/chroot-ipsec/etc/ipsec.conf. Just to make sure pluto is configured correctly.

2) check the connection profile settings in ASC. In the "IP address assignment" dialog, "IP config mode" should be selected after import of the .ini file.

3) restart ASC and try again. This helped in the past when the settings were right but it didn't work anyways.

Thanks.

Part of my confusion came from the fact that we're using L2TP over IPSec, not the more-complex IPSec configuration.  Johannes, do you have the box checked for NAT-Traversal?  The negotiation for that happens automatically with the L2TP flavor.

Cheers - Bob

@d12fk
#/etc/ipsec.conf - strongSwan IPsec configuration file

config setup
        interfaces="ipsec0=ppp0"
        charonstart="no"
        plutodebug="none"
        packetdefault="drop"
        fragicmp="yes"
        hidetos="yes"
        overridemtu="1420"
        uniqueids="no"
        nocrsend="yes"
        nat_traversal="yes"
        keep_alive="60"
        crlcheckinterval="0"
        strictcrlpolicy="no"

conn %default
        rekeymargin="9m"
        rekeyfuzz="100%"
        keyingtries="0"
        leftsendcert="always"
        dpddelay="30"
        dpdtimeout="120"
        dpdaction="restart"


conn D_REF_yxYERqWcEf_0
        leftcert="/etc/ipsec.d/hostcerts/x509cert.pem"
        left="Y.Y.Y.Y"
        keyingtries="3"
        rightcert="/etc/ipsec.d/hostcerts/REF_SBOuSpxZzr_f0a49d8b.pem"
        esp="aes128-md5"
        authby="rsasig"
        ikelifetime="7800"
        keyexchange="ike"
        pfsgroup="modp1536"
        rightsourceip="5.214.18.11"
        leftrsasigkey="%cert"
        pfs="yes"
        leftsubnet="192.168.4.0/255.255.255.0"
        keylife="3600"
        rightid="jhiby@domain.tld"
        leftid="@gate.name.tld"
        rightupdown="/opt/_updown.classic 2>/tmp/log 1>/tmp/log"
        right="0.0.0.0"
        auto="add"
        leftupdown="/opt/_updown.classic 2>/tmp/log 1>/tmp/log"
        compress="no"
        ike="aes256-md5-modp1536"
        type="tunnel"
        rightrsasigkey="%cert"


in the ASC Client: IKE Config Mode   (not IP Config Mode)


@BAlfson
Yes NAT-TRAVERSAL is on


--Johannes

        rightsourceip="5.214.18.11"

The client should get this IP address assigned from the ASG but seems to refuse to do modecfg in the first place. Thus, no IP assignment is taking place. Instead it uses 10.2.120.1 as it's local address.

The ASC log would be interesting to make sure ASC is not trying modecfg. However, 5.214.18.11 is not 192.168.76.1. Are you sure you assigned the right address as a "static remote access IP" for your user?

        rightupdown="/opt/_updown.classic 2>/tmp/log 1>/tmp/log"
        leftupdown="/opt/_updown.classic 2>/tmp/log 1>/tmp/log"

The ipsec.conf file seems not to be from a 7.400 beta installation. What version are you using?

in the ASC Client: IKE Config Mode   (not IP Config Mode)

My bad, the setting is correct.

        rightsourceip="5.214.18.11"

The client should get this IP address assigned from the ASG but seems to refuse to do modecfg in the first place. Thus, no IP assignment is taking place. Instead it uses 10.2.120.1 as it's local address.

The ASC log would be interesting to make sure ASC is not trying modecfg. However, 5.214.18.11 is not 192.168.76.1. Are you sure you assigned the right address as a "static remote access IP" for your user?

        rightupdown="/opt/_updown.classic 2>/tmp/log 1>/tmp/log"
        leftupdown="/opt/_updown.classic 2>/tmp/log 1>/tmp/log"

The ipsec.conf file seems not to be from a 7.400 beta installation. What version are you using?

in the ASC Client: IKE Config Mode   (not IP Config Mode)

My bad, the setting is correct.

The client should get this IP address assigned from the ASG but seems to refuse to do modecfg in the first place. Thus, no IP assignment is taking place. Instead it uses 10.2.120.1 as it's local address.

The ASC log would be interesting to make sure ASC is not trying modecfg. However, 5.214.18.11 is not 192.168.76.1. Are you sure you assigned the right address as a "static remote access IP" for your user?



The ipsec.conf file seems not to be from a 7.400 beta installation. What version are you using?



My bad, the setting is correct.

I'm online again.
My system has crashed. Now i have a new installed Windows XP and it works fine.
No Problem with the ASG any more.

The ipsec.conf was from version 7.305 because after my first post i have downgraded
the astaro from 7.380 for testing. Now i'm back on 7.386 and it works fine.

There must be a problem with the ASC Installation on my system. I have had reinstalled
it many times on the old system but every time was the same problem well with other
astro boxes.

Now it works.

Many thanks for your help.

--Johannes