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

Sophos Firewall: v19.5 MR2: Feedback and experiences

Release Post: Sophos Firewall OS v19.5 MR2 is Now Available

The old V19.5 MR1 Post: Sophos Firewall: v19.5 MR1: Feedback and experiences

To make the tracking of issues / feedback easier: Please post a potential Sophos Support Case ID within your initial post, so we can track your feedback/issue.

This thread was automatically locked due to age.

Top Replies

ddcool over 2 years ago +3

Would be a relief to be able to also use FQDN objects in ACL exception rules, so you can use a DNS entry for proper remote support address maintenance

0 MikeBarber1 over 2 years ago

Where can info on disabling "19.5 MR2 will automatically disable web admin and/or user portal access from the internet (all WAN sources) after 90 consecutive days of inactivity." be found?. I do not want the firewall disabling access automatically. Yes I understand the reasons why this feature was added - and I still do not want it.
- +1 bobbylam over 2 years ago in reply to MikeBarber1
  
  ACL rules for accessing WebAdmin are not affected by this, and would not be disabled automatically even if there's no activity. So if you want a persistent way to access WebAdmin over WAN, recommendation is to apply an ACL rule.
  - 0 Gerhard Seemüller over 2 years ago in reply to bobbylam
    
    And access to the user portal, and thus the VPN provisioning, can be ensured using the ACL exception rule described in the release notes?
  - 0 Tony Gaddis over 2 years ago in reply to bobbylam
    
    This doesn't fully answer the question. Attempting to do so with Any as the source for an ACL still displays you cannot.
    "You can't set the source network to Any when you select HTTPS service and WAN zone. The firewall doesn't allow web admin console access from all WAN sources. "
    
    I do agree that it is a good thing to have but I would still like to have this as a feature.
  - 0 sanket.shah over 2 years ago in reply to Tony Gaddis
    
    Hello Tony Gaddis,
    
    Please go through release notes where it's mentioned that HTTPS access would require specific source to be selected. It won't work with "Any" source - Sophos Firewall OS v19.5 MR2 is Now Available .
    
    Web Admin access for specific IPs:
    
    We strongly recommend disabling web admin console access from all WAN sources (the Internet) to reduce the potential for a brute force or reconnaissance attack. Instead, we suggest that remote management of your firewalls be performed through Sophos Central which is free for all customers.
    
    However, if you absolutely need to provide WAN access to the web admin console, v19.5 MR2 enforces WAN access from specific IP addresses and networks using an ACL exception rule (Administration > Device access > Local service ACL exception rule). It will no longer be possible to enable web admin console access from all WAN sources.
    
    Regards,
    
    Sanket Shah
    
    Director, Software Development, Sophos Firewall
  - 0 LuCar Toni over 2 years ago in reply to Tony Gaddis
    
    You can use Internetv4 with all IPs in the Internet, if you want to go down that road.
    
    __________________________________________________________________________________________________________________
0 ddcool over 2 years ago

