Can't connect to port 143 on external host

Hi all,

 

I have a Sophos XG with SFOS 17.5.8 MR-8, and everything is by default.

I have one nat rule to all hosts/ports to go out to the wan.

My issue is that I have a internal host, an IOT device, that needs to communicate with port 143 on the wan and its not able to, I see the package being accepted on the logs but no reply from target. Checked With tcpdump on other host trying telnet to the same target and no replies are getting in.

Tested without Sophos and it works. I can't see any traffic being denied anywhere.

How can I find in which layer it's being rejected?

Thanks

  • Hi  

    Please check which IP has been assigned to IoT device and follow the below steps.

    1. Create a Source IP based firewall rule and do not apply any scanning and allow all the traffic and check, please put the rule on top. 

    2. Now replicate the scenario and apply policies and scanning to the same firewall rule we have created above and check the traffic.

    3. Capture drop packets- https://community.sophos.com/kb/en-us/127111

  • In reply to Keyur:

    Hi Keyur,

     

    Just did what you said, created a firewall rule

    drop-packet-capture 'host "IP"' shows nothing

    Firewall log:

    messageid="00001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" con_duration="185" fw_rule_id="15" policy_type="1" 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="PortA" out_interface="PortB" src_mac="00:00:00:00:00:00" src_ip="xxx.xxx.xxx.xxx" src_country="R1" dst_ip="yyy.yyy.yyy.yyy" dst_country="ITA" protocol="TCP" src_port="53598" dst_port="143" packets_sent="7" packets_received="0" bytes_sent="420" bytes_received="0" src_trans_ip="zzz.zzz.zzz.zzz" src_trans_port="0" dst_trans_ip="" dst_trans_port="0" src_zone_type="LAN" src_zone="LAN" dst_zone_type="WAN" dst_zone="WAN" con_direction="" con_event="Stop" con_id="1825802392" virt_con_id="" hb_status="No Heartbeat" message="" appresolvedby="Signature" app_is_cloud="0"

     

    And I can't connect.

     

    Thanks

  • In reply to Telmo Reis:

    Hi,

    port 143 is mail port, you don't have mail scanning enabled on an earlier firewall rule do you?

    Ian

  • In reply to rfcat_vk:

    Hi Ian,

     

    To avoid that issues I created this as the first rule, I've also looked into mail stuff and I can't find any enabled rule/policy.

    So problem still here.

     

    I would really like that there would be a log for all denied packages, or some king of real time testing that would show all chain and where the block is. Kind of a system wide drop-packet-capture.

     

    Thanks

  • In reply to Telmo Reis:

    Hi,

    inn logviewer set a filter for rule 15 and see what entries there are when you try to connect.

    Have you disabled rule 0 capture of no connection entries?

    Also change your source network to any during the testing.

    Ian

  • In reply to rfcat_vk:

    Hi Ian,

     

    Log viewer filter for rule 15 only shows accepts, not even one deny.

    Source network is ANY ando no change to the result.

    Sorry, how do yo edit rule 0?

     

    Thanks

  • In reply to Telmo Reis:

    Hi,

    you can't edit rule 0, just stop it recording all unassociated packets.

    Does your device get a DHCP assigned address or is it fixed, so check your gateway configuration  and netmask on the device.

    Ian

  • In reply to rfcat_vk:

    Hi,

     

    Replaced Sophos XG with another (not XG) FW and it works, so looks like there's something blocking the traffic in XG.

    Thanks anyway.

  • In reply to Telmo Reis:

    What you are saying is there is something wrong with the XG interface because you are not seeing the traffic hit the XG, so, check the XG LAN interface is set to auto negotiate.

    Are you using DHCP and do you see an address being allocated in the XG DHCP server. What is the address of you IoT device. gateway settings etc?

    Ian

  • In reply to rfcat_vk:

    I just use XG as internet gateway, all other services are external, DNS, DHCP...

    What I did was replace XG (virtual) with other FW (virtual) using the same IP so there wouldn't be any logical changes, and it worked.

     

    TGR

  • In reply to Telmo Reis:

    What IP address does the IoT device use because you are not seeing it in the logs.

    Ian

  • In reply to rfcat_vk:

    Output of tcpdump when using XG

    15:03:31.030880 IP x.x.x.x.43322 > y.y.y.y.143: Flags [ S ], seq 3490777265, win 29200, options [mss 1460,sackOK,TS val 3516544317 ecr 0,nop,wscale 7], length 0
    15:03:32.041296 IP x.x.x.x.43322 > y.y.y.y.143: Flags [ S ], seq 3490777265, win 29200, options [mss 1460,sackOK,TS val 3516545327 ecr 0,nop,wscale 7], length 0
    15:03:34.057302 IP x.x.x.x.43322 > y.y.y.y.143: Flags [ S ], seq 3490777265, win 29200, options [mss 1460,sackOK,TS val 3516547343 ecr 0,nop,wscale 7], length 0
    15:03:38.281301 IP x.x.x.x.43322 > y.y.y.y.143: Flags [ S ], seq 3490777265, win 29200, options [mss 1460,sackOK,TS val 3516551567 ecr 0,nop,wscale 7], length 0

    Firewall log

     

    Output of tcpdump with other FW

    16:06:15.359375 IP x.x.x.x.52462 > y.y.y.y.143: Flags [ S ], seq 2776136244, win 29200, options [mss 1460,sackOK,TS val 9894944 ecr 0,nop,wscale 7], length 0
    16:06:15.547123 IP y.y.y.y.143 > x.x.x.x.52462: Flags [S.], seq 239633173, ack 2776136245, win 28960, options [mss 1103,sackOK,TS val 120540279 ecr 9894944,nop,wscale 7], length 0
    16:06:15.547164 IP x.x.x.x.52462 > y.y.y.y.143: Flags [.], ack 1, win 229, options [nop,nop,TS val 9894990 ecr 120540279], length 0
    16:06:16.603238 IP y.y.y.y.143 > x.x.x.x.52462: Flags [S.], seq 239633173, ack 2776136245, win 28960, options [mss 1103,sackOK,TS val 120540536 ecr 9894944,nop,wscale 7], length 0
    16:06:16.603265 IP x.x.x.x.52462 > y.y.y.y.143: Flags [.], ack 1, win 229, options [nop,nop,TS val 9895254 ecr 120540279], length 0
    16:06:18.592049 IP y.y.y.y.143 > x.x.x.x.52462: Flags [S.], seq 239633173, ack 2776136245, win 28960, options [mss 1103,sackOK,TS val 120541040 ecr 9894944,nop,wscale 7], length 0
    16:06:18.592075 IP x.x.x.x.52462 > y.y.y.y.143: Flags [.], ack 1, win 229, options [nop,nop,TS val 9895752 ecr 120540279], length 0
    16:06:20.209946 IP x.x.x.x.52462 > y.y.y.y.143: Flags [P.], seq 1:6, ack 1, win 229, options [nop,nop,TS val 9896156 ecr 120540279], length 5
    16:06:20.378361 IP y.y.y.y.143 > x.x.x.x.52462: Flags [.], ack 6, win 227, options [nop,nop,TS val 120541487 ecr 9896156], length 0
    16:06:20.378407 IP y.y.y.y.143 > x.x.x.x.52462: Flags [F.], seq 1, ack 6, win 227, options [nop,nop,TS val 120541487 ecr 9896156], length 0

     

    The only difference between the tcpdumps is the firewall, everything else remains untouched.

    Hope this explains better the issue

  • In reply to Telmo Reis:

    Hi  

    Thank you for providing working and nonworking tcpdump capture for port 143.

    In the Nonworking scenario, SYN request is sending out but no SYN ACK packet.

    Could you please try to capture drop packets on port 143? drop-packet-capture 'port 143

    Previous Drop Packet showing Firewall Rule 15, Could you please confirm the firewall rule ID?

    Please also check MTU MSS value for LAN and WAN Interface.


  • In reply to Keyur:

    Hi Keyur,

     

    Sorry for the late answer but I was out of the country.

    drop-packet-capture 'port 143' did not return any output.

    yes, the rule number is correct it's 15 and its the rule on top.

    No issues with MTU MSS.

     

    Thanks

  • In reply to Telmo Reis:

    Hi  

    I would request you to contact support and open a service request to investigate the issue further. Please PM us the service request number.