RDP Issues
-
I have searched through the forums and it doesn't look like this issue has been posted, so here it goes.
We are having issues with RDP ( TCP port 3389 )
What happens is when an RDP Session is initiated that RDP session will connect but all i will see is a black screen. This is occuring both directly to tcp port and through a vpn. So i sniffed out the traffic for a few hosts and I get the following type of message (using wireshark)Source(LAN) Destination(RDP CLIENT) 4998 > 3389 [PSH, ACK] Seq=230 Ack=0 Win=64441 [TCP CHECKSUM INCORRECT] LEN=87
Needless to say RDP to the hosts in question works when bypassing pfsense. Any ideas?
My PFSENSE setup isn't very complex really. I have just WAN LAN ints and a handful of NAT's and VIPs. No traffic shaping. I have the 12-06-2006 snapshot installed. I have about 2500 states @ around 15mbit. I am not sure where to go from here. Thanks for the assistance.
-
Might be an mtu issue. Try lowering mtu at WAN to something very conservative like 1300. If it works then go up in steps until it breaks and then one step back. I'm using rdp through ipsec frequently without any issues.
Btw, the tcp checksum incorrect can be an indiciation of checksum offloading of the nic. It's a feature that takes some load away from the cpu. In this case you will see these kind of messages in wireshark (I think wireshark even notes that this might be due to tcp checksum offloading). Nothing to worry about if this is the case.
-
If you are seeing checksum mismatches then the hardware of your card is telling pfSense that it will do this but FreeBSD has an issue with it. I would change the nics to something a bit more reliable such as Intel.
-
Thanks for the quick replies, you guys rock, seriously.
I tried bumping my MTU clear down to 1000 and still no success. I just happened to stumble upon 3 Intel PRO 1000 GT's just now, such a coincidence! Its a miracle really because we have 3com everywhere. I will try installing one and hope for the best.
oh and for the record i did also try from home and it is also behind a pfsense wall and i can hit each of these sites just great. I will post back in a bit.
-
Ive got the new intel in the box now, making them both intel pro 1000's, and have been testing all the MTU settings and multiple hosts on the LAN, but nothing has changed. Any ideas?
-
try tracing from one end to the other and vice versa. do both directions take the same route?
-
They are going through the same networks, the addresses vary slightly, but i think that is normal.
-
I have been able to spend a little more time troubleshooting and have found that when going –---> pfsense -----> pix that my pix reports an mss exceeded error. Apparently this is caused because the Maximum Segment Size is changing or not matching what it is supposed to be, so the pix drops the packets. I am still leaning towards this being an issue with pfsense since I can get to this sever when bypassing pfsense. I appreciate the help hoba and sullrich :)
-
What's the exact log message you're seeing from the PIX?
I've never had this issue with a number of PIX's, but I also don't need MSS clamping since my WAN is 1500 MTU.
-
Yeah sure, no prob. Here it is.
Dropping TCP packet from outside:xx.xx.xx.xx/3389 to inside:xx.xx.xx.xx/60983, reason: MSS exceeded, MSS 1260, data 1460
MTU on every interface on the pix is also set to 1500
-
You can solve your problem by issuing the commands listed in this link:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a00804c8b9f.shtml
However, the above link is not a true fix. Can you give a better diagram or description of how you have your network configured? Also perhaps a 'sh run', minus sensitive stuff, from your pix and a list of nat's and firewall rules from pfsense as well.
-
I actually tried that cisco workaround already and it didn't help at all. :(
My network looks like this
Private LAN (10.x.x.x) –----> PFSENSE (2x Intel PRO 1000) ------> "DMZ" (172.x.x.x) ---------> PIX --------> Internet
I am doing Dual NATing. Ex: Internet TCP 21 ------> PIX forwards to -------> PFSENSE forwards to ------> Internal FTP Server
NATing 21, 25, 80, 143, 443, 1723, GRE
I have various VIPs as well, so that hosts in the DMZ can send traffic to a host that no longer sits in the dmz, so pfsense forwards to the new 10.x.x.x address. I have not configured carp yet as I still have some issues I want to iron out. If you need any more info, let me know. I appreciate your help a ton though. Thanks. :)
Show run from my pix would be a very large pain, as it is about 12mb of text and would take ages to filter out sensitive info, but if it is absolutely needed, I can do it. So essentially, when I am in the DMZ and try to RDP, vpn or anything else so some host, I can get to the host as expected, but when i put myself behind pfsense is when it starts to cause problems. Again this is only an issue with a handful of sites, but anytime VPN is used, all kinds of weird things happen, like cant copy files over vpn, cant rdp over vpn, and sometimes it works fine. I am baffled.
-
So you are having issues connecting from your LAN segment to hosts on your DMZ segment when going through the pfSense?
-
LAN to Internet hosts, sorry if my explanation was kinda hard to understand.
-
K, are you able to connect to Host on the DMZ segment from your LAN Segment?
-
yes
-
Well, I'm not positive what is going on, but I know the MSS feature in PIX's is new to the 7.0 version.
pfSense, as of right now, does not do any MSS filtering like the pix. The MSS values should remain unchanged as they pass through the pfSense. Negotiation of the MSS value should also work properly through the pfSense.
I have to say that, since you are able to connect to the DMZ segment from the LAN segment, the pfSense is working as it should.
That MSS fix should work. If you are running 7.2, and you've tried it the previous fix, try using the ADSM to look for the checkbox about the MSS default deny. I can't remember where it was under the ADSM, but there is a checkbox that says something like 'allow MSS exceeded values.'
The only thing that I can surmise is that maybe a router might be throwing off the MSS.
-
Maybe this thread isn't active any more. But I could report that I have the same problem.
RDP Client -(PPTP)-> fpSense 1.2 -(PPTP)-> Corp. Firewall –> Terminal Services / Remote Admin
I also just get a black screen connecting to machines on the other side. But, If start one more RDP-Client and try to connect to the same host, at the same time the first started show a black screen, I can connect. Strange, but it works.
Haven't sniffed any traffice on this one. But may the above info can help out resolve this problem.
-
Maybe this thread isn't active any more. But I could report that I have the same problem.
RDP Client -(PPTP)-> fpSense 1.2 -(PPTP)-> Corp. Firewall –> Terminal Services / Remote Admin
I also just get a black screen connecting to machines on the other side. But, If start one more RDP-Client and try to connect to the same host, at the same time the first started show a black screen, I can connect. Strange, but it works.
Haven't sniffed any traffice on this one. But may the above info can help out resolve this problem.
i have the same issue like you discribed. I think its because of my VMWARE Setu, i have installed pfSense inside a VM and this coused the problem. But if you have a real machine for pfsense, i think its an pfsense fault.
is there anything to get a fix? Does someone know where or what rdp get blcked?!
i'll try to help as much as i can - someone hast to say me what i can do :)
thx,
sash
sash(at)gmx.it
-
I had this problem before. It was caused by the MTU on one end being to big to "fit" at the other end
Network looks like this
Pfsense(ethernet - mtu 1500) -> internet -> (ADSL mtu - 1462)PfsenseWhat I had to do was reduce the mtu on the ethernet side ie
Pfsense(ethernet - mtu 1412) -> internet -> (ADSL mtu - 1462)PfsenseMy problem was exaggerated by running the rdp through an IPSEC tunnel that adds extra overheads so you may not need to reduce your mtu so far
