Sophos Xgs Download Packet Capture [WORK]
Alexandrina Burbidge
I have captured packets with the GUI Packet Capture Tool. I now would like to export/download/save the captured data for offline analysis. The only instructions I have found are to download a pcap file that was generated from the console packet capture.
Effectively, you use nc on the XG to open a port on your laptop, also running nc to receive the data. When the tcpdump is done (either by limiting the number of packets or simply pressing control-c) the connection closes and a file is created. I use this technique a lot.
Packet capture shows the details of the packets that pass through an interface. You can see the connection details and details of the packets processed by each module, such as firewall and IPS. Packet capture also shows the firewall rule number, user, web, and application filter policy number. This information can help you troubleshoot instances where firewall rules fail.
Click Display filter to filter the details based on interface name, EtherType, packet type, source IP address and port, destination IP address and port, reason, status, rule ID, user, and connection ID.
Well I still don't see the original source and target IPs but it does the trick so far, that I can at least verify, my traffic passes through the right tunnel.
So I suggest to write an article on this in the knowledgebase if not already existing.
I think this might be valuable to other admins too.
Especially, when you have to juggle many VPNs and pass traffic from one to another, it's very helpful to have this at hand.
Sometimes packets get lost somewhere and comands like this ease diagonsing such scenarios a lot.
Best regards
RanX
As pointed out in my first answer, I want to know, if my traffic passes the right tunnel.
If I got your colleague right, packet capture only shows me, that it goes to some tunnel (interface ipsec0).
When I wan't to verify, it goes to a certain tunnel, this is only half the job.
If packet capture allows a more detailed diagnosis on a single tunnel, I'm looking forward for instructions how to acheive this.
Best Regards
RanX
I have a problem with communication between two servers? My firewall is rejecting packets as seen from the picture. Due to this reason both sides cannot exchange MS SQL data. Ping is also functional only from 172.21.17.50, but not reverse. I checked the wireshark on the Windows Server(172.21.17.50) and ICMP replies are sent during ping, but they are not reaching the destination(Linux 192.168.12.46). See second picture.
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).
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.
Sophos XG has the ability to capture and display actual network packet information right from the management web interface. This is a great tool to determine what is actually happening "on the wire". Unlike firewall logs that can be turned off or configured to exclude logging of some traffic, a packet capture literally shows you every packet that the firewall has to process. Let's have a look at how to enable Sophos XG packet capture.
Previously we specified the IP address of the Fastvue server as a capture filter. We did this to only capture packets to and from that device. From the image below you can see that a packet capture shows a lot more detail than a log entry would. You can see both in and outbound request for the web browsing on port 80.
Note: Since the traffic we are looking for is UDP, we do not expect any return or ACK messages. If we were looking for TCP traffic, we would expect to see those like we did in the TCP Port 80 example. With UDP, you know that a packet was sent but there is no way to know if it arrived without checking the destination.
We've seen that there are packets flowing from the XG device to the Fastvue server on UDP Port 514. So it looks like syslog messages are correctly being sent. We can take it a step further and confirm that the messages themselves are legitimate syslog records.
Sophos XG's packet capture feature is a very useful tool when it comes troubleshooting connectivity issues. It provides a deeper level of information compared to looking at firewall log files. This is especially true in cases such as the one above, where there are no explicit traffic rules defined and limited visibility in the UI for the syslog traffic.
As we are trying to find a reason why some computers are having an issue with their real time programs and email, we are coming across alot of consumed packets and invalid traffic. Is there something I can look into to find out the cause of the issue. All the consumed IPs seem to be going to the real time programs.m We have firewall, IPS, and CFS rules put in but we do not have any traffic shaping implemented. We have a 1 Gig internet connection. Thanks for all your help
Packets showing Consumed does not mean that the packets are dropped my the XG , however, the Invalid Traffic does drop the traffic and must know if the packet is necessary for the communication or not.
Most recently VMware is saying that it is Sophos. They did two separate packet captures, one was at stage 0 and they were able to capture packets and we discovered that two VMs on the same virtual switch can communicate. The other was at stage 1 and it doesn't show any packets at all. When I had time to restart my physical host everything came back up good. Based on that VMware said "Please engage Sophos UTM team and review the configuration for any IOChain activity leading to blocking the traffic on the NIC."
I just got off the phone with Sophos for the first time since I passed that information along to them and they are saying their VM is not receiving packets which means it is a physical issue/VMware since it is a virtual machine. He agreed to pass the information along to higher people in their support staff, but seemed to indicate he strongly believed it was not their issue.
Some DNS traffic is classified as sophos-live-protection in our traffic logs. Has anyone else seen this? I only have logs 5 days back in time, so I cannot say when this started but it wasn't with the latest apps update. Our firewall is PA-5050 running PAN-OS 6.1.14.
UDP 53 is one of the standard ports used in the sophos-live-protection app signature. If you run a packet capture, check the queries to see if they are going towards sophos. Sophos uses specially crafted DNS packets to function, I believe this is how it does the live lookup functionality.
If that is the case then I would advise you open a case with TAC to get the traffic investigated, could be legimate or mis-identification. Your best bet is to run a packet capture to see what the query is that is trigging this.
After talking to TAC we found that it was indeed DNS queries from BYOD clients using Sophos Live Protection. I guess we could use some kind of application override to force this traffic to be identified as DNS, but instead we will just block sophos-live-protection.
I am seeing this on my network but I still think this is a mis-classification. If it was genuine live update traffic, surely it would not be routed via our DNS servers but instead would go directly from the client to sophos? Did you manage to confirm that genuine sophos live update traffic is still routed through the client's DNS servers? If so, this is bad because it is putting a lot of extra load on our domain controllers and BIND servers.
We concluded that the traffic is a genuine DNS request, but that the Sophos client adds a lot of content to the request and this makes PA change the appid from dns to sophos-live-protection. Here is the full reply I got from PA support:
I looked into this a while back but I didn't actually look closely at the traffic content. I don't think this is mis-categorised, sophos admit they use port 53 for their updates but don't mention that they actually tunnel it in DNS requests so I presumed the traffic was going directly between our clients and sophos until I noticed the flows were coming from our DNS server this morning.
I think I need to do some more digging because from what I can see each session transfers around 600kB, so if that means the actual signature updates are passed through the DNS servers, it may be a good reason to move away from sophos. If they just check to see if they need updates that way, it would be less of an issue, but 600kB seems a lot just for that.
I've set the integration to listen on port 9005 for syslog data and I've confirmed through traffic capture that my ELK stack is receiving UDP packets from my firewall. However, the data doesn't appear in Elasticsearch.
Thank you! I'm new to Elastic and Filebeat, but as far as I understand, Elastic Agent utilizes Filebeat to capture UDP syslog packets (which worked for me). By the way, Sophos does not allow to install or use agent directly
SD-WAN profile routing strategies can be based on first available or performance-based link criteria. Performance monitoring criteria includes jitter, latency and packet loss and can utilize multiple probe targets for PING and TCP probes. SD-WAN profiles automatically select the best link based on performance or according to your custom SLA policies that define specific values for maximum acceptable jitter, latency, or packet loss before re-routing over a better performing link.
df19127ead