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

Unknown traffic src'd from WAN

Setup

  • SFOS 17.0.0 GA
  • NAT = disabled; it is being performed by the device just upstream to the XG.
  • All users are authenticated as Clientless Users.

Issue

I am observing a fair amount of unknown traffic being sourced from my WAN IP address (192.168.7.129) destined for a variety of hosts.  All of this traffic shows as DENIED and is labeled as belonging to a variety of Clientless Users. A snippet of the traffic log is attached.

I masked the usernames but all other data is taken directly from the log.  Also of note is the In and Out Interface fields are blank.  

Any idea what this traffic is for and why it is occurring?



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

    by now you should have updated to v17.0.1 mr-1.

    Logging was increased in V17 which is some of your issue, the other issue is that the IP addresses are not part of your clientless group.

     

    Ian

  • Hi Ian,

    rfcat_vk said:

    Logging was increased in V17

    So are you saying the increase in logging relates to a defect with regard to log accuracy?  I'm not seeing how the XG should log traffic sourcing from the WAN IP and heading out to the Internet as being attached to a Clientless User - that just doesn't make any sense.

    rfcat_vk said:

    ...the IP addresses are not part of your clientless group.

     

    So it isn't possible to create a Clientless User without it being assigned to a clientless group and having an IP address specified.  In addition, all of the users in the log I posted are definitely Clientless Users as other traffic belonging to those users is logged as expected.

    What am I missing here?

  • Hi,

    you misunderstood, in v17 the logging was increased showing a lot mote denied connections.

    If you want clientusers to access the internet they must be in group and have an IP address or you must select any when using match users if you want control of the firewall rules they use.

    DHCP assignments are not related or affected by clientless configuration. You cannot create a clientless user without assigning an IP address.

    Blank ports indicate the firewall does not have a valid contrack entry so drops the attempted connection and marks it denied.

    Iave large numbers of similar drops in the middle of valid connections.

    The above is an extract from the logviewer.

     

    Ian

  • I'm not sure if you're completely reading my responses...I never mentioned any issue with my Clientless Users nor DHCP so not sure how that became part of the thread.  Not trying to be difficult here but it is somewhat confusing when feedback doesn't relate to what has been said previously.

    Anyway, there is no issue with Clientless User connections - those are working fine.  What I am saying is that the XG should not be sourcing traffic from the WAN port and logging it as being attached to a Clientless User connection - that is clearly a defect OR the system is lying to me.

  • I read your initial request for assistance and it talks about clientless users being in the report. My experience is that clientless users in that usually means they are missing from a clientless group and once added reduce their number of appearances in that report.

    What the report is stelling you at some stage one of your clientless users had a valid session to that external site which either failed or was dropped at one end and the other thought it was still open. The XG sees the incoming traffic as no longer valid and posts it to a log for you to review. As I sads earlier this additional information was only added in the V17 and according to the Sophos support during the beta can be safely ignored.

    Ian

  • While this may or may not be true, it doesn't explain why the source-IP is the WAN port.

    Also, I've seen you often comment that logs "...can be safely ignored..." merely because logging was increased in v17 - this just isn't true.  An increase in log verbosity does not mean the logs are meaningless.  One should only disregard a log message if (1) It is deemed generated in error ; (2) One knows the root cause for the log message is not of concern.

    Neither are the case here.