Comodo blocking SSH traffic (PuTTY) - RESOLVED

Help for v2
#1

I recently installed Comodo and so far have been happy with it. However, yesterday I tried to connect to my remotely hosted server via SSH and got the message “No route to host”. I spent a little while trying to diagnose where the problem was and ended up uninstalling Comodo, at which point connectivity returned.

I then reinstalled Comodo and was able to configure it to allow PuTTY to connect to the internet.

However, after about half an hour the problem returned.

The server is contactable by other PCs on the net. It really does look like an issue with Comodo. Any ideas anyone?

#2

You have created the required rules to allow traffic to/from port 22, haven’t you?

Ewen :slight_smile:

#3

Well - I haven’t a specific rule to allow port 22, but I do have a rule allowing outgoing traffic on all ports. I’m not trying to serve ssh, so I don’t need an incoming rule for port 22.

But the thing is - this worked for about half an hour, then stops. Which clearly has nothing to do with any rules.

#4

Furthermore, rebooting the PC gives access to SSH again for a limited time - then it is gone again.

#5

hi,

does the temps port change after a time? ssl can have such features.

did you monitor it close?

use highest alert level, disable check protocols.

of coures retick if found it

Mike

#6

Sorry - I am not sure what you mean by “the temps port”. SSH is not configured to change ports.

Thanks for the advice - I’ll keep looking.

#7

re,

i overflow your problem, you give 2 ports open, works 30 mins,

yeah do all, high alert level, logs,

is it a idle icmp refuse cut? look network monitor,

you should have local loop monitor udp tcp high alert, you know all expert switches.

comodo block or not, is my imho

hey :slight_smile:

Mike

#8

Hi,

Sorry Mike - I’m not sure I understand what you are saying there.

I’ve got logging of everything switched on. I’ve got port 22 open.

When I try and connect I still get the “No route to host” message.

Reboot fixes it every time - this seems more like a bug than a misconfiguration.

#9

Ok - a bug in Peer Guardian - some reason was blocking my server some of the time. Now fixed.

Thanks for your efforts!

Dunx

#10

This is really odd. I use SSH extensively and have had no problems.

To help trouble shoot, you could try the following;

  1. create an explicit rule for port 22 outbound with logging enabled
  2. disable logging on all other rules
  3. move the port 22 rule to the top of the list
  4. clear the logs
  5. reboot
  6. connect to an ssh and wait for the disconnection
  7. while you are waiting for the disconnection, literally do nothing with the connection.
  8. once the disconnection occurs, reboot and repeat step 6
  9. this time, while waiting for the disconnection, ensure that there is constant traffic over the connection

If, after step 9 there is still a disconnection, export the logs and attach them to your reply to this post. The above method should ensure that only activity for the SSH connection is in the logs. If the disconnect only occurs after step 6 but not after step 9, then the disconnect is related to the host checking for activity on the connection, rather than leaving connections open if there is no activity. This, IMHO, is a good idea for a remote server. If there is still a disconnect after both steps 6 and 9, we should have some pertinent info in the logs.

Please remember to revert your rules back to their normal state after this test.

Cheers,
Ewen :slight_smile:

#11

Please ignore my reply. Your fix beat my response, timewise.

Glad to hear its resolved.

Ewen :slight_smile:

#12

Hey - but thanks for the concise reply. Hopefully this can help someone out in future.

#13

I’ll lock this topic and mark it as resolved. If you need it reopened just PM any of the moderators.

cheers,
Ewen :slight_smile: