Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Subscribers 27 subscribers
  • Views 7992 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

XG not logging all dropped packets?

FrancWest

SFOS 17.1.0 GA. It looks like the logviewer doesn't show all dropped packets.

For example, I have an incoming NAT firewall rule that restricts access to specific hosts only. These hosts communicate every second with a device hosted behind XG. Once I remove one of the allowed hosts from the list, this host of course looses it's connection. However, I don't see any blocked packets to the destination port (8080) the NAT rule is configured for. I do see 'allow' lines, but no 'denied'.

Since I must modify the rule from time to time because some hosts have dynamic IPs, I can't lookup the IP anymore from the log since it doesn't appear in that.

Franc.



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

    I did some more testing. I took a packet capture and in there I can see that the packets are being blocked. Status is 'violation' and reason 'Local_ACL' with the IP address I need. However, these blocked packets don't show up in the logviewer. I'm coming from UTM and in there you could see everything in the packet filter logs. Why not in XG? This makes troubleshooting much more difficult.

    Franc.

  • +1 in reply to FrancWest

    Hi,

    it is true, XG does not log in the current build dropped packets in case XG does not find any matching rule. 

    Example: you want to build up LAN to WAN Port 1234 and you dont have any rule, you won´t see the drops in the logviewer. But you can test the framework with the policy tester and you will see, there is not rule. And without rule, there can´t be traffic :) 

    cheers

  • 0 in reply to LuCar Toni

    Hi,

    So that would  mean it can only show allowed packets in the log? What’s the use in that then? You can filter on denied but that would never occur? Isn’t a log mainly used to reveal things that aren’t allowed?

    Franc.

  • 0 in reply to LuCar Toni

    In UTM I use the packet filter log a lot to troubleshoot firewall rules. Why isn’t host x able to connect to host y? With XG I can’t do that anymore since the log doesn’t report these kind of things anymore?

    How do I troubleshoot then?

  • 0 in reply to FrancWest

    As mentioned before.

    If you have an issue with a connection, check the policy checker. 

    This is not possible in UTM. If you have a issue with Client A to Server B, you have to check, whether there is a block or not. In XG, you can just insert the information in the policy tester and it will show you the matching rule or if you dont have any rule.

    It is basically a lot simpler to troubleshoot than UTM. 

  • 0 in reply to LuCar Toni

    Ok, but in my specific case where I need to get the new dynamic IP of a host that previously connected fine, the only way to get this is to do a packet capture?

  • +1 in reply to FrancWest

    So - Yes. But tbh XG gives you more ways to see, what is happening than UTM.

    There is a drppkt and tcpdump with more information.

    The Packetfilter.log on UTM only covers the stateful firewall (and only if you have logging on in the specific rule). I dont want to go further off topic in the UTM vs XG, but i think, XG gives you more power in troubleshooting than UTM. 

Reply
  • +1 in reply to FrancWest

    So - Yes. But tbh XG gives you more ways to see, what is happening than UTM.

    There is a drppkt and tcpdump with more information.

    The Packetfilter.log on UTM only covers the stateful firewall (and only if you have logging on in the specific rule). I dont want to go further off topic in the UTM vs XG, but i think, XG gives you more power in troubleshooting than UTM. 

Children
No Data