Re: DMVPN with NAT

bdedek · ‎06-06-2003

Hi,

I have several site-to-site VPNs using Cisco IOS software. My main VPN hub is a 3640 that sits behind our firewall (no Cisco). I have the firewall setup to do a static NAT to the VPN router behind it. I allow only IPSEC (ISAKMP + ESP) through. Remote sites also have various routers behind NAT devices.

I want to implement DMVPN, but was told some time ago that it was not compatible with NAT. I was recently told that DMVPN and its incompatibilities with NAT, CSCdz54453, were resolved in 12.2.15T. I have setup a similar config in a lab environment using 12.3.1, and am still having the same problems as before.

The tunnel negotiations fail with: IPSEC(validate_transform_proposal): proxy identities not supported. This is because the IPSEC proposal is using the true IP of the router and not it’s public NAT. This is usually solved within the crypto map where you specify the internal IP when defining your access lists. However, DMVPN uses crypto profiles instead of crypto maps, and they do not support access lists. If anyone knows how to get around this limitation, I would sure appreciate it.

Thanks,

Billy

gfullage · ‎06-09-2003

Doesn't actually look like this bug was resolved in 12.3(1), you might want to try 12.2(15)T in your lab and see if it works. I don't believe there's any configuration workaround for this, the IOS just has to be made to work with NAT-T and that's currently only in certain versions of code. Let me know if it doesn't work and I'll set it up in the lab and see what's going on.

bdedek · ‎06-09-2003

Thank you, I will back rev to 12.2(15)T and try again.

Thanks again for your help.

Billy

bdedek · ‎06-10-2003

Sorry, that didn't work either. I tried 12.2(15)T2 on both ends. CCO recommened T2 over base ios. I am still getting the same error. Is this even a supported configuration? I think I will open a TAC case and see what happens.

Thanks.

gfullage · ‎06-10-2003

OK, thanks for trying. Go ahead and open a TAC case to get an official answer, I'll build it in the lab here also and see what I can come up with.

gfullage · ‎06-10-2003

OK, I get the same thing here. I played around with setting the NHRP maps to the NAT address, even created a loopback on the hub with the same IP address as the NAT'd address and then made that my tunnel source, didn't help. The bug you mentioned initially is a little different to what you're running into here though which is why your still seeing the problem even in code that has this bug fix. The bug dealt with the spokes still connecting to the actual hub address, they were just going through a NAT device in between and so negotiated UDP port 4500. In your scenario you're not actually connecting to the hub router's configured IP address, so there's always going to be trouble.

To be honest I don't think there's a good answer for this, but I've sent an email to the developers and will see what they have to say.

bdedek · ‎06-11-2003

Thanks for helping out. I went ahead and opened a case yesterday. Brian Richins has taken it up and is looking into it. He has the configs and debugs.

Thanks again.

Billy

ddawson · ‎10-23-2003

Did you ever get a resolution to this? I've been trying to get DMVPN working with a spoke router behind a PIX and it appears that NHRP imbeds the local pre-NAT address in its packet(s) and mGRE uses that address instead of the post-NAT address fromthe headers when it configures that endpoint. If there's a fix or a workaround, or even a definitive statement that it doesn't work, I'd love to hear it.

Thanks!

bdedek · ‎10-23-2003

Hi, I understand your pain on this. After visiting with TAC a few times, they never really came out and said that it wouldn't work, but I nor they could ever get it to work behind NAT devices. So the answer is it doesn't work. I had to stick to my original design and do it the old way.

Billy