Trouble with VPN between Cisco PIX 6.3.3 and VPN 3000 Concentrator

Answered Question
Apr 8th, 2010

Hi Guys,

I hope this is the right place and that someone has come across this before as I don't have much hair left to pull out -- I'm trying to set up a tunnel between our Pix running 6.3.3 and a customer using a VPN3000.

The customer would like us to be able to do health checks on a device without allowing anything in from our private side network address range, just a single public IP address.  We currently run a VPN to our disaster recovery site to allow for offsite replication, but the ACL on the other end of that VPN *does* allow for traffic from our private side network, so the config we had there wasn't all that helpful.  Here's a snip of what I've been trying:

nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz1 security50

name 172.16.1.48 Cust_DVR1

access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 Cust_DVR1 255.255.255.255

access-list outside_cryptomap_30 permit ip 192.168.1.0 255.255.255.0 Cust_DVR1 255.255.255.255

ip address outside X.Y.Z.227 255.255.255.224
ip address inside 192.168.1.1 255.255.255.0

pdm location Cust_DVR1 255.255.255.255 outside

global (outside) 1 X.Y.Z.230
global (dmz1) 1 interface
nat (inside) 0 access-list inside_outbound_nat0_acl
nat (inside) 1 192.168.1.0 255.255.255.0 0 0

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto map outside_map 30 ipsec-isakmp

crypto map outside_map 30 set peer A.B.C.D <--- (public IP of customer device)

crypto map outside_map 30 match address centura_map_30

crypto map outside_map 30 set transform-set ESP-3DES-MD5

crypto map outside_map interface outside

isakmp key ******** A.B.C.D netmask 255.255.255.255 no-xauth no-config-mode

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 86400

My hope was that anything on the 192.168.1.0/24 would be able to go out the outside interface as our one of our public IPs (i.e. X.Y.Z.230) but the traffic they're seeing on the other end is coming from the 192.168.1.0 network.  I tried removing the inside_outbound_nat0_acl line thinking that it would then use the global but still not having any luck and the only difference I can see on Kiwi Syslogd is that the src_proxy changes to 0.0.0.0 where is has been showing my private side IP address (for the purposes of the config above we'll call it 192.168.1.135).

MANY THANKS FOR ANY HELP!

-Mario

I have this problem too.
0 votes
Correct Answer by Federico Coto F... about 6 years 8 months ago

Hi,

For example, you can NAT the traffic from your internal network through the tunnel when going to this customer.

In this way, they will see your internal network as a single IP.

Let's say, instead than they seeing your internal 192.168.1.0/24, tthey will see your traffic as X.Y.Z.227

Is this what you need?

Federico.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Federico Coto F... Thu, 04/08/2010 - 15:13

Hi,

For example, you can NAT the traffic from your internal network through the tunnel when going to this customer.

In this way, they will see your internal network as a single IP.

Let's say, instead than they seeing your internal 192.168.1.0/24, tthey will see your traffic as X.Y.Z.227

Is this what you need?

Federico.

Mario Ramirez Thu, 04/08/2010 - 15:50

Federico,

Yes, I think that's exactly what I need!  How can I do this?  Do I just remove the line from my ACL that is currently telling it not to NAT:

access-list inside_outbound_nat0_acl permit ip 192.168.1.0 255.255.255.0 Cust_DVR1 255.255.255.255

After removing that should my traffic be NATed, or do I need to adjust my crypto map as well so that it sees the traffic as interesting:

access-list centura_map_30 permit ip 192.168.1.0 255.255.255.0 Cust_DVR1 255.255.255.255

and change it to:

access-list centura_map_30 permit ip X.Y.Z.227  255.255.255.0 Cust_DVR1 255.255.255.255

Thanks again!

-Mario

Federico Coto F... Thu, 04/08/2010 - 16:12

Exactly.

You need to make sure that your traffic is NATed (removing the nat 0 access-list statement).

Then, specify the access-list for crypto map to be from the public IP to the other's side network.

Federico.

Mario Ramirez Thu, 04/08/2010 - 18:38

Federico,

Thanks so much for the help, I'm edging closer to the solution I now get an ACL error showing:

IPSEC(sa_initiate): ACL = deny, no sa created

I don't have any rules stopping anything on that interface -- although it is the global NAT that everything else sits behind.  Would it deny it for this reason?  Am I not allowed to use the global as a host in my ACL?  I'm sure I could create a static route between one of our public IPs X.Y.Z.50 and just route traffic from a workstation in our 192.168.1.0 network to that, but I hate limiting access to 1 PC and giving up one of our public IPs at the same time )

THANKS AGAIN!

-Mario

Federico Coto F... Thu, 04/08/2010 - 19:05

Sounds to be a problem with the interesting traffic.

Remember that if you do change the interesting traffic on your side, you must exactly mirror the change on the other end. (otherwise the interesting traffic will not match).

Have you done this?

Federico.

Mario Ramirez Thu, 04/08/2010 - 19:58

Federico,

I just did a reload to get back to my startup config and pasted in the VPN stuff again and it's all up and working, I'm sure there was just a problem with me adding and removing my cryptomap ACLs for interesting traffic because it's working fine now!

THANK YOU SO MUCH FOR YOUR HELP!  I've been working on this so long, and as educational as it's been, it's been equally frustrating

Again, thank you very very much!

-Mario

Actions

This Discussion