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

Missing option for enabling notification of "WAN interface up"

Hello,

Running Sophos XG v16.05.7 MR-7 w/ 2 interfaces - 1 LAN and 1 WAN.

When I initially setup my FW, there was an option to enable the notification of when the WAN interface comes online.  I enabled this and the notification does indeed work.  However, once this option was set, it then disappeared.  When I browse back to the proper location (Configure --> Network --> Interfaces --> WAN), all of the network type options are there but the previous WAN link notification setting is just gone.

I suspect this is a defect.

Thanks in advance for any insight and help you can provide.



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

    do you have notifications set in Administration -> Notification settings

    Ian

  • Well, there's really not any global notification enable\disable setting.  There is a setting to enable IPSec tunnel up\down notifications and then of course the to\from e-mail addresses and the option to select the Built-in or an external server.  I have tested both and am currently using the latter.

    As an aside, I have a separate thread started to discuss issues with the Built-in server not working properly as well as no log data for notification emails sent successfully - in essence, no way to check SMTP behavior in the logs.

    Thanks.

  • Hi,

    I have receive notifications about the WAN link going up and down, but I am not sure where I find the notification enable setting, still looking.

    If you look in log viewer system you will see the mail sent messages also look in log viewer email tab.

    Ian

Reply
  • Hi,

    I have receive notifications about the WAN link going up and down, but I am not sure where I find the notification enable setting, still looking.

    If you look in log viewer system you will see the mail sent messages also look in log viewer email tab.

    Ian

Children
  • That's the exact issue I'm discussing - after you enable the setting, it then disappears...

    Also, there is no evidence in the Log Viewer of the actual notifications being sent.  The underlying events that would trigger the log entry are in the Log Viewer but there are no entries that specifically note the e-mail notification being sent.

    That said, while those type of entries are nice to have, that's not really to which I'm referring.  What we want is to have the SMTP communication sessions logged much like they are on any machine that communicates with an SMTP server.  Also, this type of technical detail doesn't really belong in the GUI-based Log Viewer - far too much data for that.  Information such as this is more often accessed and reviewed via CLI.

    There are a bunch of logs in /log but none appear to have the actual SMTP communications that relate to the notifications I receive.

  • Interestingly, when I setup my test XG with MR7 then v17b I had a lot of trouble getting the mail both notifications and users to send and the logs were full of failed messages, then successful ones, now nothing. Since then I have fixed the mail configuration (ISP doesn't allow relay), changed the BIOS time and restarted the XG a couple of times, but no version updates, very strange. On the V17b I receive messages for the link going down and being restored.

    Ian

  • That's very close to the same behavior I have seen as well.  I put this in the other thread but basically, the failed SMTP communications are in the /log/awarrenmta.log file but nothing relating to the successful SMTP communications is found.

    I originally thought that the /log/awarrenmta.log file was used only for Built-in SMTP comm but after I changed to external, I still see the failed attempts when trying to re-send previously queued notifications.  

    Perhaps the queued e-mail retains the original SMTP server setting it obtained when the message was originally generated so any change to the SMTP server selection will have no effect on already queued email.  If so, then that would explain why the strange observations...

    In any event, it would be great to know where the external SMTP server communications are logged.

  • Did you ever resolve this as I am the same - enabled it way back but now cannot find any settings to change it....

  • Hi Ian,

    As far as I can tell, this is still a one-way street kind of thing.  Once, the notification is enabled, then it will basically stay enabled until some future event modifies that part of the config.  I haven't tested what might be required to do that but I suspect resetting the config get it done - kind of extreme however...

  • Thanks cyberzeus,

     

    Seems a bit extreme for an email notification :-)

    Maybe one day we will find the config as I want to change it - I get notifications when a WAN Link comes up but not drops out.

  • Ian Melton said:

    Seems a bit extreme for an email notification :-)

    Defintely

    I get notifications when a WAN Link comes up but not drops out.

    If you have a single WAN port and your email server is accessible only via the WAN port, then this may make sense.  I don't think the XG caches the link down messages - at least not reliably.  In my deployment, I actually get both up and down notifications but that is because I have dual WAN links to diverse ISPs and both links are symmetrically redundant.
  • I also have dual WAN links with different ISP's.

     

    Also different types - PPPOE and STATIC

    I get the came up - but not went down :-(

  • Yeah - that's a little strange.  I find I do miss some notification emails every now and then.  I am able to review my email server logs and when a notification email is not received, I see no evidence, on the SMTP server, that the XG is sending the email which means the failure is happening at the XG.  And unfortunately, there are no SMTP logs messages at the XG so trying to figure out why this occurs is challenging.

    I think the notification subsystem is still somewhat buggy and could also benefit from some feature enhancements...