Would be a relief to be able to also use FQDN objects in ACL exception rules, so you can use a DNS entry for proper remote support address maintenance
- 0 alda over 2 years ago in reply to ddcool
  
  Hello ddcool,
  
  a FQDNs have long been supported in ACLs...
  
  Regards
  
  alda
  - 0 ddcool over 2 years ago in reply to alda
    
    That is not true. FQDNs can not be used within "Local service ACL exception rules".
  - 0 alda over 2 years ago in reply to ddcool
    
    Hello ddcool,
    
    hmm, really interesting and how is it possible that I have been using this feature for several years?!?
    
    I definitely recommend you to try this feature, I'm sure you will be very surprised.
    
    Regards
    
    alda
  - 0 ddcool over 2 years ago in reply to alda
    
    Feel free to post a screenshot showing that this is possible in Sophos XG(S) v19.5 or below (not Sophos UTM!)
  - 0 alda over 2 years ago in reply to ddcool
    
    Hello ddcool,
    
    as I wrote before, this feature has been supported for many years. It is naturally also supported in SFOS version 19.5.1 MR-1-Build278.
    
    I won't send any screen shot because you can try it trivially easily yourself. You need one FQDN for this, which you enter in the Source Network / Host field in the Local service ACL exception rule window.
    That is all.
    
    Regards
    
    alda
  - 0 ddcool over 2 years ago in reply to alda
    
    You mean this? Yeah funny it does not offer FQDN...
    
    Oh and what is this? Use FQDN-Host Object for Device Access ACL - Discussions - Sophos Firewall - Sophos Community
  - 0 alda over 2 years ago in reply to ddcool
    
    Really?!?
    
    I don't know about you, but it works for me.
    
    Regards, alda
  - 0 ddcool over 2 years ago in reply to alda
    
    I guess you just created IP host objects with FQDN in its name, but IP addresses as content. That is not an FQDN object, as it does not resolve anything
  - 0 alda over 2 years ago in reply to ddcool
    
    Hello ddcool,
    
    yes, you're right, sorry, I forgot that I have hosts records defined like this as FQDN.
    
    Well, again, all the more reason that I started using another firewall solution a long time ago. Something like that obviously works there, sorry...
    
    Regard
    
    alda
  - 0 LuCar Toni over 2 years ago in reply to alda
    
    There are plans to implement a FQDN Support for ACLs - Generally speaking: Using Services like Central for Access from external instead could be a good approach to access the firewall.
    
    There are even plans to build a SSO Access as a Partner directly to the SFOS Firewall of a customer (Partner Dashboard).
    
    Other approach could be using VPN Tunnels (To ensure a access).
    
    __________________________________________________________________________________________________________________
  - 0 ddcool over 2 years ago in reply to LuCar Toni
    
    All of them are valid points, but there are scenarios and customer whishes, which would benefit from having this feature. In general I think every object type should be usable within all modules of the firewall if possible.
  - View More
0 TheBalmasque over 2 years ago

After the update the Avira AV pattern update fails... My current pattern version numer is 1.0.421521
- 0 LuCar Toni over 2 years ago in reply to TheBalmasque
  
  From which version did you upgrade? And do you know (for sure) if the Avira AV Pattern were working before?
  
  Sophos upgraded the Avira Version in V19.0 MR1. See: https://docs.sophos.com/releasenotes/output/en-us/nsg/sf_190_rn.html
  
  __________________________________________________________________________________________________________________
  - 0 TheBalmasque over 2 years ago in reply to LuCar Toni
    
    I upgraded from version 19.5 mr1. But it seems it was a temporary error. Now the engine is on 1.0.421526. Thank you anyway. ;-)
- 0 MarekDalke over 2 years ago in reply to TheBalmasque
  
  It works fine on both appliances I've upgraded so far. Current version is 1.0.421526. Last successful update on 06:10:54, May 10 2023. The uprade from 19.5.1 MR1 to19.5.2 MR2 went fine.
  - 0 LHerzog over 2 years ago in reply to MarekDalke
    
    A bit more RAM usaged can be seen by now.
    
    Update was installed on small size XG106 as a test on Tuesday 6PM:
    
    pattern update fine so far
  - 0 Amodin over 2 years ago in reply to LHerzog
    
    One reason I don't want to upgrade, they limit home use to 6GB, yet forget about 64-bit usage and keep adding on mem usage. I'm sitting at 70% on average already as it is.
    
    OPNSense 64-bit | Intel Xeon 4-core v3 1225 3.20Ghz
    16GB Memory | 500GB SSD HDD | ATT Fiber 1GB
    (Former Sophos UTM Veteran, Former XG Rookie)
  - 0 JasP over 2 years ago in reply to Amodin
    
    70% is not particularly high for this type of device, it isn't a workstation or server. Memory management is generally pretty good. We have run multiple devices for years with a base of 4GB and 80-90% memory usage without issues.
0 jamesharper over 2 years ago

