Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > PIX to PIX vpn problem

Reply
Thread Tools

PIX to PIX vpn problem

 
 
Rik Bain
Guest
Posts: n/a
 
      07-10-2003
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" <(E-Mail Removed)-cnrc.gc.ca> wrote in message
> news:bekj1g$bfu$(E-Mail Removed)...
>> In article <eUjPa.30213$(E-Mail Removed)>,
>> mcaissie <(E-Mail Removed)> 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
>> eers.
>>
>> 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.


 
Reply With Quote
 
 
 
 
mcaissie
Guest
Posts: n/a
 
      07-10-2003
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



 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      07-10-2003
In article <eUjPa.30213$(E-Mail Removed)>,
mcaissie <(E-Mail Removed)> 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
eers.

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
 
Reply With Quote
 
mcaissie
Guest
Posts: n/a
 
      07-10-2003

"Walter Roberson" <(E-Mail Removed)-cnrc.gc.ca> wrote in message
news:bekj1g$bfu$(E-Mail Removed)...
> In article <eUjPa.30213$(E-Mail Removed)>,
> mcaissie <(E-Mail Removed)> 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
> eers.
>
> 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.



 
Reply With Quote
 
mcaissie
Guest
Posts: n/a
 
      07-11-2003

"Rik Bain " <(E-Mail Removed)> wrote in message
news(E-Mail Removed) rg...
> 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.


 
Reply With Quote
 
Marino
Guest
Posts: n/a
 
      07-14-2003
Hi.

Check routing on CheckPoint or behind the PIX.

Bye


"mcaissie" <(E-Mail Removed)> wrote in message
news:eUjPa.30213$(E-Mail Removed)...
> 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
>
>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
VPN PIX-_static PIX ; PIX-dynamic_PIX ; VPN Client Svenn Cisco 3 03-13-2006 09:25 AM
PIX-to-PIX vpn + remote Access VPN not working Marko Uusitalo Cisco 1 04-11-2005 12:45 PM
mixing pix-to-pix vpn and pptp-dial-in-vpn on pix501 Tom Cisco 4 11-17-2004 02:18 PM
PIX to PIX VPN and VPN Client to PIX Config Example? GVB Cisco 1 02-06-2004 07:44 PM
PIX to PIX to PIX meshed VPN Richard Cisco 1 11-15-2003 07:41 AM



Advertisments