PIX VPNs timeouts.

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.

Reply to
AM
Loading thread data ...

In article , 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.

Reply to
Walter Roberson

syslog messages I received a message telling

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

Alex.

Reply to
AM

syslog messages I received a message telling

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.

Reply to
AM

syslog messages I received a message telling

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

Reply to
AM

In article , 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.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.