|
Posted by Darren on April 25, 2008, 10:20 am
If you were Registered and logged in, you could reply and use other advanced thread options
> On 25 Apr, 15:24, musik...@gmail.com wrote:
>> Hi all,
>> my company already has a pair of routers (3725) at head office
>> and several branch sites using 1801s. The small branches use ADSL and
>> hence have public fixed IP addresses. Three are the usual GRE tunnels
>> encrypted with IKE/IPSEC. The 1801s use Transport Mode (not Tunnel
>> Mode).
>>
>> What I've been asked is, if a mobile branch could be put together. The
>> same 1801 will be used with the same encrypted GRE tunnel but it will
>> be behind an ADSL router and so NAT'd. I know I have to configure NAT
>> traversal and have read
-http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htmipmar.html#wp105...
>> My question is, can I enable NAT traversal on the head office without
>> affecting other tunnels that don't require it?
>>
>> Alternatively, I know that Nokia VPN boxes (Sadly dicontinued) and
>> ASAs can use a management proxy for dynamically addressed sattelite
>> nodes. Can this also be done with Cisco boxes?
>
> My (very limited but perhaps sufficient in this case) understanding
> is that NAT-T is "negotiated" (or maybe discovered is better?) if
> enabled
> and will not affect non NATed links.
>
> I am sure this it works OK since I have some Pixes doing that
> at present.
>
> If you do not know the IP address of the remote site in advance
> you may have to use DMVPN.
>
> Whether the 3725 will run a sufficiently recent IOS
> to have DMVPN I don't know.
>
> Here is a pix (6.4) doing NAT-T (udp encaps) and non NAT-T
>
> sh cry ip sa | inc settings|peer
> current_peer: x.x.x.22:500
> in use settings ={Tunnel, }
> in use settings ={Tunnel, }
> current_peer: x.x.x.74:4500
> in use settings ={Tunnel UDP-Encaps, }
> in use settings ={Tunnel UDP-Encaps, }
> current_peer: x.x.x.24:500
> in use settings ={Tunnel, }
> in use settings ={Tunnel, }
NAT-T is definitely negotiated. A vendor ID string that is sent /
received by the hosts as part of the VPN setup determines if NAT T is
supported by the Hosts. Then I seem to recall a HASH is done on a test
packet which the sender / receiver use as a comparison to see if the
packet has changed in transit. If it has then the hosts know there is a
NAT device in the middle. If not everything carriers on regardless.
So long ago since I read up on this but enabling NAT-T shouldn't break
anything.
Regards
Darren
| 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map