I am playing a game called Soldat and I can’t join 2 certain game servers anymore since the last update. I can join them when I have my firewall disabled.
It’s about 78.46.76.21:23071 and 72.232.225.66:23071 both linux server. The servers do see me requesting the game, but I cannot join.
There’s another server 84.250.25.167:23071 that I am able to join. That’s a windows server. I gave Soldat full access at the network security policy and I can’t remember changing any settings.
BUMP
This has still not been fixed.
It’s not a problem with my settings, I know more people with the exact same problem.
We can’t join the server. The server does detect that we are ‘requesting’ the game.
Can you show screenshots of the application rules of the game and the Global Rules (Firewall → advanced → Network Security Policy)?
What ports need to be opened for this game?
I can join any other servers. You have to connect the lobby server and game servers. It works fine for every server except for the ones with port 23071
I can also join servers with the same IP and different port. The port is blocked for that host (or for linux servers) for some reason.
screenshots attached
Edit: I just tested something, I can also join other linux servers with that port. So the port is only blocked for that host. Does look like wrong settings, can’t find something though.
[attachment deleted by admin]
I have identical problem as PQ.
Just to add. i used copy from trusted application policy and then edit it: tick Log as a firewall event if this rule is fired.
Log shows allowed but i can’t join the server.
[attachment deleted by admin]
I was tinkering with the the setting and i was able to find a possible solution.
I unchecked block fragmented IP datagrams in attack detection settings and i able to join the server.
what could be the effect of disabling this option?
PQ,
Could you try it and tell me if it works for you too? 
[attachment deleted by admin]
Are you seeing any firewall log entries for this?
Attached the log when i disable block fragmented IP datagram.
[attachment deleted by admin]
But you don’t see any Block entries prior to disabling those settings?
No blocked entries. This is all my logs shows.
Above the highlighted entry is after i disable it and below is before disabling.
[attachment deleted by admin]
Well, for what ever reason there must be a lot of fragmented datagrams being generated between certain points, hence the ability to join some servers but not others. It would also be of interest to know what settings the server has regarding IP Fragmentation…
Be aware that unchecking that box, whilst allowing you to play your game, does potentially open your defences. There are a number of attack types that make use of fragmentation.
That solution works, but I get many hack attempts since I live in a house with 17 roommates and we all share one 100mbit internet connection. (and most of them don’t have a firewall)
So I don’t think that it’s safe to disable that (or am I wrong)
Could this just be a comodo bug then? And why would it only block that port from 1 IP address?
See my post above
Guess i have to revert my settings back. 
I will try to find out the settings of server has regarding its IP Fragmentation.
I have some questions:
- Is it possible that a single port from a IP to cause this?
- Why does comodo doesn’t show blocked entries?
- Since we can connect to the server by unchecking that box, is there a program to fully check/see the detials while connecting to the server?
thanks Toggie for helping
I have some questions: 1. Is it possible that a single port from a IP to cause this?
To understand why fragmentation may be occurring and why it may also be causing your problems, you would need to know the details of how IP fragmentation occurs as well as understanding the differences between TCP and UDP.
In a nutshell (this is very simplistic), a large network such as the Internet is divided into segments, each segment is connected to another segment via a router. Each segment typically has a set size that it will allow for datagrams that travel over that segment. This is called the MTU (Maximum Transmission Unit). If a datagram is larger than a specified MTU it will be fragmented.
When a datagram is fragmented, each piece is given a new header and sent on its way. The path one individual piece takes may not be the same as any other piece. When the pieces arrive at their destination they are reassembled. However if one piece is missing the datagram is discarded.
With TCP this is less of a problem because TCP has the ability to ensure retransmission of any lot pieces. Typically, UDP does not.
So, In your scenario, for whatever reason, it seems that the connection to one particular server is less reliable than others. It may be a fragmentation issue, resulting in lost datagrams or it may be some configuration issue with that particular server.
2. Why does comodo doesn't show blocked entries?
It will only show log entries for rules for which logging has been enabled, either allow or block.
3. Since we can connect to the server by unchecking that box, is there a program to fully check/see the detials while connecting to the server?
There are some things that can be done to investigate, obviously talking to the server host to determine their configuration parameters may enlighten us further.
Failing that, you could analyse the traffic leaving your client using something like Wireshark You could also try to investigate the maximum MTU size by using ping with different ICMP sizes.
ping -f -l 1472 (insert the server details here)
Keep reducing the number until you no longer receive fragmentation required messages. Once you have this value you can change the MTU size on your PC.
Seems like a lot of aggravation to me…
unfortunately ICMP request has been block for this server.
I have tried wireshark. test it with 72.232.225.66:23071 and with other servers.
It shows an extra line with fragment IP protocol and a lot of bad checksum.
I guess thats the reason why comodo is blocking it.
[attachment deleted by admin]
This is from my system:
ping -f -l 1372 72.32.225.66
Pinging 72.32.225.66 with 1372 bytes of data:
Reply from 72.32.225.66: bytes=1372 time=295ms TTL=56
Reply from 72.32.225.66: bytes=1372 time=292ms TTL=56
Reply from 72.32.225.66: bytes=1372 time=293ms TTL=56
Reply from 72.32.225.66: bytes=1372 time=293ms TTL=56
Ping statistics for 72.32.225.66:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 292ms, Maximum = 295ms, Average = 293ms
ping -f -l 1373 72.32.225.66
Pinging 72.32.225.66 with 1373 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 72.32.225.66:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
1372 is the ping packet size but does not include IP/ICMP header of 28 bytes. So, 1372+28=1400, the actual MTU.
As I said this right for my system, it may well be different for yours, it will depend on things like make and model of router, the configuration at your ISP etc.
The fact that data is being lost/corrupted (Bad CRC) very likely goes a good way to explaining why you’re having problems. The question to answer now would be, why is data getting lost? That’s a much harder question to answer.
Sorry. didn’t even tested it before. it do work.
From what i understand regarding MTU , if it was setup incorrectly there is a possibility that I can’t access the server, right?
I was looking at the logs from wireshark and i also notice that it has larger frame length compared to other servers, which i can access (611 bytes)
Does this have relation with MTU settings?
No. Time Source Destination Protocol Info
4 3.449158 72.232.225.66 192.168.1.2 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=ffe6) [Reassembled in #5]
Frame 4 (1514 bytes on wire, 1514 bytes captured)
Arrival Time: Jul 11, 2009 12:01:01.452042000
[Time delta from previous captured frame: 0.290273000 seconds]
[Time delta from previous displayed frame: 0.290273000 seconds]
[Time since reference or first frame: 3.449158000 seconds]
Frame Number: 4
[b]Frame Length: 1514 bytes[/b]
Capture Length: 1514 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:data]
Ethernet II, Src: AztechEl_e6:ee:89 (00:30:0a:e6:ee:89), Dst: AsustekC_59:b8:ce (00:17:31:59:b8:ce)
Internet Protocol, Src: 72.232.225.66 (72.232.225.66), Dst: 192.168.1.2 (192.168.1.2)
Data (1480 bytes)
Yes, frame size is important. When the data to be sent reaches the Datalink Layer of the stack, it is is placed in to a frame. The frame size is dictated by the underlying network type, such as Ethernet, FDDI etc.
We essentially come back to the earlier discussion. For what ever reason, the server you cannot reach, is doing something different to the servers you can reach. Whether, that’s network related or configuration related is difficult to discern.
It would probably be easier to send the host an email asking for the relevant details…
Thank a lot for your help, toggie. :-TU
I just wanted to make sure about the discrepancy with frame sizes.
that I will do.