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

packet loss

Hey, everybody,

hey there. It’s already been 2 months that we are facing a problem that we cannot find the source until now with sophos XG. Our concern is that we have a lot of packet loss at the XG appliance level. We checked, but it’s not a network layer issue or anything else.

here is a result extract of the drop-packet-capture command

2021-06-15 08:42:54 0103021 IP 51.15.159.151.5060 > 41.204.124.142.64048 : proto UDP: packet len: 648 checksum : 61834
0x0000: 4500 029c 8cd1 0000 3411 7e7f 330f 9f97 E.......4.~.3...
0x0010: 29cc 7c8e 13c4 fa30 0288 f18a 4f50 5449 ).|....0....OPTI
0x0020: 4f4e 5320 7369 703a 6363 3132 3940 3431 ONS.sip:cc129@41
0x0030: 2e32 3034 2e31 3234 2e31 3432 3a36 3430 .204.124.142:640
0x0040: 3438 3b74 7261 6e73 706f 7274 3d55 4450 48;transport=UDP
Date=2021-06-15 Time=08:42:54 log_id=0103021 log_type=Firewall log_component=Local_ACLs log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=Port3 o
ut_dev= inzone_id=2 outzone_id=4 source_mac=ac:f2:c5:88:09:62 dest_mac=c8:4f:86:09:33:c4 bridge_name= l3_protocol=IPv4 source_ip=51.15.159.151 dest_ip=41.204.124.142 l4
_protocol=UDP source_port=5060 dest_port=64048 fw_rule_id=N/A policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuse
r_id=0 hb_src=0 hb_dst=0 dnat_done=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 nat_id=0 cluster_node=0
inmark=0x8002 nfqueue=0 gateway_offset=0 connid=1408073216 masterid=0 status=256 state=0, flag0=549757911040 flags1=17179869184 pbdid_dir0=0 pbrid_dir1=0

2021-06-15 08:42:54 0103021 IP 51.15.159.151.5060 > 41.204.124.142.53110 : proto UDP: packet len: 565 checksum : 29694
0x0000: 4500 0249 8cd4 0000 3411 7ecf 330f 9f97 E..I....4.~.3...
0x0010: 29cc 7c8e 13c4 cf76 0235 73fe 5349 502f ).|....v.5s.SIP/
0x0020: 322e 3020 3430 3120 556e 6175 7468 6f72 2.0.401.Unauthor
0x0030: 697a 6564 0d0a 5669 613a 2053 4950 2f32 ized..Via:.SIP/2
0x0040: 2e30 2f55 4450 2034 312e 3230 342e 3132 .0/UDP.41.204.12
Date=2021-06-15 Time=08:42:54 log_id=0103021 log_type=Firewall log_component=Local_ACLs log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=Port3 out_dev= inzone_id=2 outzone_id=4 source_mac=ac:f2:c5:88:09:62 dest_mac=c8:4f:86:09:33:c4 bridge_name= l3_protocol=IPv4 source_ip=51.15.159.151 dest_ip=41.204.124.142 l4_protocol=UDP source_port=5060 dest_port=53110 fw_rule_id=N/A policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 nat_id=0 cluster_node=0 inmark=0x8002 nfqueue=0 gateway_offset=0 connid=1408073216 masterid=0 status=256 state=0, flag0=549757911040 flags1=17179869184 pbdid_dir0=0 pbrid_dir1=0