The day before this update came out we updated a customer from 19.0.x (19.0.2 i think) to 19.5.1, and it failed spectacularly. It seems to start up just fine but then as soon as the HA Auxiliary device joins it all comes crashing down. The Primary can ping maybe 1 in 3 devices on the network. We can connect remotely sometimes. Forcing a HA failover doesn't fix anything.

In the release notes of 19.5.2 I see that NC-115019 refers to "Primary device in HA becomes unresponsive.", which vaguely matches our issue, but could also refer to a completely different issue (eg that the primary freezes after some number of days). How can I find out when that bug started? That NC number is not mentioned in the known issues list, maybe because it is now resolved? If the bug was created in 19.5.[01] then that could be the cause. If not I guess i'll raise a case with Sophos support, but doing that is such a pain
- 0 Erick Jan over 2 years ago in reply to jamesharper
  
  Hi James,
  
  I'm sorry to hear that, and apologies for the experience, please do raise a support case and kindly share your case number here.
  
  Erick Jan
  Community Support Engineer | Sophos Technical Support
  Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
  If a post solves your question use the 'Verify Answer' link.
  - 0 jamesharper over 2 years ago in reply to Erick Jan
    
    I have logged a case. I would typically use the support case number as proof that the Sophos support caller is who they say they are, so i'm reluctant to post it here. I'll PM you
  - 0 Erick Jan over 2 years ago in reply to jamesharper
    
    Hi James,
    
    Received the case number, I'll also put a note on your case and further monitor it. Thank you
    
    Erick Jan
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  - 0 LuCar Toni over 2 years ago in reply to jamesharper
    
    By the way, your issue sounds like a general ARP Problem.
    
    https://doc.sophos.com/nsg/sophos-firewall/19.5/Help/en-us/webhelp/onlinehelp/HighAvailablityStartupGuide/AboutHA/HAArchitecture/index.html
    
    Check if the HA Cluster can "survive" this MAC Spoofing by checking the Switches.
    
    __________________________________________________________________________________________________________________
  - 0 jamesharper over 2 years ago in reply to LuCar Toni
    
    Yes it definitely does have that feel to it. Has there been a change between the previous working-perfectly version 19.0.1 and the new everything-is-broken version 19.5.1?
    
    The LAN port is a LAG across 4 ports, so if there was a change with LACP or something then that could maybe trip it up.
  - 0 LuCar Toni over 2 years ago in reply to jamesharper
    
    There are no changes, and this behavior is the same since Day1. We are using a virtual MAC and if the interface fails, the Failover will be done.
    
    So in case of Update and something does not work, you could do a failover to the other appliance to check, if this appliance accept the traffic.
    
    __________________________________________________________________________________________________________________
  - 0 jamesharper over 2 years ago in reply to LuCar Toni
    
    You can be sure I've tried failover over, failing back, rebuilding HA. Something has changed between 19.0.1 and 19.5.1 and it's broken our cluster badly.
  - 0 jamesharper over 2 years ago in reply to LuCar Toni
    
    Just to follow this up. We updated to 19.5.2 and still had the same problems. We then engaged Sophos Support to join us on a support session the next morning and everything worked perfectly. It turned out that 19.5.2 did actually fix the issues with 19.5.1, but the morning we tested the upgrade, the ISP had a major outage which fairly closely mimicked the issue we were having with 19.5.1 so it appeared that the issue was still occurring.
