• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1008
  • Last Modified:

outbound smtp connection attempt - source port shivadiscovery (tcp/1502)

We have several PC's that are unable to establish any outbound connection to a particular domain name or the IP address of a server used by the domain.  For example, we are not able to access the website of domain.com, cannot telnet to mail.domain.com or the IP of mail.domain.com.  We are able to telnet to other smtp servers without issue.

There is also a separate internal network (on a different interface) that utilizes the same internet gateway.  Devices on the second network are able to connect just fine.

Here is the capture of when a connection attempt is made from network 1:

UNSUCCESSFUL CONNECTION:
1327      4.849653000      192.168.1.59      YYY.YYY.YYY.YYY      TCP      shivadiscovery > smtp [SYN] Seq=0 Win=65535 Len=0 MSS=1460 SACK_PERM=1

Here is the capture of when a connection attempt is made from network 2:

SUCCESSFUL CONNECTION:
114      2.967202      192.168.10.21      YYY.YYY.YYY.YYY      TCP      52592 > smtp [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8 SACK_PERM=1
117      3.016186      YYY.YYY.YYY.YYY      192.168.10.21      TCP      smtp > 52592 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=7

[Where YYY.YYY.YYY.YYY is a public IP address]

Clearly the difference is the outbound port that the TCP connection attempt is made.  Does shivadiscovery indicate that we have some type of malware on these devices?

In limited troubleshooting the only other thing that seemed unusual was the routing table, the metric of what should be the default route was higher than some of the other routing table entries.

Any ideas?
0
gatorIT
Asked:
gatorIT
  • 2
1 Solution
 
QlemoC++ DeveloperCommented:
The metric of routes is relevant only if there are multiple routes to the same target. The most restrictive route is used first, then the less ones. Only if the restriction is the same, e.g. two 192.168.1.0/24 routes, metric is used to decide which one to take.

The ShivaDiscovery port is NOT the outpound port, it is the source port, and that can and will be dynamic. Only the destination port is fixed, as SMTP. Of course that is reversed for the reply, which needs to come on the port used as source for the request.

First thing to try is a tracert from both sources to the public IP, and compare them with each other and with the tracert from 192.168.1.59 to a different (public) target.
0
 
Craig BeckCommented:
It may be that your firewall is only allowing connections FROM source ports above a certain number.

For example, your firewall might block connections from ports 0-1024, or from between 5000-6000.
0
 
gatorITAuthor Commented:
Turns out it was the remote server that was blocking the IP.  We have a block of five routable/public IPs and when we changed IP's we were able to connect without an issue.  No idea why we were blocked though.
0
 
gatorITAuthor Commented:
Actual outcome.
0

Featured Post

[Webinar] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now