Site To Site VPN Issue (NAT?)

Unanswered Question
Apr 18th, 2008
User Badges:

Hello All,


I have been reading some of the post about Site to Site VPN with overlapping subnets. I could use a little guidance or further explanation to understand this a bit more. To start off here is the scenario. We have a VPN established with a vender of ours and they need access to several different hosts on several different subnets.


Subnets:


140.x.x.x

141.x.x.x

10.10.20.x


Our vender already has another VPN established with another customer that uses the 10.10.20.x subnet.


As it stands the vender only needs to access two different host (10.10.20.28 & 10.10.20.29)


I setup a NAT for each:

10.10.20.28 => 10.9.220.28

10.10.20.29 => 10.9.220.29


When they go to access this via the VPN I see the following show up when doing a debug:


IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) dest= 10.10.8.10, src= 12.129.5.3,

dest_proxy= 10.9.220.28/255.255.255.255/0/0 (type=1),

src_proxy= 172.17.1.91/255.255.255.255/0/0 (type=1),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4

IPSEC(validate_transform_proposal): proxy identities not supported

IPSEC(validate_proposal_request): proposal part #1,

(key eng. msg.) dest= 10.10.8.10, src= 12.129.5.3,

dest_proxy= 172.17.1.91/255.255.255.255/0/0 (type=1),

src_proxy= 10.9.220.28/255.255.255.255/0/0 (type=1),

protocol= ESP, transform= esp-3des esp-md5-hmac ,

lifedur= 0s and 0kb,

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4

IPSEC(validate_transform_proposal): proxy identities not supported


Please note access to the other host on the other subnets works with out issues, it is just access to the two host in the overlapping - any help?


Thanks,

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
cisco24x7 Fri, 04/18/2008 - 06:46
User Badges:
  • Silver, 250 points or more

Before I answer your question, keep in mind that I am not an expert in this

but I've worked quite a bit with NAT, double-NAT on Checkpoint firewall platform.

I am also familiar with Cisco platforms but not as well compared to Checkpoint

firewall platforms.


The vendors needs to put 10.9.220.28 and 10.9.220.29 in his remote encryption

domain. He knows nothing about your 10.10.20.28 and 10.10.20.29 on your end

nor should he care. When he initiates traffics from his end from host x.x.x.x

going to the destination of 10.9.220.28 10.9.220.29. So far, so good.


Now when the traffics get to your destination, after the traffics get

decrypted, your vpn device is responsibe for "de-nat" the destination

from 10.9.220.28 to 10.10.20.28 and 10.9.220.29 to 10.10.20.29.


Now the return traffics from 10.10.20.28 and .29 going back to vendor x.x.x.x

will be natted to 10.9.220.28 and .29, repsectively.


In summary, it will look like this, I will use Checkpoint terminology because

it is so much easier than checkpoint


Source Destination Translated-source Translated-dest.

x.x.x.x 10.9.220.28 & .29 original 10.10.20.28 & .29

10.10.20.28 & .29 x.x.x.x 10.9.220.28 & .29 original


It is a very simple process, if you think about this. What makes it hard

is all the stupid security level that cisco put on the interface. Because

of this, you have to takes into account policy NAT which is a pain in the ass

to configure. If you're not careful, you can cause a network outtage.


Does that help?

ldehmer Fri, 04/18/2008 - 06:52
User Badges:

Well, it just so happens the vender we have the VPN with is using checkpoint…


I will see what we can puzzle out from here and come back…


Jon Marshall Fri, 04/18/2008 - 07:19
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

David is spot on with this.


"IPSEC(validate_transform_proposal): proxy identities not supported"


This basically means that the remote and local subnets that your pix thinks it is using do not agree with the local and remote subnets that your vendor thinks they should be using


so preusmably you have a crypto map access-list that says


access-list vpntraffic permit ip host 10.9.220.28 host 172.17.1.91


The vendor must have the exact same local and remote network (host) entries on his checkpoint.


Jon

ldehmer Fri, 04/18/2008 - 07:45
User Badges:

access-list outside_cryptomap_20 permit ip object-group GRP-INSIDE object-group GRP-OUTSIDE



I have the subnet on the vender side part of GRP-OUTSIDE and the 10.9.220.29 host part of the GRP-INSIDE

cisco24x7 Fri, 04/18/2008 - 09:23
User Badges:
  • Silver, 250 points or more

The complexity comes in play when you have to

configure VPN and NAT/double-NAT on the same

device. This is a really bad design. It will

make troubleshooting and support very difficult.


The sensible approach is to separate VPN and

Firewall into two different components. That

will make life much easier in term of support

and troubleshooting.


my 2c



Attachment: 

Actions

This Discussion