- 0 Joshua Drost over 2 years ago in reply to jamesharper
  
  I had that happen too during one of our HA upgrades. We had to remove and re-create the HA connection from scratch to get it to work. The secondary upgraded fine and took over but the primary was unresponsive, and had to be physically restarted to even get into it's GUI or SSH. Once we did that, we were able to go into the GUI, remove the HA completely from both, upgrade the primary, then re-create the HA.
  
  Frustrating endeavor because it was an active-backup HA, and the secondary didn't take over the license in the re-creation process. Had to remotely add an evaluation license for the necessary firewall features for it to function properly while we did the work. Hopefully it doesn't happen again since that serial number has now burned it's evaluations, but we do also have the option of adding a 1-month MSP license to it through Sophos Central Partner in that case.
  
  I think that the primary firewall should have another management IP address in case of these kinds of issues, separate from the regular address that they both take together when in HA, much like the secondary has. But it wouldn't have mattered in this particular issue as the only access available was console until it was rebooted. I'll need to set up OOB console access for these kinds of deployments going forward, or at least OOB power outlet access to force reboots. But I do hate shutting down non-gracefully, as that occasionally corrupts the PostgreSQL database.
  
  I wonder if the hardware could include a small battery (similar to RAID controller battery size) that does a graceful shutdown when no AC power is found? But that's a huge ask, as it's not an easy thing to implement without possible false-alarm shutdown events, and would have to monitor at the hardware level to be reliable, not the software level. Maybe the higher end versions have this? I was using an XGS 2100 if I remember correctly, so I wouldn't be surprised if bigger models have it, but I haven't looked.
0 Enrico van Egmond1 over 2 years ago

We were waiting for the SSL VPN routing problem with static IP assigned to the client to be solved with MR2. Unfortunately it still is not solved. It got worse instead. After assigning a static SSL VPN IP to one client it cannot access the LAN network anymore. Connection is established but no traffic to LAN is possible. If we remove the static SSL VPN IP from the user everything works fine. But we need static IP so we can access the device from the LAN on FQDN. With MR1 we had the problem that the device could access the LAN with static IP assigned but traffic from LAN to the connected device was not possible because of routing problem in the XGS. Does anybody have the same problem and is there a solution? The issue ID for this is NC-114163.
- 0 MarekDalke over 2 years ago in reply to Enrico van Egmond1
  
  Same problem here. Requests from the client are hitting the Sophos Firewall but replies are not routed in to the tunnel interface but to the WAN.
  
  After deleting the static IP from the user settings everything works fine and replies are hitting the tunnel interface
  - 0 emmosophos over 2 years ago in reply to MarekDalke
    
    Hello Marek,
    
    Would it be possible for you to open a case with Support, reference this community post and the NC-114163.
    
    Regards,
    
    Emmanuel (EmmoSophos)
    
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  - 0 MarekDalke over 2 years ago in reply to emmosophos
    
    Case has been opened. Support Engineer pointed an easy way how to test this with the Route Lookup from the Sophos Firewall Diagnostics Tools:
    
    Route to the static IP VPN client:
    
    172.16.255.250 is located on the Port2 172.16.255.250 is reached through the router X.Y.Z.W
    
    Route to the dynamic IP VPN client:
    
    172.16.255.10 is located on the tun0 172.16.255.10 is not behind a router
  - 0 emmosophos over 2 years ago in reply to MarekDalke
    
    Hello Marek,
    
    Thank you, I cannot find the Case ID under your account; can you share it.
    
    Regards,
    
    Emmanuel (EmmoSophos)
    
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  - 0 emmosophos over 2 years ago in reply to emmosophos
    
    Hello Marek,
    
    Thank you for the Case ID, you shared via PM; I can see the case is already escalated to GES for further investigation and troubleshooting.
    
    Regards,
    
    Emmanuel (EmmoSophos)
    
    Technical Team Lead, Global Community Support
    Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  - 0 Joshua Drost over 2 years ago in reply to MarekDalke
    
    I've seen similar cases, where routes to move traffic across tun0 were not automatically created in certain cases and were instead being sent out the default route. I specifically remember that I could only create the proper routes via the CLI but don't remember exactly why. But I do remember not seeing the expected routes when using the ""ip route show table all" CLI command.
    
    In my case it was across some IPSec tunnels instead of SSL VPN connections, but there's overlap in how those are treated in a Sophos. I would compare the full routing tables when the user is connected with a static versus the same user connected with a dynamic. I didn't like creating my routes like that because they are difficult to find unless you already know they exist, but it did work
  - 0 MarekDalke over 2 years ago in reply to MarekDalke
    
    Problem has been solved. In my case the root cause was the SD-WAN Route and its Traffic Selector where source network 172.16.255.0/24 and destination network object 'Any' were used in policy for traffic to the Internet.
    
    After replacing the source network with system object '##ALL_SSLVPN_RW’ and replacing the destination network 'Any' with 'Internet IPv4 group’ it started to work properly. Finally only the traffic to Internet is routed to the gateway and return traffic is reaching the static IP VPN client via tun1 interface.
    
    edit
    [edited by: MarekDalke at 8:49 PM (GMT -7) on 23 May 2023]
