PIX VPNs timeouts.

Discussion in 'Cisco' started by AM, Jun 21, 2005.

  1. AM

    AM Guest

    Hi all,

    I setup a lot of VPN but for some of them my PIX refuses tunnels when started from remote.

    Some one told me I must modify timeouts (lifetime security associations). Moreover I saw more "timeouts/lifetime" are
    reported in PIX config and as well the routers like 837 running 12.3 and higher.

    Just 2 hours ago I setup another VPN. My PIX can start the tunnel but on syslog messages I received a message telling
    the PIX received a malformed payload from the remote. I deeply controlled syslog messages through thousands of messages
    regarding all VPN messages the PIX produces.

    I wondered the tunnel was up and working fine but there were those messages about malformed payload (702206). The only
    strange behaviour was that ping command reported variable times from 40 to 160 ms randomly (sometime some "Request timeout")

    Another question for those messages (702206) the PIX didn't report which phase they are related to.How could I know that?

    Thanks,

    Alex.
     
    AM, Jun 21, 2005
    #1
    1. Advertising

  2. In article <jbUte.14397$>, AM <> wrote:
    :Just 2 hours ago I setup another VPN. My PIX can start the tunnel but on syslog messages I received a message telling
    :the PIX received a malformed payload from the remote.

    Malformed payloads are often phase 1 indications of mis-matches in
    IPSec keys.

    --
    Would you buy a used bit from this man??
     
    Walter Roberson, Jun 21, 2005
    #2
    1. Advertising

  3. AM

    AM Guest

    Walter Roberson wrote:
    > In article <jbUte.14397$>, AM <> wrote:
    > :Just 2 hours ago I setup another VPN. My PIX can start the tunnel but on syslog messages I received a message telling
    > :the PIX received a malformed payload from the remote.
    >
    > Malformed payloads are often phase 1 indications of mis-matches in
    > IPSec keys.


    In this case should the tunnel not work? Mine works "fine". Other administrator and me controlled both the configuration
    twice and more...

    Alex.
     
    AM, Jun 22, 2005
    #3
  4. AM

    AM Guest

    Walter Roberson wrote:
    > In article <jbUte.14397$>, AM <> wrote:
    > :Just 2 hours ago I setup another VPN. My PIX can start the tunnel but on syslog messages I received a message telling
    > :the PIX received a malformed payload from the remote.
    >
    > Malformed payloads are often phase 1 indications of mis-matches in
    > IPSec keys.
    >


    In this case could the tunnel work without the security provided by phase 1?
    I apologize if my question comes out from my ignorance about IPSec theory

    Alex.
     
    AM, Jun 22, 2005
    #4
  5. AM

    AM Guest

    Walter Roberson wrote:

    > :Just 2 hours ago I setup another VPN. My PIX can start the tunnel but on syslog messages I received a message telling
    > :the PIX received a malformed payload from the remote.
    >
    > Malformed payloads are often phase 1 indications of mis-matches in
    > IPSec keys.
    >

    Sorry again on the topic.
    A list so made

    isakmp policy 10 authentication pre-share
    isakmp policy 10 encryption 3des
    isakmp policy 10 hash md5
    isakmp policy 10 group 1
    isakmp policy 10 lifetime 86400

    isakmp policy 20 authentication pre-share
    isakmp policy 20 encryption 3des
    isakmp policy 20 hash md5
    isakmp policy 20 group 2
    isakmp policy 20 lifetime 86400

    isakmp policy 30 authentication pre-share
    isakmp policy 30 encryption 3des
    isakmp policy 30 hash md5
    isakmp policy 30 group 2
    isakmp policy 30 lifetime 86000

    isakmp policy 40 authentication pre-share
    isakmp policy 40 encryption 3des
    isakmp policy 40 hash md5
    isakmp policy 40 group 2
    isakmp policy 40 lifetime 1200

    isakmp policy 50 authentication pre-share
    isakmp policy 50 encryption 3des
    isakmp policy 50 hash md5
    isakmp policy 50 group 1
    isakmp policy 50 lifetime 28800

    is a good list or could give me problems?

    When PIX receives an IPsec packet it looks through this list (after verified the PSK) to search whether a policy can be
    applied. The main parameters to look for are encryption and hash. And lifetime?
    When managing VPNs to different vendors it seems to me that the order of that list is important. Is this true or not?
    Perhaps lifetime should be specified in ascending order when the same parameters (hash and encr.)are specified?
    I apologize if I've bored you but I'm trying to understand better PIX's behaviour IPsec in general.

    Alex
     
    AM, Jun 22, 2005
    #5
  6. In article <Qfiue.16862$>, AM <> wrote:
    :isakmp policy 10 authentication pre-share
    :isakmp policy 10 encryption 3des
    :isakmp policy 10 hash md5
    :isakmp policy 10 group 1
    :isakmp policy 10 lifetime 86400

    :isakmp policy 20 authentication pre-share
    :isakmp policy 20 encryption 3des
    :isakmp policy 20 hash md5
    :isakmp policy 20 group 2
    :isakmp policy 20 lifetime 86400

    For 3DES, group 2 is usually preferred, so you would normally put the
    version with group 2 as a lower number (higher priority) than the group 1.

    :isakmp policy 30 authentication pre-share
    :isakmp policy 30 encryption 3des
    :isakmp policy 30 hash md5
    :isakmp policy 30 group 2
    :isakmp policy 30 lifetime 86000

    That duplicates policy 20 except for the lifetime, but lifetimes are not
    used to choose proposals: instead, the proposal is chosen, and the shorter
    of the two lifetimes (from the two ends) is used. You might as well
    remove policy 30 and the policy 40 that follows, as they will never
    be selected.

    :isakmp policy 50 authentication pre-share
    :isakmp policy 50 encryption 3des
    :isakmp policy 50 hash md5
    :isakmp policy 50 group 1
    :isakmp policy 50 lifetime 28800

    Similar lifetime consideration (except vs policy 10.)


    :is a good list or could give me problems?

    I would suggest that you should have a 3DES SHA in there. SHA is
    more secure than MD5, so MD5 is often not used except with plain DES
    (PIX 6.3 does not support DES + SHA).

    I know you are running PIX 6.3, so I would suggest that your first
    policy should be AES-128 group 5. That's faster than 3DES and is
    at least as secure.


    :When managing VPNs to different vendors it seems to me that the order of that list is important. Is this true or not?

    Yes. Each end will send a list of proposals to the other end, with the
    lowest numbered policy first in the list. The receiving end will choose
    the first one on the list that it also supports (no matter what priority
    is assigned to it on the receiving end.) Thus, the policy is chosen by
    the receiving endpoint of the tunnel, and the policies of the two tunnels
    is chosen independantly -- it is considered completely valid to have
    strong encryption in one direction and no encryption in the other direction.

    :perhaps lifetime should be specified in ascending order when the same parameters (hash and encr.)are specified?

    It is not used as a selector.
    --
    I was very young in those days, but I was also rather dim.
    -- Christopher Priest
     
    Walter Roberson, Jun 22, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Walter Roberson

    Re: PIX 501 - Two VPNs between same hosts

    Walter Roberson, Jul 11, 2003, in forum: Cisco
    Replies:
    0
    Views:
    942
    Walter Roberson
    Jul 11, 2003
  2. Matt
    Replies:
    1
    Views:
    831
    Aaron Leonard
    Feb 17, 2004
  3. Max
    Replies:
    1
    Views:
    549
    Walter Roberson
    Aug 4, 2004
  4. Graeme Geldenhuys
    Replies:
    2
    Views:
    4,395
    Graeme Geldenhuys
    Apr 14, 2005
  5. Chris
    Replies:
    0
    Views:
    428
    Chris
    Oct 18, 2006
Loading...

Share This Page