NAT-T help

[Maro.Cisco]

                   Dears , im having the below setup and i want to implement IPSEC LAN to LAN VPN so please correct me if im wrong :-

Server----VPN Concentrator(outside private ip:y.y.y.y)------PIX( outside public ip : x.x.x.x)-------Internet-------Remote Site

My question since the vpn configuration will be made on the VPN concentrator and remote site will be using my public ip as vpn peer (x.x.x.x)

1) in this case i'll need to enable NAT-T on the VPN concentrator since all my internal ip address (y.y.y.y) are being PAT to the x.x.x.x

2) after enabling nat-t ESP will be encapsulated into UDP with port 4500

3) do i need to force the remote site to have the NAT-T enabled too and if not would that make any problem in estabilising the tunnel

4)do i need to create access-list on the PIX to allow port 4500.

Thanks

[Andrew Phirsov · Accepted solution]

1) NAT-t will work by itself. It's done by vpn-endpoints by comparind NAT-D payloads with actual IP headers of IKE packets (MM3,MM4 / AG1, AG2 packets). If there's NAT device between the peers, they'll find it out and enable NAT-T automatically. So i don't thik you'd have to configure anything manually (and, as far as I know, it's not possible to enable NAT-T manually at all).

2) Yep, that's right.

3) I don't know what device you have on the opposite site of a tunnel, but most probably you won't have to enable there anything either, like in the 1).

4) It depends on who is the initiator of a tunnel. If VPN-concetntrator at your site is the initiator, it'll first start exchenge through 4500/udp, so returning packets to this port will be inspected - in this case u won't need to allow 4500 in the outside-in ACL. If the oposite VPN-gateway works as initiator, then yes, you'd have to allow 4500/udp in the ACL.

[Maro.Cisco]

Thanks andrew , one more question traffic going thru the VPN tunnel , does it have source ip address of public ip or the private one ???

[Azubuike Obiora]

Hi Marco,

Well I want to believe you mean the traffic originating from your inside network traversing your vpn tunnel, If yes thats what you mean?.....Then it's the Local IP

The public IP is for your router to know its VPN peer. Once the Local IP hits the your router's public IP interface....the crypto map statement there would tell the router if the traffic is a VPN traffic or it's just a normal traffic like you nat traffic.

I hope this helps out?

Have a good one.

Cheers

[Maro.Cisco]

i think that traffic will have a source ip address of local private IP and destination of remote private ip till it reaches the public IP interface then crypto map statment will tell the router if its vpn traffic or just normal , if its a vpn traffic the local public VPN IP is added to the packet as source ip address and the remote public VPN IP peer will be added to the packet as destination ip address and packet will be sent thru the tunnel , once it arrive at the other end the PUBLIC IPs(Source and destination) is removed and then the packet is forwarded using the private source ip and private destination ip. Please correct me if im wrong

[Azubuike Obiora]

Hi Marco,

You are right! just something like this below for clearification since you are using a pix

access-list VPN-TRAFFIC permit ip 192.168.200.0 255.255.255.0 172.16.30.0 255.255.255.0

in this case 192.168.200.0/24 is your local ip while 172.16.30.0/24 is your remote ip. Your remote will have the reverse of this access-list on its device 

access-list VPN-TRAFFIC permit ip 172.16.30.0 255.255.255.0 192.168.200.0 255.255.255.0

Your crypto map configuration would look something like this

crypto map outside_map 5 match address VPN-TRAFFIC

crypto map outside_map 5 set pfs group1

crypto map outside_map 5 set peer 11.11.11.11 ( assuming this is the public ip of your remote side)

crypto map outside_map 5 set transform-set ESP-AES-MD5

crypto map outside_map interface outside

so once the traffic hits your side the other side, the remote side will definitely see the traffic encrypted and do the needful.

Cheers

Teddy