- 0 emmosophos over 2 years ago in reply to Enrico van Egmond1
  
  Hello Enrico,
  
  Can you share your previous Case ID, and if you haven't, can you create a new Case ID, and reference the NC number and the previous Case ID.
  
  Regards,
  
  Emmanuel (EmmoSophos)
  
  Technical Team Lead, Global Community Support
  Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
  If a post solves your question use the 'Verify Answer' link.
- 0 Giridhar Katti over 2 years ago in reply to Enrico van Egmond1
  
  Hi Enrico - We tried to reproduce this issue in our lab, both on VM and XGS. We see that the traffic is passing from the client static ip to the LAN and vice-versa. We dont see any problem.
  
  We would like to take a look at your setup. I will DM you, to check if we can get the Access ID
  - +1 Giridhar Katti over 2 years ago in reply to Giridhar Katti
    
    Hi Enrico van Egmond1 - We had a discussion on this issue internally. Can you please disable this "any" "any" rule(3rd rule in the list) from the SDWAN routes ? It should solve your problem.
  - 0 Enrico van Egmond1 over 2 years ago in reply to Giridhar Katti
    
    After disabling the SD-WAN route the Static IP SSL VPN works good. Traffic is routed correctly from VPN connected device to LAN and from LAN to the VPN connected device with the static IP. It's still strange why this is no problem on dynamic IP's with SSL VPN connected devices.
  - +1 Giridhar Katti over 2 years ago in reply to Enrico van Egmond1
    
    Hi Enrico van Egmond1
    
    When SSLVPN is configured with a static IP address, SSLVPN service sets nfmark mark on SSLVPN tun interfaces.
    
    ip link set tun0 nfmark 0x300
    
    ip link set tun1 nfmark 0x301
    
    Note: Based on the number of OpenVPN instances SSLVPN service will have an equal number of tun interfaces.
    
    So if SSLVPN static IP connections have a matching SDWAN route then the 0x300 mark is overridden by the SDWAN route, which causes SSLVPN connections to send traffic on the SDWAN gateway instead of the tun interface.
    
    Where as for SSLVPN dynamic ip, when we assign the Dynamic IP to the user, we provision the route on the client, which is in the same network as tun interface. Hence there’s no issue w.r.t the traffic.
0 JasP over 2 years ago

This release appears to have broken our SNMPv3 monitoring.

We use AES Encryption and MD5 Authentication (because that is the only combination that fits with our monitoring software) and since upgrading, we can't connect.

