Eric
asked on
very weird networking issues.. related to MTU?
RDP does not work though vpn. i was told it was MTU. client packet with vpn overhead was above max size allowed by there dsl provider?
on the day i tested chanign it, rdp started to go through (made it 1450 on my firewall endpoint) client side firewall does not have a setting.
however it was so slow! and here is the weird part. when i typed, it would scrable what i typed.
if i keyed in 123456789123456789 I would get back something like 12356879124456789
notice alll keys are there, just scrambled. this was the logon window via rdp.
i dont even know what to say.. or where to begin. before i dig in much more, maybe someone can give me a clue?
on the day i tested chanign it, rdp started to go through (made it 1450 on my firewall endpoint) client side firewall does not have a setting.
however it was so slow! and here is the weird part. when i typed, it would scrable what i typed.
if i keyed in 123456789123456789 I would get back something like 12356879124456789
notice alll keys are there, just scrambled. this was the logon window via rdp.
i dont even know what to say.. or where to begin. before i dig in much more, maybe someone can give me a clue?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
its not DNS.
i use ip's for testing. i understand the normal networking issues. I see it come into my network from the vpn., just nothing happens.
somewhere I saw something about fragmentation, ill see if i can find that note i made.
I know RDP works via VPN, i have many users doing it everyday. this is a "wierd" issue.
i use ip's for testing. i understand the normal networking issues. I see it come into my network from the vpn., just nothing happens.
somewhere I saw something about fragmentation, ill see if i can find that note i made.
I know RDP works via VPN, i have many users doing it everyday. this is a "wierd" issue.
ASKER
RobWill,
im using a hardware, IPSEC VPN.
I tried adding the value to the registry. when the passwords /user names started coming out in different orders is when I started messing with the MTU.
they are all now back to default.
im using a hardware, IPSEC VPN.
I tried adding the value to the registry. when the passwords /user names started coming out in different orders is when I started messing with the MTU.
they are all now back to default.
ASKER
2006-07-10 12:47:05 Allow 192.168.2.1 192.168.1.3 3389/tcp 1310 3389 0-WAN/IPsec 1-LAN allowed (decrypted packet, SA info: id 0x50be6f2d, mss not exceeding 1400, idle timeout=43205 sec 48 127 (Sitename_VPN-Any-00)
2006-07-10 12:47:05 Deny "remote pub IP" "local pub IP" icmp-Dest_Unreach code(4) 0-WAN Firebox icmp error with data src_ip="local pub IP" dst_ip="remote Pub IP" pr=esp-spi=0x1afd0b85 src_port= dst_port= src_intf='0-WAN' dst_intf='0-WAN' can not match any flow, drop this packet 56 112 (internal policy)
notice my test used the private IP's via VPN, and the ICMP reply went public ips :|
thats odd.
I searched the error code 4 and found this.
Code 4: Fragmentation required, and the don't fragment bit was set in the IP header (ICMP_UNREACH_NEEDFRAG)
Note: the typeing coming out in the wrong order happend with vpn enabled or using a nat redirect not through the vpn.
2006-07-10 12:47:05 Deny "remote pub IP" "local pub IP" icmp-Dest_Unreach code(4) 0-WAN Firebox icmp error with data src_ip="local pub IP" dst_ip="remote Pub IP" pr=esp-spi=0x1afd0b85 src_port= dst_port= src_intf='0-WAN' dst_intf='0-WAN' can not match any flow, drop this packet 56 112 (internal policy)
notice my test used the private IP's via VPN, and the ICMP reply went public ips :|
thats odd.
I searched the error code 4 and found this.
Code 4: Fragmentation required, and the don't fragment bit was set in the IP header (ICMP_UNREACH_NEEDFRAG)
Note: the typeing coming out in the wrong order happend with vpn enabled or using a nat redirect not through the vpn.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
it was fixed by clicking an option " ignore the DF flag" in my ipsec settings on my firewall.
Thanks ecszone, for points and update.
--Rob
--Rob
thnx but you still want to follow the suggestions I had in the link, basically it makes sure that fragmentation doesn't happen!
Cheers,
Rajesh
Cheers,
Rajesh
ASKER
i was trying it on the server and it was not working. we were even using packet sniffers. we went down to 1350 I think.
had packet sniffers the works.. it just wasnt working.
had packet sniffers the works.. it just wasnt working.
hmm.. I'm not sure but that is what is required and exactly what you told your device is to ignore the DF bit and fragment it as necessary...
Cheers,
Rajesh
Cheers,
Rajesh
ASKER
may be something wierd with the firmware i installed when this started to happen?
not sure.
not sure.
Check yur DNS logs and event viewer.
or
You're connection to the internet is slow. 1450 will generally work fine for RDP and VPN but you have to put into consideration other clients on the network, people streaming music, downloading files, transferring files from-to the server. If you server is fairly powerfull you shouldn't have a problem. Check your event viewer and see what kind of errors you are getting and give a little more info.