Site To Site VPN Issue (NAT?)

ldehmer · ‎04-18-2008

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,

cisco24x7 · ‎04-18-2008

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 · ‎04-18-2008

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 · ‎04-18-2008

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 · ‎04-18-2008

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 · ‎04-18-2008

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