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

IPSec VPN problem: no connection is known for

I'm trying to use the IPSec VPN part of Astaro v3.2 together with Sentinel v. 1.3.2 (w2k, service pack 3).

Basic network setup is something like:

Company LAN: 192.168.100.0/255.255.255.192 (not the real one)
Company FW: 70.35.15.25 (public IP - but not the real one)
Roadwarrior: 90.30.10.20 (public IP - i.e. no NAT'ing - not the real address).

However, diagnosing the VPN connection I get:

Cannot run the diagnostics. The remote end does not respond to
the IKE proposal (phase-1). Make sure that you filter rules bypass
the IKE data packets. Also, verify that the remote end runs
IPSec/IKE, and that it is not temporarily offline or unreachable due
to network configuration.

From the Astaro log at least something seems to be working:

 1. packet from 90.30.10.20:500: ignoring Vendor ID payload

 2. "remote2company__vpn_1" 90.30.10.20 #1: responding to Main Mode from unknown peer          90.30.10.20

 3. "remote2company__vpn_1" 90.30.10.20 #1: ignoring informational payload, type          IPSEC_INITIAL_CONTACT

 4. "remote2company__vpn_1" 90.30.10.20 #1: Peer ID is ID_IPV4_ADDR: '90.30.10.20'

 5. "remote2company__vpn_1" 90.30.10.20 #1: Issuer CRL not found

 6. "remote2company__vpn_1" 90.30.10.20 #1: Issuer CRL not found

 7. "remote2company__vpn_1" 90.30.10.20 #1: sent MR3, ISAKMP SA established

 8. "remote2company__vpn_1" 90.30.10.20 #2: cannot respond to IPsec SA request because no connection is known for 

192.168.100.0/26===70.35.15.25...90.30.10.20

 9. "remote2company__vpn_1" 90.30.10.20 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message 

ID 0xb27e6dbb (perhaps this is a duplicated packet)

A few questions to the above:

Line 1: Is it ok that it ignores the Vendor ID?

Line 2: 

Line 2: I guess unknown peer 90.30.10.20 is ok - since it is later "recognized" in line 4, correct?

Line 5: Issuer CRL not found. Is this the problem? And how do I correct it?

Line 7: What does this sent MR3? ISAKMP SA established - doesn't this at least indicate that something is working correctly?

Line 8: I've read about problems with 192.168.... subnets - are they still present? And how do I solve it?

*****************************
Setup on Sentinel:
*****************************

Security gateway: Public IP of company = external interface of Astaro firewall.

Remote network: Network on which internal interface of Astaro firewall is connected.

Auth. key: company certificate.

Proposal Parameters:

IKE proposal:
Encrypt. alg: 3des
Integrity function: MD5
IKE mode: main mode
IKE group: MODP 1024 ( group 2 )

IPSec proposal:
Encrypt alg: 3des
Integrity function: HMAC-md5
IPSec mode: tunnel (not selectable)
PFS group: MODP 1024 ( group 2)

*****************************
Setup on Astaro
*****************************

IPSec VPN connection:
Name: remote2company
Type: RoadWarrior
IPSec Policy: 3DES_PFS_COMP
Tunnel Endpoints: eth1
Remote Endpoint: Any
Subnet Definition (optional)
Remote Sunet: None
Authentication of remote station(s) -> Keys (the key I saved to disk and imported to client).

Connection is activated.

I used X.509 keys - all generated on ASL 3.2. I followed (or tried to follow) the host to net - static document from 

http://docs.astaro.org

Hints, suggestions etc are very welcomed!

Thanks in advance,

Michael


This thread was automatically locked due to age.
  • Just a thought... 

    Is the public NIC IP address that presented to the outside world? We have a similar problem here where our ISP has assigned us an IP address for the external interface but out 'public' IP address is different - they are translating IP addresses as traffic id routed through thier kit which screws up IPSEC.
  • Originally posted by Jerry Allen:
    192.168.100.0/26===70.35.15.25...90.30.10.20

    should be

    LEFT-IP...LEFT-publicIP===RIGHT-public-IP...RIGHT-IP

    I had this problem and it was an error in the configuration of the IPSEC Configurations.
    I had to edit the files manually to fix it. ASL picked up a subnet mask that was wrong from somewhere and would not allow it to be changed.

    What are you VPNing with/to?
    It seems there is still a bug in Astaro. Could you detail what files you edited, and what I need to modify?

    Thanks in advance,

    Michael
  • Originally posted by norwich:
    Just a thought... 

    Is the public NIC IP address that presented to the outside world? We have a similar problem here where our ISP has assigned us an IP address for the external interface but out 'public' IP address is different - they are translating IP addresses as traffic id routed through thier kit which screws up IPSEC.
    The IP address they assigned us is outside the RFC1597 specified addresses:

    10.0.0.0 -> 10.255.255.255
    172.16.0.0 -> 172.31.255.255
    192.168.0.0 -> 192.168.255.255

    But I guess that isn't a proof. Any suggestions on how I do a better test of that?

    Thanks,

    Michael
  • Originally posted by oliver.desch:
    Hi,

    check all network settings, such as 192.168.100.0/26 -
    do you really use 26 as bit mask, most common is 24 ;-)

    read you
    o|iver
    Actually the 26 bit mask is correct. Although I would prefer class-divided subnets this is actually what we have.

    Michael
  • Originally posted by Jesus Picornell Alsina:
    I have the same problem. Have you solved it?

    Thank you.
    Unfortunately, no. Have you solved it?

    Michael