Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

RDP disconnects to DMZ after VPN innitialized 1

Status
Not open for further replies.

speedingwolf

IS-IT--Management
Jan 23, 2003
65
US
Good day,

I'd greatly appreciate it you could point out some insights regarding to my VPN, DMZ, and RDP issues.

We have a business partner that allows us to VPN to their corporate office. The VPN client does not work from our internal net unless I set up a static NAT from our public IP address to inside address and give access list to the interface. However, this solution is "unacceptable" by the senior network. So, they recommend that I put 3 computers in the DMZ and have static NAT from outside to DMZ and have inside engineers to RDP to these clients and work. The concept sounds great. However, i do not understand the following problem:

1. Users from inside 10.0.0.x network and go to these three XP boxes in network 192.168.0.0 and able to RDP using terminal service client.

2. As soon as the start the VPN client, their RDP is disconnected.

3. When I brought that same computer into our intranet with 10.0.0.x, users can RDP to it after they innitialized the VPN client.

I know i have to do something with the PIX, but at this point, i don't understand the logics.

Please help.

Thanks,

mixa
 
HI.

2. As soon as the start the VPN client, their RDP is disconnected.
This is probably because of the "split-tunnel" downloaded from the remote VPN server.
Or if no split-tunnel is configured on remote VPN server, then all traffic goes via the VPN tunnel, and that is why the VPN client tries to tunnel also the traffic to inside 10.0.0.0 that should have been NUT tunneled.

You can initiate VPN connection from the box and double-click the yellow icon to see what is going on.

> 3. When I brought that same computer into our intranet with 10.0.0.x, users can RDP to it after they innitialized the VPN client.
The difference from previous situation is that now 10.0.0.0 is considered "Local LAN access" from the VPN client point of view.


Possible solutions:

* An alternate solution for you is to purchase a hardware VPN client 3002 from Cisco. This can act as a "VPN proxy" for your workstations.

* Contact the remote VPN server administrators, and ask them to define split-tunnel. If this is against their policy, you may ask them to define a new "vpngroup" for you with split-tunnel.

* Contact the remote VPN server administrators and check for other options, like site to site VPN, or simply using IP address based access rules instead of VPN.

* There are other possible solutions - try to be open minded and consult with remote VPN server administrators.
(But your solution is also a good one after you fix the problems).


Yizhar Hurwitz
 
Hello Yizhar,

Thank you very much for your help. I really appreciated it. I'm curious in this issue. Is it really risky to have Static NAt from outside to inside and have access list for UDP and ISKMP prototols to go inside so we could establish vpn to the vendor intranet? Or does this DMZ setup is a pain in the neck?

thanks,

Mixa
 
HI.

> Is it really risky to have Static NAt from outside to inside and have access list for UDP and ISKMP prototols to go inside so we could establish vpn to the vendor intranet?

You can specify in your ACL to permit UDP 500 (ISAKMP) + IP 50 (ESP) protocols from the VPN server:
access-list ??? permit udp host x.x.x.x host y.y.y.y eq 500
access-list ??? permit esp host x.x.x.x host y.y.y.y
(You can also use "any" instead of "host y.y.y.y")

It is not so risky.
EMail attachements, Kazza/ICQ, and HTTP links are much more dangerous...


Yizhar Hurwitz
 
Yizhar. Thank you very much for your help. I think I will have a site to site VPN terminate at our DMZ network and let these workstation VPN into the vendor network and allow my inside network RDP to this DMZ. It sounds like an idea but i don't know how to set this up yet. Need to do more reading...

Mixa
 
HI.

I didn't realy understand the last idea, but it does not seem like a good one in first reading because:
It looks like a complex solution.
Remote access VPN is better then Site to Site for your case because traffic over Site to Site can be initiated from the other side as well.

Have you considered purchasing a hardware Cisco 3002 VPN client?


Yizhar Hurwitz
 
Hello Yizhar,

We have 2 PIXes (failover) 516 with 4 ports. Inside, Outside, DMZ, Vendor Net.

DMZ has web, ftp, etc., servers. Vendor Net has only one computer. So, after discussion with the IT Director's "friend" who is the "expert" in security, he recommended that we should make use the PIX 515 Vendor interface as a Site-to-Site VPN termination point for our vendor. Then put 3 or 4 computers in this Vendor Net, since this network will have an 24/7 tunnel establish to the customer's site, and let them work in there. Users from our inside network will RDP to this Vendor Net and work within this controll environment. If he or she needs to upload or download to these workstations, then an access-list allows only these workstation to go in and out from inside network to the Vendor Net.

The reason for this PITA is that senior network management does not like the idea to have site to site from vendor to inside network. They afraid that our customer could browse our internal network via this VPN tunnel. By using our vendor net, we "could" eliminate this browsing. That's the theory. That's why I asked you earlier is it insecure to have UDP and ISMP open. This the 2 porst i have openned on the FW:

access-list 100 line 12 permit esp host 200.189.26.x host 32.72.82.x (hitcnt=517)
access-list 100 line 13 permit udp host 200.189.26.x host 32.72.82.x eq isakmp (hitcnt=0)

Then, i have a static mapping between our outside public IP address to inside private network.


I agree with you that it is complex. And bugget is limited.

Thanks,
Mixa

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top