Screen OS

last person joined: 8 months ago 

This is a legacy community with limited Juniper monitoring.

  • 1.  set ike p1-proposal - necessary??

    Posted 06-13-2012 13:34

    I am setting up mulitiple phase-2 SA's using 1 VPN tunnel.

    Following the ScreenOS cookbook as a refernce (pg 372 -374)

     

    I've set-up almost 100 vpn's in the past. This is the first time I am trying multiple phase-2 SA's using one tunnel.

    Its an older fireware verion (6.1.0r2)
    I'm running it becuase I can't upgrade to 6.3 during a prodution cycle.

     

    This is the way the cookbook says to set up Phase 1:

    set ike p1-proposal "pre-3des-sha-g2-12800" preshare group2 esp 3des sha-1 second 12800

     
    set ike gateway "cisco1" address 10.200.1.1 Main outgoing-interface "ethernet0/2 " preshare "xxx" proposal "pre-g2-3des-sha"

     

    My question is why is the first "set ike p1-proposal" entry necessary if the 2nd entry (setting up the ike gateway) seems to do esentially the same thing...proposal, etc.

     

    Can someone school me on this subject?

     



  • 2.  RE: set ike p1-proposal - necessary??
    Best Answer

    Posted 06-13-2012 14:27

    The set ike p1-proposal is configuring a set of phase 1 parameters (in this case 3des for encryption, sha for auth hash, diffie hellman group 2, and 12800 seconds liketime)

     

    The second set ike gatway line is setting up a spceific phase 1 tunnel, and you are configuring that tunnel to use the phase1 parameters you confiugred earlier and named "pre-3des-sha-g2-12800"



  • 3.  RE: set ike p1-proposal - necessary??

    Posted 06-15-2012 05:51
    @B2 wrote:

    The second set ike gatway line is setting up a spceific phase 1 tunnel, and you are configuring that tunnel to use the phase1 parameters you confiugred earlier and named "pre-3des-sha-g2-12800"

    Actually, the second command in this example is using the pre-configured "pre-g2-3des-sha" setting, so it looks like the first command is completely redundant. It might be a mistake in the book (i.e. the author meant to use the custom 12800-second timeout, but accidentally typed it without the "-12800" part in the second command).

     

    For a bit more info: According the the relevant RFCs, both endpoints are supposed to exchange timeout values and use the shortest proposed timeout. So in theory, it shouldn't matter whether the timeout values match on both ends or not. However in reality, it occasionally causes reliability issues when both ends don't agree exactly on the rekey timeout value, so on occasion you might have to change the default timeout on one side to match the other. Screenos uses a default of 28800 seconds for the Phase 1 rekey time, and other vendors sometimes use longer or shorter periods. In your example, the author is creating a custom P1 config with a timeout of 12800 seconds, presumably to match whatever device is on the other end of the tunnel.