Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 27 subscribers
  • Views 3397 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IMAPS/POPS working, but SMTPS not!?

Michael Ploch1

Hi forum,

I have tried everything I could imagine. I have a private installation of Sophos XG home, everything works fine but I cannot get email to work. Basically I would like to deactivate all Email-Stuff completely. If I deactivate the default rule being created by the appliance, I cannot reveive and send emails.

If I activate the rule and check scanning for smtps and imaps and pop3s, I can receive emails, but cannot send. Sending runs into a timeout. I have imported/accepted certificates
I have tried legacy mode and mta mode.

I have two different external email providers (freenet.de and goneo.de)
To make it more complex, freenet works like a charm (both with and without rule enabled), but goneo doesnt. Before I introduced Sophos, all worked fine.

Any good advice for helping me out?

edit: I forgot to say that using the notification functionality of Sophos in order to send system notes with the goneo.de email-adress this works. 



This thread was automatically locked due to age.
Parents
  • 0

    Hi,

    if you are using port 587 for smtps that is currently not supported by XG and you will need to create a firewall rule for that port specifically and of course create your own service.

    Assumption is you have installed the XG CA on the sending device?

    Ian

  • 0 in reply to rfcat_vk

    I did create a firewallrule. I also tried it with a any to any rule and all ports allowed. Does not work.

    Yes, I have installed the XG CA on the sending device.

     

    I even would prefer not so scann at all. But without the rule active, even pops and imaps does not work. 

    Is it possible to avoid mail protection completely?

  • 0 in reply to Michael Ploch1

    Hi Michael,

    I have the mail business rule working for my IMAP/s (993) and scanning works. reporting well, I am hoping that might be fixed in v18.

    SMTP/S using port 25/456 works using SSL on the sending devices. I am using two MBPs, one running outlook 2016 and that was a pain to get working. I also run two iPhones, but only one works with scanning, incoming works reliably, but scanning SMPTs totally unreliable, keeps breaking the CA.

    So I use port 587 with SSL  and its own mail rule source LAN -> network PCs, destination  WAN networks, the ISP mail servers -> port 587.

    Does work, you can check using log viewer and the email menu.

    If you want to use IMAP/s and POP3/s just add the ports, they are in the menu to the mail rule. You will need to make sure the rule is near the top of your firewall rules.

    Ian

  • 0 in reply to rfcat_vk

    I think I already did it this way but will try it as you suggest and will keep you updated once I did. thank you!

  • 0 in reply to rfcat_vk

    did not work unfortunately.

    works for my freenet.de but not for my goneo.de.

    dunnot know whats the difference for those cases.

     

    Sometimes I cannot see anything in the logs. Sometimes as below. Your rule active.

    Logfile:

    pop:
    messageid="01001" log_type="Firewall" log_component="Invalid Traffic" log_subtype="Denied" status="Deny" con_duration="0" fw_rule_id="0" policy_type="0" user="" user_group="" web_policy_id="0" ips_policy_id="0" appfilter_policy_id="0" app_name="" app_risk="0" app_technology="" app_category="" in_interface="Port1.120" out_interface="" src_mac="xx:xx:xx:xx:xx:xx" src_ip="192.168.120.3" src_country="" dst_ip="82.100.220.160" dst_country="" protocol="TCP" src_port="51173" dst_port="995" packets_sent="0" packets_received="0" bytes_sent="0" bytes_received="0" src_trans_ip="" src_trans_port="0" dst_trans_ip="" dst_trans_port="0" src_zone_type="" src_zone="" dst_zone_type="" dst_zone="" con_direction="" con_id="" virt_con_id="" hb_status="No Heartbeat" message="Could not associate packet to any connection." appresolvedby="Signature" app_is_cloud="0"

    smtp:
    messageid="01001" log_type="Firewall" log_component="Invalid Traffic" log_subtype="Denied" status="Deny" con_duration="0" fw_rule_id="0" policy_type="0" user="" user_group="" web_policy_id="0" ips_policy_id="0" appfilter_policy_id="0" app_name="" app_risk="0" app_technology="" app_category="" in_interface="Port1.120" out_interface="" src_mac="xx:xx:xx:xx:xx:xx" src_ip="192.168.120.3" src_country="" dst_ip="82.100.220.166" dst_country="" protocol="TCP" src_port="51074" dst_port="465" packets_sent="0" packets_received="0" bytes_sent="0" bytes_received="0" src_trans_ip="" src_trans_port="0" dst_trans_ip="" dst_trans_port="0" src_zone_type="" src_zone="" dst_zone_type="" dst_zone="" con_direction="" con_id="" virt_con_id="" hb_status="No Heartbeat" message="Could not associate packet to any connection." appresolvedby="Signature" app_is_cloud="0"

     

    smtp port 587:
    messageid="01001" log_type="Firewall" log_component="Invalid Traffic" log_subtype="Denied" status="Deny" con_duration="0" fw_rule_id="0" policy_type="0" user="" user_group="" web_policy_id="0" ips_policy_id="0" appfilter_policy_id="0" app_name="" app_risk="0" app_technology="" app_category="" in_interface="Port1.120" out_interface="" src_mac="xx:xx:xx:xx:xx:xx" src_ip="192.168.120.3" src_country="" dst_ip="82.100.220.166" dst_country="" protocol="TCP" src_port="52097" dst_port="587" packets_sent="0" packets_received="0" bytes_sent="0" bytes_received="0" src_trans_ip="" src_trans_port="0" dst_trans_ip="" dst_trans_port="0" src_zone_type="" src_zone="" dst_zone_type="" dst_zone="" con_direction="" con_id="" virt_con_id="" hb_status="No Heartbeat" message="Could not associate packet to any connection." appresolvedby="Signature" app_is_cloud="0"

  • 0 in reply to Michael Ploch1

    Hi Michael,

    you can safely ignore those dropped packets, you can even disable logging them if you wish. They are the default firewall rule 0 when the XG cannot find an existing connection or firewall rule to match.

    They do not mean your firewall rules are not working.

    Check with your ISP about their mail server settings.

    Ian

Reply
  • 0 in reply to Michael Ploch1

    Hi Michael,

    you can safely ignore those dropped packets, you can even disable logging them if you wish. They are the default firewall rule 0 when the XG cannot find an existing connection or firewall rule to match.

    They do not mean your firewall rules are not working.

    Check with your ISP about their mail server settings.

    Ian

Children
  • 0 in reply to rfcat_vk

    Hi rfcat,

     

    I dont know what to ask my ISP. Without Sophos XG everything runs fine. This is why I assume the problem to be on the Sophos side, configuration, ... and not on the settings I have on the client side. Nothing changed there, and if I run my network without Sophos, it all starts to work again.

  • 0 in reply to Michael Ploch1

    Hi Michael,

    Your mail firewall rule should look a bit like this :-

    Source - LAN

    Network - ANY

    Destination -WAN

    Destinations networks - imap.goneo.de and smtp.goneo.de

    ports - 25, 993, 465 and 587

    Allow

    Log

    NAT - MASQ

    IPS - NONE

    WEB - all lall

    application - allow all.

     

    Then in log viewer create a filter with your new rule number. Follow the by connecting to your mail server and try to send a message. 

    Then report back here with extracts from the logviewer if the new firewall rule is not successful. You also need to check what you mail client thinks is wrong.

    Ian