2021-06-15 08:42:54 0103021 IP 51.15.159.151.5060 > 41.204.124.142.64310 : proto UDP: packet len: 565 checksum : 33241
0x0000: 4500 0249 8cd5 0000 3411 7ece 330f 9f97 E..I....4.~.3...
0x0010: 29cc 7c8e 13c4 fb36 0235 81d9 5349 502f ).|....6.5..SIP/
0x0020: 322e 3020 3430 3120 556e 6175 7468 6f72 2.0.401.Unauthor
0x0030: 697a 6564 0d0a 5669 613a 2053 4950 2f32 ized..Via:.SIP/2
0x0040: 2e30 2f55 4450 2034 312e 3230 342e 3132 .0/UDP.41.204.12
Date=2021-06-15 Time=08:42:54 log_id=0103021 log_type=Firewall log_component=Local_ACLs log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=Port3 out_dev= inzone_id=2 outzone_id=4 source_mac=ac:f2:c5:88:09:62 dest_mac=c8:4f:86:09:33:c4 bridge_name= l3_protocol=IPv4 source_ip=51.15.159.151 dest_ip=41.204.124.142 l4_protocol=UDP source_port=5060 dest_port=64310 fw_rule_id=N/A policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=0 sslvpn_id=0 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_done=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 nat_id=0 cluster_node=0 inmark=0x8002 nfqueue=0 gateway_offset=0 connid=1408073216 masterid=0 status=256 state=0, flag0=549757911040 flags1=17179869184 pbdid_dir0=0 pbrid_dir1=0



This thread was automatically locked due to age.
  • Hi,

    please post a copy of your sip firewall rule.

    ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • it is just this rule that allows LAN traffic to outside VOIP servers.

  • This is SIP hitting your firewall WAN Interface. The XG dropps this because it cannot handle it. Looks like responses to communication from internal devices that have already been terminated because the source port is 5060 from the external IP. Can also be SIP spoofing attempts. But this IP does look legitimate to me.

    Do you have issues with VoIP?

    Please do not NAT this to your VoIP devices.

  • I was about to ask what are you internal address ranges because those PCAPS look like external addresses from other VOiP services trying to contact your internal phones.

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • also check this settings. We're OK with these parameters for VoIP:

    console> show advanced-firewall
    ...
            Tcp Conn. Establishment Idle Timeout    : 10800
            UDP Timeout                             :
            UDP Timeout Stream                      : 60
            Fragmented Traffic Policy               : allow

    ...

    edit: whilre reading, it looks strange that UDP timeout is blank but this is our actual setting.

    console> system system_modules show
    pptp    loaded
    h323    loaded
    tftp    loaded
    irc     loaded
    dns     loaded
    sip     not loaded

  • indeed, SIP clients (zoipers) cannot connect to the server when sophos XG as to remove all SIP / VOIP packets

    We have to Nat the clients since we use private IPs while the VOIP servers are on the internet.

  • we are using the range 10.2.0.0/16 which are Nat on a WAN interface (41.204.124.142)

  • this is our current configuration.


    console> show advanced-firewall                                                 
            Strict Policy                           : off                           
            FtpBounce Prevention                    : control                       
            Tcp Conn. Establishment Idle Timeout    : 50400                         
            UDP Timeout                             :                               
            UDP Timeout Stream                      : 150                           
            Fragmented Traffic Policy               : allow                         
            Midstream Connection Pickup             : off                           
            TCP Seq Checking                        : on                            
            TCP Window Scaling                      : on                            
            TCP Appropriate Byte Count              : off                           
            TCP Selective Acknowledgements          : on                            
            TCP Forward RTO-Recovery[F-RTO]         : off                           
            TCP TIMESTAMPS                          : off                           
            Strict ICMP Tracking                    : off                           
            ICMP Error Message                      : allow                         
            IPv6 Unknown Extension Header           : deny                          
                                                                             
  • This is SIP hitting your firewall WAN Interface. The XG dropps this because it cannot handle it. Looks like resposes to communication from internal devices that have already been terminated because the source port is 5060 from the external IP. Can also be SIP spoofing attempts. But this IP does look legitimate to me.

    how can we make sure that XG does not delete this traffic which is legitimate?

  • for the XG this traffic looks like 41.204.124.142 wants to connect to the XG itself on the random high port.

    Thats why this happens: log_component=Local_ACLs log_subtype=Denied 

    I think you should check why 41.204.124.142 sends you back 401 Unauthorized

    Also, have you checked the SIP module of the XG turned off as mentioned above?