Invalid traffic violation even with proper rules applied

Hi Lubomir,

One thing is pretty clear, that ping is working and in this rule, services are already allowed as "ANY". So need to investigate where the traffic gets dropped. We need some information to assist you on this :

1) Can you please share the snapshot of the Network > Interface ?

(In case any Alias are configured, ensure that we are able to see all the settings in that snapshot)

2) In case those two networks 172.21.17.50 and 192.168.12.46 are not configured on Firewall interface directly, also share the snapshot of the Static Route configuration.

3) Take drop packet capture from the SSH access :

drop-packet 'host 192.168.12.46 or host 172.21.17.50 and port 1433

Share this complete output when you initiate the traffic. 

Based on this information, we will be able to assist you further.

Regards,

Resolution24x7

Hello,

I'm sending the information you requsted. Output from router is in attachment.

5758.Drop Packet.txt

Thanks

Lubo

Hi Lubo,

I would request you to create one more rule that allows the connection from the specific initiator to the specific responder.

1) Try with NAT/Without NAT MASQ in that rule. Ensure that the rule is on the top.

2) Also, you may flush the conntracks before proceeding with this activity using below command :

 console > sys dia utili connections v4 delete dest_ip 192.168.12.46
 console > sys dia utili connections v4 delete src_ip 192.168.12.46
 console > sys dia utili connections v4 delete src_ip 172.21.17.50
  console > sys dia utili connections v4 delete dest_ip 172.21.17.50

Initiate the requests on ping and on required port 1433.

3)  Now when after you initiate the ping and then the traffic on port 1433, enter below command to get the status of those connections : (as ping is working)

 console > sys dia utili connections v4 show dest_ip 192.168.12.46
 console > sys dia utili connections v4 show src_ip 192.168.12.46
 console > sys dia utili connections v4 show src_ip 172.21.17.50
  console > sys dia utili connections v4 show dest_ip 172.21.17.50

Hope it helps !

Regards,

Resolution24x7

Hi Lubo,

I would request you to create one more rule that allows the connection from the specific initiator to the specific responder.

1) Try with NAT/Without NAT MASQ in that rule. Ensure that the rule is on the top.

2) Also, you may flush the conntracks before proceeding with this activity using below command :

 console > sys dia utili connections v4 delete dest_ip 192.168.12.46
 console > sys dia utili connections v4 delete src_ip 192.168.12.46
 console > sys dia utili connections v4 delete src_ip 172.21.17.50
  console > sys dia utili connections v4 delete dest_ip 172.21.17.50

Initiate the requests on ping and on required port 1433.

3)  Now when after you initiate the ping and then the traffic on port 1433, enter below command to get the status of those connections : (as ping is working)

 console > sys dia utili connections v4 show dest_ip 192.168.12.46
 console > sys dia utili connections v4 show src_ip 192.168.12.46
 console > sys dia utili connections v4 show src_ip 172.21.17.50
  console > sys dia utili connections v4 show dest_ip 172.21.17.50

Hope it helps !

Regards,

Resolution24x7

Hello,

this doesn't work for me. Still, ping is working only from 172.21.17.50, not in reverse.

And using port 1433 does not work either.

I have no clue what to do. :(

Thanks

Lubo

Most likely Port 1433 is blocked because of the application running there not XG. Thats invalid traffic blocks after the connection is already closed. So basically XG forwards the packet, the server closes the connection with multiple packets XG blocks those multiple packets (and forward one close packet). 

You should investigate the application itself. 

Hi Lubomir,

Ideally, if rules are configured for Any services and ping is working, it should not be issue from firewall.

However, as per drop packet capture you have shared, apart from FIN/RST packets, SYN Packets are also getting dropped. This requires a support team investigation via wireshark packet capture.

This is observed for traffic initiated from 172.21.17.50:1433 to 192.168.12.46:random port.

[This should be traffic initiated from 172.21.17.50 itself because SYN is getting dropped and not SYN-ACK]

console> drop-packet 'host 192.168.12.46 or host 172.21.17.50 and port 1433
2019-12-12 13:31:37 010202130 IP 172.21.17.50.1433 > 192.168.12.46.35493 : proto TCP: S 2884457186:2884457186(0) win 8192 checksum : 9702
0x0000: 4500 003c 5136 4000 8006 1f68 ac15 1132 E..<Q6@....h...2
0x0010: c0a8 0c2e 0599 8aa5 abed 52e2 cbe3 40ce ..........R...@.
0x0020: a012 2000 25e6 0000 0204 05b4 0103 0308 ....%...........
0x0030: 0402 080a 2836 1769 011c 9b6f ....(6.i...o
Date=2019-12-12 Time=13:31:37 log_id=010202130 log_type=Firewall log_component=Invalid_Traffic log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_dev=PortE0 out_dev= inzone_id=0 outzone_id=0 source_mac=00:0c:29:1c:20:9d dest_mac=7c:5a:1c:48:20:28 l3_protocol=IP source_ip=172.21.17.50 dest_ip=192.168.12.46 l4_protocol=TCP source_port=1433 dest_port=35493 fw_rule_id=0 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 proxy_flags=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 source_nat_id=0 cluster_node=0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drop_fix=0 ctflags=0 connid=0 masterid=0 status=0 state=0 sent_pkts=N/A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_dst_ip=N/A tran_dst_port=N/A

Regards,

Resolution24x7

Hi guys,

Please see screensshots from Wireshark. I've captured the data during connection/

Also, I have discovered the same problem between two different hosts. (192.168.12.50 and 192.168.1.230 in this case with port 4711)

Hope it helps somehow.

3301.Sample1.zip

Hi Lubomir,

As per the Pcap and earlier logs :

1) SYN packet was getting dropped and not SYN Acknowledgement. You can cross confirm that by re taking the drops/tcpdumps and running wireshark on initiator system.

2) So if SYN packets are forwarded, as per this wireshark packet capture, below show be the packet flow :

Initiator > Responder SYN
Responder > Initiator SYN-ACK
Initiator > Responder ACK

However, in your case, packet flow is as below :

Initiator > Responder SYN
Responder > Initiator SYN-ACK
Initiator > Responder Retransmission of SYN packet  (This is unexpected behaviour)

So logic is, if firewall forwards that traffic, which should be confirmed from the tcpdump and drop packet capture, then better to run a wireshark on the initiator system and confirm if system receives the SYN-ACK from the responder or not.

Your local firewall could be dropping traffic. Try disabling that as well once or allow that specific port from firewall/end point security. Normally ICMP packets are not blocked so that might be working.

Hope the logic helps to narrow down !

Regards,

Resolution24x7

Thanks both for advice.

Now I have discovered somehting strange:

When I ping from 172.21.17.50 to 192.168.12.46. This is what I get from wireshark. This is echo request:

and this is an echo reply.

Notice the ethernet source on reply. Shouldn't it be sophos' mac address?

Thanks

Hi Lubomir,

Technically you are correct that destination should be the Sophos Mac address. However, that requires to be checked on responder once for it is generating response to destination mac instead of gateway mac. This means the destination should be having the arp of the initiator instead of the gateway itself.

Reference document : https://www.geeksforgeeks.org/packet-flow-in-different-network/

Thanks and Regards,
Resolution 24x7