I have tried deleting and recreating the settings on each end but it didn't fix it. For the moment we have changed to SNMPv2 monitoring.
- 0 ShrikantSophos over 2 years ago in reply to JasP
  
  Hi JasP Was this upgrade from 19.5MR1 to MR2? There is no known change in SNMP for 19.5MR2 from 19.5MR1. Dev team would like to investigate this more. Is it possible to share the device access id in private message to me / Avinash Aathreya . Also share the snmp config and remote command that is tried to check the connectivity. If access id not possible not , these log files may help to start investigation - /log/snmp.log /log/syslog.log /log/csc.log , along with config -Shrikant
  - 0 JasP over 2 years ago in reply to ShrikantSophos
    
    Yes the upgrade was from 19.5MR1 to MR2. Although there may have not been any changes in SNMP, clearly there have been changes in Administration access so something may have got unintentionally broken amongst those changes.
    
    For some reason, I have no option to message Avinash Aathreya but I can message ShrikantSophos. How would you like to proceed?
  - 0 ShrikantSophos over 2 years ago in reply to JasP
    
    Yes - Please message me ie ShrikantSophos . Will have it checked.
  - 0 Avinash Aathreya over 2 years ago in reply to ShrikantSophos
    
    Hi JasP - We tested the migration from 19.5MR1 to 19.5MR2. Used a free SNMP Tool to retrieve sample OID which works without issues. As discussed over Live debugging session, pls help us with the snmpd logs & Packet capture (pcap) outputs for further analysis.
    
    Attached screenshot of FWVersion read across MR1 & MR2 for your reference.
  - 0 JasP over 2 years ago in reply to Avinash Aathreya
    
    Avinash Aathreya I replied to your PM in some detail but when I 'sent' it, I got the message that I couldn't sent to you and all my text was lost
    
    I used the same tool as you to test SNMPv3 and it worked. So I tried the tool I had been using previously, and that worked. So I switched our monitoring software back to SNMPv3 and that worked! I haven't made any changes since our debugging session on Friday.
    
    Last night I rebooted the XGS and our monitoring software to check that everything still worked, and it does. I have setup new credentials for SNMPv3 (as I had shared the previous credentials with you by email) and that worked fine too.
    
    It is very frustrating to have no idea of what the issue was but clearly there is nothing further we can do now. Hopefully it was just a 'one off' problem and that is the end of it.
    
    Thanks for your assistance with this.
  - 0 Avinash Aathreya over 2 years ago in reply to JasP
    
    Hey Jason,
    
    Glad to know that the problem is resolved on your end. Agree its annoying when things start working w/o changes/ root causing. Feel free to reach out in case you run into the issue again. Also, you now have the debugging tips which I hope will be handy for any problems in future.
    
    Thanks,
    
    Avinash
0 LHerzog over 2 years ago

Some finding about inaccessible userportal after upgrade:

--

Userportal on WAN was enabled in 19.5.1. after the upgrade it was still enabled on Webadmin but it was inaccessible.

It is configured to use a custom port.

TCPdump showed no packets coming in for the requests.

disabled userportal on WAN zone, saved

enabled it, saved

--

tested access to the userportal again.

tcpdump showed packets coming in but not going out.

re-checking the status of userportal on WAN zone - it was disabled, regardless I re-enabled it before

enabled it again, saved

--

userportal was working again for the clients.
- 0 deeptibhavsar over 2 years ago in reply to LHerzog
  
  Hi LHerzog ,
  
  Thank you feedback.
  
  Request to share access on PM.
  
  Regard,
  
  Deepti
0 Ben@Network over 2 years ago
We have an interesting problem after updating to MR2 (from 19.5-MR1). We have a web server that is made available via a DNAT rule in the DMZ. From the WAN this is not a problem, this works.

Since the update, we have some networks on the LAN that can no longer access the web server. Other networks from the LAN have no problem with this.

With a tcpdump I have seen that requests from the LAN without NAT go directly over the WAN interface to the Internet:

XGS5500_CI02_SFOS 19.5.2 MR-2-Build624 HA-Primary# tcpdump -i Port2 host 10.0.2.200
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on Port2, link-type EN10MB (Ethernet), capture size 262144 bytes
18:34:46.269798 Port2, OUT: IP 10.0.2.200.50011 > 10.0.5.80.https: Flags [SEW], seq 454467722, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
18:34:46.519736 Port2, OUT: IP 10.0.2.200.50012 > 10.0.5.80.https: Flags [SEW], seq 3042186263, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

10.0.2.200 is the Client in LAN, 10.0.5.80 is the private IP of Web-Server in DMZ, Port2 is the WAN-Port

