PIX to PIX vpn problem

Discussion in 'Cisco' started by Rik Bain, Jul 10, 2003.

  1. Rik Bain

    Rik Bain Guest

    Run a capture on the pix outside interface (or use sniffer) and show that
    you receive ICMP packets from the peer, show that you receive UDP/500 from
    the peer, and show that you DONT receive ESP from the peer.

    On Thu, 10 Jul 2003 21:04:06 +0000, mcaissie wrote:

    >
    > "Walter Roberson" <-cnrc.gc.ca> wrote in message
    > news:bekj1g$bfu$...
    >> In article <eUjPa.30213$>,
    >> mcaissie <> wrote:
    >> :I have a vpn between to sites . PIX to PIX 6.2(2)
    >>
    >> :As you can see , there is no packets decaps and decrypt on PIX 2 . It
    >> :seems that the encrypted packets send from PIX 1 are not received by PIX

    > 2
    >>
    >> ;-routing is ok since both PEER can exchange keys
    >>
    >> :I must add that this VPN goes across a CheckPoint Firewall wich allows
    >> :( i hope i have no control on this firewall ) all ipsec traffic between

    > both
    >> :peers.
    >>
    >> Is the Checkpoint firewall [or some other device on the way] doing
    >> NAT and you have AH configured? If so, then you would not be
    >> able to get valid packets through in one direction, as AH is not
    >> compatible with NAT [unless you were using the new NAT-T available
    >> in 6.3(1).]

    >
    > Thanks for your quick response
    >
    > There is a static translation in the Checkpoint translating the outside
    > IP of the PIX for a Public address .
    >
    > Transform-set is esp-3des esp-sha-hmac
    >
    > But it was working before . I manage both PIX , the one on the remote site
    > through https. I haven't change any config on both PIX since , and the
    > Checkpoint admin is
    > saying the same thing about the Checkpoint , so we are in a ball game where
    > each one is trying to prove that the problem is on the other. I am quite
    > sure that i am ok on my side but i need some killer test that would prove it
    > with any doubt.
    Rik Bain, Jul 10, 2003
    #1
    1. Advertising

  2. Rik Bain

    mcaissie Guest

    Hi,

    I have a vpn between to sites . PIX to PIX 6.2(2)

    On both sides sh isakmp gives QM_IDLE



    On side 1 sh cry ipsec sa gives

    #pkts encaps: 288, #pkts encrypt: 288, #pkts digest 288
    #pkts decaps: 51, #pkts decrypt: 51, #pkts verify 51
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress
    failed: 0
    #send errors 1, #recv errors 0

    But on the side 2 i get

    #pkts encaps: 81, #pkts encrypt: 81, #pkts digest 81
    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress
    failed: 0
    #send errors 1, #recv errors 0

    As you can see , there is no packets decaps and decrypt on PIX 2 . It
    seems that the encrypted packets send from PIX 1 are not received by PIX 2
    ..

    Any idea on what could cause this ?

    -routing is ok since both PEER can exchange keys
    -crypto access-list are mirror image from each other
    -sh log shows no error

    I must add that this VPN goes across a CheckPoint Firewall wich allows
    ( i hope i have no control on this firewall ) all ipsec traffic between both
    peers.
    They don't see any errors on their side either . Is there a test i could do
    that
    would certify that the problem is on the checkpoint side ?

    thanks
    mcaissie, Jul 10, 2003
    #2
    1. Advertising

  3. In article <eUjPa.30213$>,
    mcaissie <> wrote:
    :I have a vpn between to sites . PIX to PIX 6.2(2)

    :As you can see , there is no packets decaps and decrypt on PIX 2 . It
    :seems that the encrypted packets send from PIX 1 are not received by PIX 2

    ;-routing is ok since both PEER can exchange keys

    :I must add that this VPN goes across a CheckPoint Firewall wich allows
    :( i hope i have no control on this firewall ) all ipsec traffic between both
    :peers.

    Is the Checkpoint firewall [or some other device on the way] doing
    NAT and you have AH configured? If so, then you would not be
    able to get valid packets through in one direction, as AH is not
    compatible with NAT [unless you were using the new NAT-T available
    in 6.3(1).]
    --
    I've been working on a kernel
    All the livelong night.
    I've been working on a kernel
    And it still won't work quite right. -- J. Benson & J. Doll
    Walter Roberson, Jul 10, 2003
    #3
  4. Rik Bain

    mcaissie Guest

    "Walter Roberson" <-cnrc.gc.ca> wrote in message
    news:bekj1g$bfu$...
    > In article <eUjPa.30213$>,
    > mcaissie <> wrote:
    > :I have a vpn between to sites . PIX to PIX 6.2(2)
    >
    > :As you can see , there is no packets decaps and decrypt on PIX 2 . It
    > :seems that the encrypted packets send from PIX 1 are not received by PIX

    2
    >
    > ;-routing is ok since both PEER can exchange keys
    >
    > :I must add that this VPN goes across a CheckPoint Firewall wich allows
    > :( i hope i have no control on this firewall ) all ipsec traffic between

    both
    > :peers.
    >
    > Is the Checkpoint firewall [or some other device on the way] doing
    > NAT and you have AH configured? If so, then you would not be
    > able to get valid packets through in one direction, as AH is not
    > compatible with NAT [unless you were using the new NAT-T available
    > in 6.3(1).]


    Thanks for your quick response

    There is a static translation in the Checkpoint translating the outside
    IP of the PIX for a Public address .

    Transform-set is esp-3des esp-sha-hmac

    But it was working before . I manage both PIX , the one on the remote site
    through https. I haven't change any config on both PIX since , and the
    Checkpoint admin is
    saying the same thing about the Checkpoint , so we are in a ball game where
    each one is trying to prove that the problem is on the other. I am quite
    sure that i am ok on my side but i need some killer test that would prove it
    with any doubt.
    mcaissie, Jul 10, 2003
    #4
  5. Rik Bain

    mcaissie Guest

    "Rik Bain " <> wrote in message
    news:p...
    > Run a capture on the pix outside interface (or use sniffer) and show that
    > you receive ICMP packets from the peer, show that you receive UDP/500 from
    > the peer, and show that you DONT receive ESP from the peer.


    Cool , i never used the command capture before , it's very usefull.
    And it is exactly as you say , when i launch a ping i can see ESP traffic
    going out,
    and on the remote PIX i see ESP coming in and replies going out again , but
    i don't
    receive those replies on the first PIX , so they are blocked somewhere in
    between.

    To bad there is no ESP traceroute to see where , but at least i have some
    good logs to put in my report .

    Thanks you both mister Bain and Robertson , your contribution to this
    group is greatly appreciated.
    mcaissie, Jul 11, 2003
    #5
  6. Rik Bain

    Marino Guest

    Hi.

    Check routing on CheckPoint or behind the PIX.

    Bye


    "mcaissie" <> wrote in message
    news:eUjPa.30213$...
    > Hi,
    >
    > I have a vpn between to sites . PIX to PIX 6.2(2)
    >
    > On both sides sh isakmp gives QM_IDLE
    >
    >
    >
    > On side 1 sh cry ipsec sa gives
    >
    > #pkts encaps: 288, #pkts encrypt: 288, #pkts digest 288
    > #pkts decaps: 51, #pkts decrypt: 51, #pkts verify 51
    > #pkts compressed: 0, #pkts decompressed: 0
    > #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress
    > failed: 0
    > #send errors 1, #recv errors 0
    >
    > But on the side 2 i get
    >
    > #pkts encaps: 81, #pkts encrypt: 81, #pkts digest 81
    > #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
    > #pkts compressed: 0, #pkts decompressed: 0
    > #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress
    > failed: 0
    > #send errors 1, #recv errors 0
    >
    > As you can see , there is no packets decaps and decrypt on PIX 2 . It
    > seems that the encrypted packets send from PIX 1 are not received by PIX

    2
    > .
    >
    > Any idea on what could cause this ?
    >
    > -routing is ok since both PEER can exchange keys
    > -crypto access-list are mirror image from each other
    > -sh log shows no error
    >
    > I must add that this VPN goes across a CheckPoint Firewall wich allows
    > ( i hope i have no control on this firewall ) all ipsec traffic between

    both
    > peers.
    > They don't see any errors on their side either . Is there a test i could

    do
    > that
    > would certify that the problem is on the checkpoint side ?
    >
    > thanks
    >
    >
    >
    Marino, Jul 14, 2003
    #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. GVB
    Replies:
    1
    Views:
    2,754
    Martin Bilgrav
    Feb 6, 2004
  2. Elise
    Replies:
    6
    Views:
    796
    John Rennie
    May 22, 2004
  3. Tom
    Replies:
    4
    Views:
    650
  4. Marko Uusitalo
    Replies:
    1
    Views:
    1,485
    Frank Durham
    Apr 11, 2005
  5. Svenn
    Replies:
    3
    Views:
    706
    Svenn
    Mar 13, 2006
Loading...

Share This Page