«

Hi all,

I have a problem where port address translation kills connectivity to port
3389 through the ipsec tunnel. The Ipsec VPN has been built via cisco 837
routers. Each router connects to the internet.

Currently all remote sites normally connect to head office via an internet
Cisco 837 IPSEC VPN. All remote sites are able to use terminal services,
port 3389, through the IPSEC VPN.

However as soon as I place the command......... ip nat inside source static
tcp 10.0.0.3 3389 interface Dialer1 3389........ on the router, sites that
would normally connect to the head office via the IPSEC VPN on port 3389
loose connectivity. But, then find that they are able to connect back to
head office on port 3389 via the internet!!!!

Unfortunately I really need to be able to provide two means of connecting to
head office via terminal services, one through the IPSEC VPN and secondly
via the internet PAT should I be at home and someone needs me to dial in so
to speak..

All help would be greatly appreciated

Todd

In article <d9o3s6$2f7$>, Todd <> wrote:
:I have a problem where port address translation kills connectivity to port
:3389 through the ipsec tunnel.

:Currently all remote sites normally connect to head office via an internet
:Cisco 837 IPSEC VPN. All remote sites are able to use terminal services,
ort 3389, through the IPSEC VPN.

:However as soon as I place the command......... ip nat inside source static
:tcp 10.0.0.3 3389 interface Dialer1 3389........ on the router, sites that
:would normally connect to the head office via the IPSEC VPN on port 3389
:loose connectivity. But, then find that they are able to connect back to
:head office on port 3389 via the internet!!!!

I don't know the equivilent in IOS at the moment, but on the PIX
the way to handle this would be to add a "NAT exemption" for the
flow. The format in the PIX would be to create an access list
defining what should NOT be NAT'd and then to

nat (inside) 0 access-list ACLNAME


Your problem is that the ip nat static that you are doing is always
applying, so the packets returning towards the remote sites are
having their source IP's NAT'd to the Dialer1 interface IP. That might
cause them to fall out of the definition of the IPSec tunnels
(which is probably defined in terms of the -internal- IP address
instead of the interface IP address).
--
Oh, to be a Blobel!

Hi Todd

I think when you are doing PAT mapping your traffic is not included in
Ipsec tunnel access-list .
Make dialer interface ip address as source in interesting traffic on
hub rtr and as destination on remote rtrs .
Add this one access -list string to ur existing crypto acl .

HTH
SH

Hi ,

You will have to bypass static Nat/PAT on the router by making a
loopback 0 and throwing traffic ( terminal seerver private ip to remote
networks ) around it .
cisco site has good example for how to bypass static nat using
route-map for Ipsec traffic .

HTH
SH

Hi Sarabjit,

Well I have managed to find out how to fix this problem.

I had to add a route map to the nat translation

ip nat inside source static tcp 10.0.0.3 3389 XXX.XXX.XXX.XXX 3389 route-map
rdp extendable

route-map rdp permit 10

match ip address 145

access-list 145 deny ip 10.0.0.0 0.0.0.255 192.168.1.0 0.0.0.255

access-list 145 deny ip 10.0.0.0 0.0.0.255 192.168.0.0 0.0.0.255

access-list 145 permit ip 10.0.0.0 0.0.0.255 any

But I also found out that you also have to make sure that you apply the nat
rules in the specific order because like access-lists they work top down..
How I found this out was my blocknat route map was not working to allow
traffic to go out to the internet be natted. What I took this nat statement
off and put it back on placing at the top everything started to work
again!!!

Ahhh I love a good outcome!!!!!