RDP thru Cisco VPN client and thru 501 Failure
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
|||||||||||||
|
Posted by on August 5, 2008, 3:52 pm
Please log in for more thread options net. We use our laptops and the Cisco VPN client to connect up to a Cisco VPN Appliance in a data center and MS=92s RDP to connect up to our servers. This setup works perfectly. We use a PIX 501 from our office to connect to the net. The VPN Client connects up to the applicance just fine. However, RDP will not connect up to our servers. We are using a 172.16.1.x sub net within the data center. In the office, we just a 192.168.4.x subnet. Anyone have any other ideas that might explain this failure? Thanks in advance. (Our =91expert=92 who setup all these is unable to explain it) | |||||||||||||
|
Posted by Artie Lange on August 5, 2008, 4:11 pm
Please log in for more thread options What is the DHCP pool you use for your clients? Do your clients receive an IP from a differnet pool depending where they connect from or who the user is? Do you have any ACL's defining RDP traffic? Can you browse the servers file systems? Do you have firewall enable on the server? | |||||||||||||
|
Posted by Merv on August 5, 2008, 4:39 pm
Please log in for more thread options > curtta...@gmail.com wrote:
> > From home, we use plain old home Netgear routers to connect up to the
r
> > net. We use our laptops and the Cisco VPN client to connect up to a > > Cisco VPN Appliance in a data center and MS=92s RDP to connect up to ou= > > servers. This setup works perfectly. We use a PIX 501 from our office
> > to connect to the net. The VPN Client connects up to the applicance > > just fine. However, RDP will not connect up to our servers. We are > > using a 172.16.1.x sub net within the data center. In the office, we > > just a 192.168.4.x subnet. Anyone have any other ideas that might > > explain this failure? >
> > Thanks in advance. (Our =91expert=92 who setup all these is unable to
> > explain it) >
> What is the DHCP pool you use for your clients? > Do your clients receive an IP from a differnet pool depending where they > connect from or who the user is? > Do you have any ACL's defining RDP traffic? > Can you browse the servers file systems? > Do you have firewall enable on the server? RDP packets cannot be fragmented. RDP sets the do-not-fragment bit in its TCP packet so do a path MTU discovery manually using ping. Start with a ping packet length of 1500 and reduce until you have successful ping. ping -l 1500 -f <IP address>
Can the VPN clients ping the servers in question - i.e confirm there are not other connectivity issues If they can ping sucessfully then determine the largest MTU that the client can use with no-fragment set Adjust you NIC to use the discovered maximum path MTU size Then set that MTU size on the VPN client and see if RDP connectivity is possilbe | |||||||||||||
|
Posted by on August 6, 2008, 6:33 am
Please log in for more thread options
>
> > > > > > curtta...@gmail.com wrote:
> > > From home, we use plain old home Netgear routers to connect up to the
our
> > > net. We use our laptops and the Cisco VPN client to connect up to a > > > Cisco VPN Appliance in a data center and MS=92s RDP to connect up to = > > > servers. This setup works perfectly. We use a PIX 501 from our office
> > > to connect to the net. The VPN Client connects up to the applicance > > > just fine. However, RDP will not connect up to our servers. We are > > > using a 172.16.1.x sub net within the data center. In the office, we > > > just a 192.168.4.x subnet. Anyone have any other ideas that might > > > explain this failure? >
> > > Thanks in advance. (Our =91expert=92 who setup all these is unable to
> > > explain it) >
> > What is the DHCP pool you use for your clients?
y
> > Do your clients receive an IP from a differnet pool depending where the= > > connect from or who the user is?
> > Do you have any ACL's defining RDP traffic? > > Can you browse the servers file systems? > > Do you have firewall enable on the server? >
> RDP packets cannot be fragmented. RDP sets the do-not-fragment bit in > its TCP packet > so do a path MTU discovery manually using ping. > > Start with a ping packet length of 1500 and reduce until you have > successful ping. > > ping -l 1500 -f <IP address> > > Can the VPN clients ping the servers in question - i.e confirm there > are not other connectivity issues > > If they can ping sucessfully then determine the largest MTU that the > client can use with no-fragment set > > Adjust you NIC to use the discovered maximum path MTU size > > Then set that MTU size on the VPN client and see if RDP connectivity > is possilbe- Hide quoted text - > > - Show quoted text - Isn't there an easier way. This seams real complicated. Maybe we should just dump this fancy firewall that prevents us from working. | |||||||||||||
|
Posted by Artie Lange on August 6, 2008, 7:35 am
Please log in for more thread options
curttampa@gmail.com wrote: > Isn't there an easier way. This seams real complicated. Maybe we
> should just dump this fancy firewall that prevents us from working. Well if it works from one location, it most likely is not an issue with the firewall. The connection at your office, as Merv pointed out, may use a MTU that is different than the other location you are connecting from. If your idea is to dump the firewall for another solution, that is completely up to you, *BUT* for an hour of diagnosis time you could probably have an engineer look at and fix the issue. | |||||||||||||
> net. We use our laptops and the Cisco VPN client to connect up to a
> Cisco VPN Appliance in a data center and MS’s RDP to connect up to our
> servers. This setup works perfectly. We use a PIX 501 from our office
> to connect to the net. The VPN Client connects up to the applicance
> just fine. However, RDP will not connect up to our servers. We are
> using a 172.16.1.x sub net within the data center. In the office, we
> just a 192.168.4.x subnet. Anyone have any other ideas that might
> explain this failure?
>
> Thanks in advance. (Our ‘expert’ who setup all these is unable to
> explain it)