I have an X11 client/server port (http://sourceforge.net/projects/xming) running on my XP machine. It is set up to connect to a linux box within my local network. With Comodo disabled (=allow all), the X11 access works properly: I get full X-Windows access from my XP-client to the linux server.
I now set up Comodo IP filter rules as to let X11 traffic (ports 6000 tcp and 177 udp, in/out) pass. Whenever I switched on Comodo (=custom), however, Xming did not get a connection to the linux server any more. The only thing I got to work with Comodo set up like that was the initial X11-handshake sequence through udp port 177 (‘Query’ 177/UDP, ‘Willing’ x/UDP, ‘Request’ 177/UDP, ‘Accept’ x/UDP, ‘Manage’ 177/UDP). I used wireshark on my linux box to figure that out.
I thought it was an IP filter configuration error, so while leaving Comodo in “custom” mode, I temporarily inserted an IP In/Out, Allow all protocols/ports rule as the first filter rule. But even then Comodo kept on blocking X11 traffic. I also played around with other Comodo configurations like disabling intrusion detection or application behaviour analysis. Nothing helped.
Can you please tell me how I have to configure Comodo to let X11 traffic pass?
Here my configuration:
Comodo Firewall Pro 188.8.131.52 (German version)
XP and linux box reside within the same local wireless LAN network. A separate firewall shields the LAN from the internet.
OS: XP SP2 Home Edition; Ubuntu Feisty Fawn 7.04
I am using Admin/root logins on both machines
Other security applications: AVG antivirus free edition, current version, Windows Firewall is switched off.
I would be very happy if you could help me with that.
Have you tried to create a Trusted Zone for your LAN? Also what do the actual blocks say in CFPs Log?
CFPs Log can be Exported to an HTML file by right-clicking on the Log (Activity tab) & selecting Export to HTML. This will export the entire Log to an HTML file. Open the HTML file with your default browser (the one you’re using now) and use a simple click-drag-select Copy ‘n’ Paste to post quoted example Log entries here. Like this (from an old Log of mine)…
Date/Time :2006-08-13 20:33:09
Reporter :Network Monitor
Description: Inbound Policy Violation (Access Denied, IP = 10.35.235.233, Port = MS-ds(445))
Protocol: TCP Incoming
TCP Flags: SYN
Reason: Network Control Rule ID = 3
To tell the truth, I do not really trust my ISP’s preconfigured router/firewall. The firmware is preconfigured and the provider did not provide an update since two years. That’s why I’d rather not implement a trusted zone but prefer standalone configurations of my computers. I’ll however try it out later today to see whether it would help.
CPF-Logs: The problem is that I get no log entry at all. The firewall simply blocks but doesn’t log anything. Setting the message level to “very high” does not produce results either. That’s how I tried it: I deleted all log entries and then tried to connect. No new log entries appeared (which is not too surprising as I put an IP allow all protocols/ports on top of my rule list…). It must be some other part of the program that is blocking but not producing log entries…
I tried the trusted zone. But it didn’t help. I saw that in the end the trusted zone is doing exactly the same as I did: It inserts a filter rule allowing IP traffic in/out between trusted hosts. Even with a trusted zone: As soon as I switch on CPF, X11-traffic is blocked without leaving any log entries. It seems that the CPF network filter silently drops some type of traffic.
I found however something else: It is sufficient to disable CPF network filtering to allow X11-traffic pass. I do not have to disable CPF as a whole. This excludes a lot of possibilities, I think.
Another information: I have got a firewall enabled on the linux side as well. The only rules that suffice to let full X11 traffic pass there are “allow incoming udp 177 and tcp 6000”. Outgoing traffic is fully enabled anyway.
For those who are interested in the topic: I found a temporary workaround to access my GNOME desktop on the linux side using Xming. I installed Xephyr and an ssh server on the linux box. Now I am able to do the following:
First I start a listening XMing Xserver on my XP machine. Then I launch Xephyr on the linux box tunneling its X11 traffic through ssh to my XP box using the following command from an XP dos prompt:
Next I open a normal ssh terminal session (putty) with the same user and execute the following commands directly on the linux side:
Note: this works without XDMCP authentication as X is started up from an already authenticated SSH terminal session.
Now Xephyr acts as local X-Server to gdm and as remote X-Client to Xming tunneling its traffic through port 22 established as an outgoing session by plink. However, due to SSH tunneling and the complicated setup the connection is very slow (too slow in fact). Anyway: I am not that paranoic that I want to tunnel X11 traffic through SSH within my own home network. That’s why I still hope that I’ll find a way to open up CPF in a more specific way than disabling it altogether.
Btw: Tunneling gdm’s X11-requests directly to Xming does not work. Probably due to limitations of the Xming windows server it is necessary to leave Xephyr in the middle. Otherwise I get corrupted panels.
As far as I know, CFP blocks nothing silently by default. Although there have been some exceptions. But, if you can resolve the issue by disabling CFPs Network Monitor, then it probably isn’t one of those exceptions. Do you have any block rules in the Network Monitor that do not Log their actions?
No, I do not have any rules that silently block traffic. I attached a screenshot of my firewall rules which are pretty much standard CPF rules. They include a trusted zone (comprising my whole LAN address range) and one “manual” rule allowing my listening VNC viewer receive connections from colleagues’ VNC servers. I just greyed out the IPs in there… Sorry, the screenshot is in German. But I think this doesn’t matter too much to you.
You can see that the only (standard) block rule I have does log it’s actions.
The Network Monitor looks OK to me… certain no silent blocks. Just as you said. OK, perhaps it is an exception. But, it is very odd that disabling the Network Monitor resolves the problem. What’s the application/component called for whatever is responsible for X11 on Windows?
See another screenshot of my application monitor attached. I didn’t make a screenshot of the component monitor but none of the components is blocked neither. The applications concerned are Xming/XLaunch. Xming is the server, XLaunch only configures and launches Xming.
Unless the user offers, I only usually go to a Packet Sniffer as a means of last result & depending on the user… scares the hell of out some users. Actually, that is not entirely true… for me, replication is the means of last result (I’m old, idle & lazy. I also figure, what I don’t know cannot harm me. It’s more of a mantra. ;D )
Mike’s PS has the next thing we try (nearly)… Right click Ming.exe in the Application Monitor. Select Edit, goto the Misc’s tab (I think? Mike will confirm all this (please)… he’s running 2.4) and check Skip Advanced Security Checks & Allow Invisible Connections Attempts… Save/Apply… best to reboot if you can & retry X11. Try this first, then we can try ABA (Application Behavior Analysis… et al… as I think Mike was suggesting (I think)).
For the interested…
The Packet Sniffer I recommend for novices, the adventurous, the curious (you can’t do any harm with this… its easy to capture everything & save it to file. easy. honest!) and experts alike is WireShark.
edit: I note WireShark’s new motto is “Sniff Free or Die”. LOL. ;D
Yes, by all means… you can email the zipped PCAP file to me (my address it to the left of my posts) or email it to comodomods(AT)bluebottle.com if you want all Mods to have access to it (although you’ll have to go through a verification process on the comodomods email address - its an anti-spam measure).
The wireshark protocols weren’t of much help. Nothing obvious there. It might be a problem with fragmented packets. But allowing fragmented packets didn’t help. We also tried out logging other than NDIS traffic, which revealed nothing either. I think kail is currently trying to reproduce the problem at his place. I sent some instructions how to set up an environment similar to mine.
Reproducing the problem will take some time. But we’ll post all results here.
In the meantime I have found a workaround using NxFree which is by the way more secure and faster than a direct X11/XDMCP connection. And it passes Comodo. We’ll post a FAQ in the forum within the next days how to set up NxFree with Comodo.