NSR10 Behind PIX

Raymakers, Guy guy.raymakers at eds.com
Wed Jun 13 02:42:03 EDT 2001


Roy,

IPSec has a problem with NAT'ing, so as you already mentioned it's inherent
to IPSEc. Best solution is to give the untrusted interface a public IP
address.

Guy

-----Original Message-----
From: Roy Rapoport [mailto:rsr at aegsys.com]
Sent: Tuesday, June 12, 2001 10:34
To: vpn at securityfocus.com
Subject: NSR10 Behind PIX



Howdy,

I've got a Netscreen 10 that I've gotten working reasonably reliably and
then moved over to behind a PIX firewall; I've enabled the appropriate
protocols (IP/50, IP/51, and UDP/500).  

client VPN does not now work.  I don't *think* it's a traffic blocking
issue -- I've got snoopers on both sides of the line and they're both
seeing the same number of packts.

The thing is, the Netscreen 10 is now NAT'ed going to the net.  This means
that the client sends packets to PublicIP, which get translated to
PrivateIP; then the responses are sent from PrivateIP and the PIX makes
them look like they're from PublicIP.

My guess is that something inherent to the way the NSR does VPN/IPSec (or
possibly inherently to IPSec) still keeps the private IP visible to the
client.  I see this message in my client's log:
01:11:45.273 Cannot match Policy Entry for received Phase 1 ID:
01:11:45.273 remote host=IP ADDR=10.201.8.22

10.201.8.22 is, of course, the internal IP address of the untrusted
interface of the Netscreen 10.  

So ... is there a solution to this?  Should I just not NAT the NSR10
Untrusted interface?

-roy


VPN is sponsored by SecurityFocus.com

VPN is sponsored by SecurityFocus.com





More information about the VPN mailing list