I have tried with different source IPs (in my NAT rule) to access the web server from the LAN. Whenever the DNAT rule takes effect, the traffic goes to the WAN without NAT instead of the DMZ.
If a post solves your question please use the 'Verify Answer' button.
- 0 Erick Jan over 2 years ago in reply to Ben@Network
  
  Hi Ben,
  
  Thank you for reaching out to Sophos Community.
  
  Apologies for the experience. Would it be possible to raise a case ID and share it here?
  
  Erick Jan
  Community Support Engineer | Sophos Technical Support
  Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
  If a post solves your question use the 'Verify Answer' link.
  - 0 sanket.shah over 2 years ago in reply to Erick Jan
    
    Hello Ben,
    
    Would it be possible for you to share access ID via PM?
    
    Also, could you please share working and non-working tcpdump from LAN side clients as some networks are working as you mentioned?
    
    Regards,
    
    Sanket Shah
    
    Director, Software Development, Sophos Firewall
  - 0 Ben@Network over 2 years ago in reply to sanket.shah
    
    Hi guys,
    
    the Case ID is: 06543219. I also send the tcpdumps to Sanket and Support Access ID.
    
    Ben
    
    If a post solves your question please use the 'Verify Answer' button.
  - 0 Vivek Jagad over 2 years ago in reply to Ben@Network
    
    Hi Ben@Network ,
    
    Thank you for the SR id, we'll get this expedited !
    
    Thanks & Regards,
    _______________________________________________________________
    
    Vivek Jagad | Team Lead, Technical Support, Global Customer Experience
    
    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case | Security Advisories
    Compare Sophos next-gen Firewall | Fortune Favors the prepared
    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.
  - +1 Ben@Network over 2 years ago in reply to Vivek Jagad
    
    Hi guys,
    
    I was able to isolate the problem with support. Shortly after the update, we had to set an SD-WAN route for a specific tunnel that overlapped with the IP scope of another tunnel (both via tunnel interfaces). To make this work we had to adjust the routing order. On the firewall, there was a forgotten config fragment that for specific networks (the exact networks it didn't work from), an SD-WAN profile should run Internet traffic over the WAN port with the least amount of jitter. By adjusting the routing order there was a collision with the DNAT rule. We disabled the SD-WAN route in doubt and now everything works as usual.
    
    Thank you for the very quick analysis by Sophos support. So I can confirm that the MR-2 is running stable.
    
    Cheers,
    
    Ben
    
    If a post solves your question please use the 'Verify Answer' button.
0 DBASQL over 2 years ago

Agree with the others seem reasonable to disable HTTPS to WAN interfaces but DNS named objects should be present in ACL list.

Thanks!
0 twister5800 over 2 years ago

ALso a SD-WAN issue here:

With MR1, all works, we are routing all traffic between two Sophos Firewalls with RED tunnel with this policy:

With MR-2 all trafiic is being blocked thus not using the route.

We have reverted back the firmware this morning, but will try later with other options.

Any suggestions? :-)

-----

Best regards
Martin

Sophos XGS 2100 @ Home | Sophos v20 Technician
- 0 sanket.shah over 2 years ago in reply to twister5800
  
  Hello Martin,
  
  Do you have "drop packet capture" logs of traffic being blocked?
  
  Regards,
  
  Sanket Shah
  
  Director, Software Development, Sophos Firewall
  - 0 twister5800 over 2 years ago in reply to sanket.shah
    
    Hi, beecause the fw got restarted.
    
    As with UTM, is there not any way of getting the traffic log files out, ex. for the last day?
    
    Local logging is enabled, but cannot find any data in the /log dir.
    
    We do no have syslog server implmented here.
    
    -----
    
    Best regards
    Martin
    
    Sophos XGS 2100 @ Home | Sophos v20 Technician
  - 0 sanket.shah over 2 years ago in reply to twister5800
    
    Hello Martin,
    
    You may want to use following KBA articles to debug dropped/blocked traffic.
    
    https://support.sophos.com/support/s/article/KB-000036858?language=en_US
    
    https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/138132/sophos-firewall-how-to-troubleshoot-dropped-packets
    
    Regards,
    
    Sanket Shah
    
    Director, Software Development, Sophos Firewall
View More