Disclaimer: This information is provided as-is for the benefit of the Community. Please contact Sophos Professional Services if you require assistance with your specific environment.
Hi,
Based on the discussion and queries we have observed on various threads, here is the things to know about new decoupled NAT and firewall changes in v18.
Update - This in-depth video has been produced to help explain the new NAT changes in SFOS v18: https://player.vimeo.com/video/376241042
1) What is changed related to NAT in Sophos firewall v18? What is Decoupled NAT? Why we changed?
with v18, Sophos Firewall has moved towards more standardized NAT design in which network translation configuration is now decoupled from firewalling configuration for better manageability in the larger sized deployments.
Starting Sophos firewall v18, NAT is now a separate rule table that will be traversed from top to bottom prioritized rule set for network translation decisions. The configuration offers better flexibility, manageability with less number of NAT & firewall rules. With v18, Sophos Firewall’s enterprise NAT capability is now at par with other competitive players.
The new design offers ease of configuration and management for all NAT capabilities:
Based on what we have been hearing from our customers, v18 now removes confusing business application firewall rule type existing in v17.x and earlier. destination NAT capability of the biz apps rule has been folded into the same NAT rule. Single firewall rule type can now achieve WAF (as a part of action) and other security configurations.
For customers who don't want to manage a separate NAT rule table, Sophos firewall v18 offers a differentiating LinkedNAT functionality - refer LinkedNAT specific FAQs for details.
2) I am running v17.x; will there be any impact/ behavior change on my existing deployment (specific to NAT) if I upgrade to v18?
No. We have implemented the migration in such a way that it will automatically migrate v17.x NAT configuration (integrated into firewall rule) to v18 NAT configurations. You need not to take any manual steps.
When you migrate from v17.x to v18, you would see many LinkedNAT rules already created – many of them could be with similar source NAT translation, for example – many rules with MASQ as source translation. We cannot consolidate/ optimize the same automatically during migration as there could be deployments with firewall rules on v17.x without any NAT configured. You can decide to manually optimize the NAT table by creating single source translation NAT rule that takes care of translating source for multiple firewall rules, for example - single MASQ rule at the bottom of the NAT table. And you can delete multiple LinkedNAT rule created during migration.
3) After upgrading to v18, I see many LinkedNAT rule created on the NAT rule table. Is this normal? Can you not optimize this further in the migration?
We have implemented the migration in such a way that it will automatically migrate v17.x NAT configuration (integrated into firewall rule) to v18 NAT configurations. You need not to take any manual steps.
When you migrate from v17.x to v18, you would see many LinkedNAT rules already created – many of them could be with similar source NAT translation, for example – many rules with MASQ as source translation. We cannot consolidate/ optimize the same automatically during migration as there could be deployments with firewall rules on v17.x without any NAT configured. You can decide to manually optimize the NAT table by creating single source translation NAT rule that takes care of translating source for multiple firewall rules, for example - single MASQ rule at the bottom of the NAT table. And you can delete multiple LinkedNAT rule created during migration.
4) After upgrading to v18, I see a non-editable checkbox on migrated firewall rules that says "Do not apply this migrated rule to system-destined traffic". Why it is there?
This is to retain the rule matching behavior of v17.x even though we have removed Business application rule type.
In SFOS 17.x and earlier, although business application rules and user-network rules were listed in a single rule table, Sophos Firewall evaluated these rule types independently to find matching criteria. For system-destined traffic (example: accessing Sophos Firewall services) and incoming traffic (example: to internal servers) that matches a destination NAT business application rule, it ignored user-network rules and matched the traffic with business application rules.
From v18, Sophos Firewall has removed the distinction between business application and user-network rules. It now offers both as firewall rules. To ensure that the consolidation does not affect the rule-matching behavior of earlier versions, it will continue to ignore migrated user-network rules positioned above migrated business application rules for system-destined traffic and incoming traffic.
This is a read-only checkbox in the firewall rule that tells system to retain rule matching behavior of v17.x even after migrating onto v18.
5) I am creating a firewall rule for DNAT (destination translation) rule. Why should I configure Dst Zone match in firewall rule as (mostly) local zone (LAN/ DMZ). And, why should I configure Dst network match in firewall rule as original Dst IP (WAN IP on Sophos Firewall)?
When you create firewall rule for NAT rule in which destination is translated, you would match Dst zone as the ultimate zone in which the traffic would terminate (that is local zone – DMZ or LAN). However, you would (want to) match against the original destination IP (WAN IP on Sophos Firewall), here’s why:
6) What is LinkedNAT?
With v18, Sophos firewall has moved towards more standardized NAT design in which network translation configuration is now decoupled from firewalling configuration for better manageability in the larger sized deployments.
However, For customers who don't want to manage a separate NAT rule table, Sophos firewall v18 offers a differentiating LinkedNAT feature to grandfather existing customers over to the new design in the long run. The linkedNAT feature is fundamentally designed to provide inline source NAT rule creation from firewall rule. Matching criteria for the LinkedNAT rule is linked with the respective firewall rule, admin only needs to configure or edit the Src translation decision in the LinkedNAT rule.
This means LinkedNAT rule will only be applied to the traffic matching that specific firewall rule. However, if standard NAT rules are placed before the linkedNAT rule that match the traffic, the matching NAT rule would apply. That means, LinkedNAT does NOT guarantee that it will be matched for respective firewall rule traffic (if admin creates standard NAT rule before LinkedNAT). NAT rule table will always be matched from top to bottom priority order. There is no special or reserved priority in execution for LinkedNAT rule.
LinkedNAT rule is only possible for SNAT (source translation) configuration, not for Destination translation (DNAT).
7) Is it mandatory to use LinkedNAT? Where should I use LinkedNAT?
It is not mandatory to use LinkedNAT. With v18, Sophos firewall has moved towards more standardized NAT design in which network translation configuration is now decoupled from firewalling configuration for better manageability.
If you have a small scale deployment (small set of firewall rules) and you don't want to manage a separate NAT rule table, you can create LinkedNAT directly from the firewall rule and ONLY configure Src translation decision while matching criteria are automatically linked with the respective firewall rule.
If you have to differentiate SNAT configuration based on Users or Schedules criteria, LinkedNAT rule becomes mandatory there. However, such configuration need is very rare, we have NOT observed such configuration in practical deployments. Also, LinkedNAT rule is only possible for SNAT (source translation) configuration, not for Destination translation (DNAT).
8) What is the new disabled “Drop ALL” rule at the bottom of the firewall rule table?
The default drop rule provides visual indication to user / admin that if none of the firewall rule gets match, traffic will be dropped.
You reported about two specific challenges that admin faces in v17.x.
Currently, the logs that you see with firewall rule id ‘0’ are NOT for the traffic dropped by Drop ALL rule. In later EAP releases, we would replace them with “N/A” as those are for the traffic dropped before the firewall rule matches – for example – invalid traffic. And actual logs for traffic dropped by Drop ALL default behavior will be available in the release post v18. Meanwhile – as a workaround, one can add a drop rule at the bottom to log the dropped traffic not matched by any other firewall rule.
9) Do I have any demo/ training on how to configure various NAT in the new design?
To help you evaluate Sophos firewall v18 better in this early access program, here is the interactive training/ work through course - video along with the PDF handout and speaker notes. Here is the interactive course to work through Sophos Firewall v18.0:
Sincerely,
Your Sophos Sophos Firewall Product Team
Let me try to put some experience I had during these days. The goal was migrating 27 DNAT rules from another Firewall to XG v18. Since it is a DR site and no disasters were "planned" for the testing time, I dediced to share with 5 guys the project of migrating the DNAT configuration from the current product to XG v18. I did not tell them how to create the DNAT. Since Sophos is "security made simple" I told them: lets migrate the rules you have on XXX to v18 but without using online help, documentation, only with your experience and Sophos XG v18 interface.
Then, I decided to show them v17 interface from a customer site. Apart some questions regarding NAT, the Wizard helped them to understand how to create the rule and they did it correctly on v17 environment (it was a test on a production installation, so the rule was disabled and deleted afterwards)
Back to v18, they tried again: still wrong. Then I showed them the Sophos v18 training course.pdf and they said "no way, really?" At the end, in the firewall rul:
On the NAT, what the guys have done:
This is the test I conducted with the help of 5 guys. Thanks to them. So my considerations are:
Firewall section:
Names you used are just confusing. Listeners are much better that what you use at the moment. Decoupling NAT and Firewall rules is a nice feature and idea, but better names and wizard can reduce confusion and ticketing to Sophos.
Other improvements:
The firewall rule works as the last nat catches the traffic. NAT icon should be coloured.
I will take a sceenshot of my reply. Just in case the reply is deleted.
Hello Luk,
I have to take off my hat before you, I wouldn't have so much patience to prepare such a test. However, I think the result of your test is indicative of the "quality" of implementing NAT rules in v18 EAP1. At the first moment (when I saw the DNAT rule after migration from v17.5 MR8) I did not believe what I saw. If you have practical experience in configuring firewall and NAT rules, then you are not able to understand it and the only result is a pleasing back pain from the endless shaking of your head ...
However, PMParth tries to tell us that in this way all comparable firewall manufacturers implement NAT rules.
I can assure him that, as the DNAT is implemented in v18 EAP1, it certainly does not implement it by comparable firewall manufacturers. Just look for "How to setup in Fort*gate DNAT rule" and what a surprise, the implementation of DNAT rules is exactly the same as in UTM v9. Yes, they use something called virtual IP address for this purpose, but again the function of this object is very logical at first sight. And then they use this object in a classic DNAT rule. Who is interested can check it here
https: //docs.fort*net.com/document/fort*gate/6.0.0/cookbook/186598/port-forwarding
I could also shake my head after reading the following sentence: "The configuration offers better flexibility, manageability with fewer NAT and firewall rules."
I probably live in another space-time, because so many NAT rules I have never needed in v17.5 as I need now. While in v17.5 I needed a few DNAT rules and I solved most of the Internet traffic using several MASQ rules, now I count the NAT rules to tens! And I have replaced some linked rules with MASQ rules.
Why is Sophos still trying to convince me of something that's not true?!
Regards
alda
Alda,
I know even that product since 2005. Sophos UTM9 has some unique features and UI designed that no one on the market can compete...The Firewall creation wizard introducted on XG is a nice and well accepted feature and reflect the "security made simple" concept. As I wrote, remember we ISA Server 2000. Publishing OWA, FTP, HTTP/S was very simple and straight-forward. No one is using that old method to publish servers anymore (expect for XG v17 and XG v16). II even used the "Client Certificate authentication" mechanism...
Anyway, let's keep focused on XG and the thread clean. We are here to give feedbacks to Sophos. I had the time to spent 4 hours with a customer where I have strong relationship. This was a personal test to understand if I am too old for understand new technology or maybe something needs to be revisited from Sophos side.
Keep posting, Alda. If you can provide real feedback as I did, this will help to improve the product and community.
Thanks
I'm with Alda here Luk. Hats off to you for 1. coming back and 2. taking the time to even do this.
I spent a little bit of time with v18 testing and just reverted as I was so thoroughly disappointed...I just had to shut it down. I feel like all this time waiting has been for nothing when we could have been moving to other solutions (we have been waiting since 2017 for this...really). How this Firewall/NAT UI even passed an internal UAT is beyond me. Reading the justifications now just seems like a lost cause.
At least with v15 they quickly realized that the icons in place of an actual name was silly and changed it. I just hope that Sophos comes to their senses and admits that this design just isn't "simple" and beyond intuitive and modifies it in time for a v18 GA.
axsom1 said:How this Firewall/NAT UI even passed an internal UAT is beyond me. Reading the justifications now just seems like a lost cause.
I am with you. If people like us or with years of experience in the field, would never accept a layout like this.
It is still a beta and I really hope that someone will reply with a :”thanks for your input, we will review the nat and firewall layouts before ga “
If it is not the case, we will take our decisions. V18 was promised as the revolution but here we are complaining about bases things like ABC. I do not want even mentioning reports and logging as we need to keep clean this topic. To Sophos: I am interested into participating into the SDLC, UAT and collaborate somehow with Sophos. Feel free to reach me via email or phone.
Regards
Hello Sophos,
I agree with Luk. I think many interesting features are implemented in v18 EAP1, such as DPI engine, SSL / TLS rules, Kerberos, DKIM, etc. However, each administrator configures these features in a second sequence only after configuring basic security features such as firewall rules and NAT. And here you can (must) always get the most points. This is the daily work of the administrator. Here the administrator cannot fumble and think "what did the developer mean when he implemented it that way?" Then a very poor implementation of these basic security features will not save even the first post of this thread. If the implementation is very well done, no such post is needed at all. Everyone will subconsciously say "of course, otherwise than in this way it is not even configurable". I think you have largely succeeded in implementing the firewall rules in v17.5, but at least as far as the links between the firewall rule and the NAT rule are concerned.
Please be inspired by what you have at home. Please overcome the pride in yourself that you know best how it should be implemented. Because simplicity is beauty. Astaro had the implementation of NAT rules so simply implemented that at first glance, everyone understood. Please take this implementation of NAT rules, change it to XG GUI, add interface matching criteria and you will be surprised by the result. Use the drop-down list in the NAT rule section of the firewall rule to create NAT rules as needed or select from existing NAT rules. I think there is no need to think of anything else, new and avangard.
Certainly others will add their possibly different view of how the NAT rules should be reworked. But surely everyone agrees that implementing NAT rules is unusable. At least I did not record a single positive statement on the current implementation of NAT rules.
Yes, there is still a problem with logging and log management, but I am not so naive and I understand that it is still a long run. So hopefully we will see it in the version v18.5.
Regards
alda
With CheckPoint firewalls, most NAT Rule are created automatically, if need be. Since the end of 1990s.
Sophos NAT is very similar with Mikrotik.
Clearly a NAT wizard is required for those who use XG's WEB only so often. Or some form of templates. But at the same time we also need to keep the actual "manual" type. Most confusion comes from the screen layout and naming convention.
Paul Jr
PMParth said:For customers who don't want to manage a separate NAT rule table, XG firewall v18 offers a differentiating LinkedNAT functionality - refer LinkedNAT specific FAQs for details.
I forgot...for customers: which customers? I did not find anyone on community that is happy with the new NAT table and Firewall rule. Decoupling is ok but what we are complaining is how you put menu, options together.
Landed here after finishing my derivatives calculation with the help of derivative tool. Thanks for this information. It is useful
I agree that it was much easier in Version 17.x to configure a DNAT Rule.
Also it is much easier with Sophos UTM as it is in the current state of v18 EAP.
One Problem I see is, that it is not possible to automatically create a firewall rule for the DNAT Rule but you have do it on your own.
Otherwise I agree with luk.
There need to be changes before v18 is released. Other wise it's just more complex as before which shouldn't be the target here.
I actually understand NAT as presented in v18. I am not saying its easy or intuitive. The design picture for v18 is spot on but I would suggest a couple of changes that probaby won't need a whole rewrite.
1. Leave DNAT rules as we had before. Every version doesn't need new confusing setup. Leave things alone that people were generally happy about.
2. In the design picture we can clearly see multiple firewall rules bound to one NAT rule. Thats possible when we put a generic NAT rule and don't tie it to any firewall rule. Why can't we manually link a firewall rule to any NAT rule that we want? It will create single NAT rules that are tied to multiple firewall rules and we won't get 50 rules when migrating. Just one single rule tied to 50 firewall rules. Clean and simple. On the other hand whats clean and simple to me maybe more confusing and top down rule design has been a standard in firewall since their conception.
Everyone will have different ideas on how to implement #2 above. As others have said from a technical point of view this is not bad. I actually understood the concept when LuCar Toni posted on how he was doing NAT in one of his posts before all the reading material became available. The point remains that it has to be explained either verbally or by KB/manuals before the concept makes sense and that is not security made simple.
dear all
i have working with xg form the first day the lunch it and before that i was working with cyberoam
also i have experience with cisco and fortigate product but i relay got confused form how to handle with the New NAT method and how they created
for example i upgrade form v17.5 to 18 so i found the linked NAT rule but when i try to create new rule i can not use the old nat one and i have to create it again ??? why i can not use the linked one
i know that you try to be more similar to the other vendor in the market
Hi,
migrated my v17.5 XG to V18 EAp. Initially the NAT rules look good until you try to use them.
1/. too much unused screen sopace
2/. each NAT rule has a number of IDs from what I can see
3/. the NAT rules bear no relationship to the firewall rules
4/. the migration tool could have at the very minimum used the firewall rules name in the identity as it stands there is no meaningful way of identifying which NAT rule applies yo which firewall rule (yes, there is a number but can you remember what each firewall rule does?).
5/. there does not appear to be a way to swap between firewall rule and NAT rule pages, so you will need two monitors and two firewall sessions open to create firewall rules and manage the firewall.
The above is a from my quick exploration after initial installation.
Ian
XGS118 - v21.5 EAP
XG115 converted to software licence v21.0.1 MR-1
If a post solves your question please use the 'Verify Answer' button.
Hello rfcat_vk
1/. Ok for the screen space lost. But that may due to a programming package Sophos is using, like Infragistics on Windows platform. In such cases, layout are done via librairies, and the programing language just calls it. Sophos programing is somewhat locked. The alternative is to program windows manually. A heck of a job.
2/. to 5/. I really don't get it. Why on earth one want to have side by side NAT rules and Firewall rules. Sounds absolutely useless to me. NAT are not that much related to firewall rules. They are related to conditions and/or networking. For example, default NAT rule for all Firewall on this planet is "all hidden behind the firewall". Or call it "Masked behind the firewall". Since most small business now are granted a unique firewall IP address, chances are that "a little more complicated NAT" will be:
1- default NAT: all hidden behind firewall. Why would you link that one ??? It simply applies to all firewall rules by default.
2- conditional NAT: External HTTPS NATed to a specific internal WEB or MAIL server IP. Obviously, you could also do a linked NAT here. But it is gonna be one of the very, very few you will have to implement.
And it is not gonna be more complicated than that for a lot of users.
Besides the non-intuitive screen layout, what's the fuzz about v18 NAT implementation ?
So. We need a better layout, AND templates (WEB Servers, EXCHANGE servers, et.c.) We also need an automatic NAT rule generator like all other firewall products on the planet.
But I also wish no one touches to the welcome flexibility we just gained !!!
My 2 cents ...
Paul Jr
Sophos should invest some partners during the design phase as changing things in the design phase can require very small effort. Car houses use prototypes before starting to manifacturing cars.
As I said, I am open to partecipate (with some notices of course) when they are thinking of re-designing something new. They did not invest Parterns that I know here on community. No one is happy with the new NAT and the wizard removal.
I like the concept of decoupling NAT and Firewall as UTM9 but not Linked NAT. Wizard is very very helpful and falls into "Security made simple".
Anyway, I already expressed my idea and the test I performed is clear. If someone from Sophos would like to contact me, feel free to do it. I am always available.
Regards
Yeap. Those who have 300 firewalls rules and more, will find themself with 300 rules NAT after upgrade, and 290 of those 300 NAT rules will be exactly the same as the logical default MASK / Hidden all rule. So they will have to create / edit a default NAT rule, and then delete manually 290 NAT rules.
I can hardly find something more unproductive.
That's a job for a script I can only tell.
Paul Jr
N.B. Oups. I forgot. Multiply this by two if you have IPv6 as well. A job for a munk.
The question is why has some much resources been wasted (my opinion) on bringing XG upto parity with opposition devices for a dying requirement eg IPv6 does not need NAT, when the resources would have been better employed bring XG v18 IPv6 upto UTM parity at the very minimum. You still cannot use country blocking in IPv6 firewall rules. You still need seperate firewall rules for IP4 and IPv6.
Ian
XGS118 - v21.5 EAP
XG115 converted to software licence v21.0.1 MR-1
If a post solves your question please use the 'Verify Answer' button.
Big_Buck said:Besides the non-intuitive screen layout, what's the fuzz about v18 NAT implementation ?
Since the beginning, for whatever reason you want to come up with, XG could not do SNAT.
For example, XG has its own DNS server. Lets say I don't want users bypassing my DNS server on XG and using something like 8.8.8.8. You should easily be able to setup a snat rule to direct all DNS traffic to XG no matter what the client is asking. This is possible with EVERY LINUX DISTRO including my 5yr old asus router yet was surprisingly missing in XG. Now finally in v18 you have that ability.
When the gui redesign was being decided, someone looked at other players in the segment and tried to add the additional flexibility of multiple NAT rules without easily integrating it into existing implementation in XG. So now you have 100 or 1000 NAT rules where you only need ONE when you are simply NATTING internal to external when updating from older versions.
Regards
Bill
I have been experimenting and found that anyone with more than 1 network that they wish to interconnect will need to use linked NAT for each firewall rule going external otherwise you end up NAT'ing your local connections if you use the generic (MASQ) NAT at the top of the NAT list.
Ian
XGS118 - v21.5 EAP
XG115 converted to software licence v21.0.1 MR-1
If a post solves your question please use the 'Verify Answer' button.
Why do you say so ? Simple internal to external NAT is a rule Sophos calls "Mask", or default NAT rule. Other player will say "Default Hide Behind". But in all cases, is such conditions, provided your ISP have given you a single IP address (i.e. a single WAN IP address) you really do not need more than a single NAT rule. Why 100 ???
I think this confusion arise from Sophos NAT migration policy. They reply it was to make sure nothing was left behind, but I do not buy it. Sorry. They did not need to create on NAT rule per firewall policy, and they did not need to have all of those NAT rule be linked. If sources, conditions and destination are the same, what's the fuze to create a single rule ??? It is only confusing everyone.
Paul Jr
In addition to the long list,
to add a new item, I do not like the drop-down menu as implemented for translated as the it is not user-friendly. A possigle implementation of NAT rule could be like this:
Simple and easy to understand. Maybe to adjust the titlle but the main idea I have is this. What do you think?
Thanks
The decoupled NAT - the biggest mistake since version 15 :-(
Imagine just apx. 100 rules with small customer - first you will need to open
XG console twice with firewalls and NAT rules together … crazy…
Not simple anymore. PLEASE RECONSIDER!!!
Don’t do a separate tab for NAT!!!
On behalt awin IT, Sophos Platinum Partner
Jindrich Rosicka
awin IT
Sorry, but no, You will not have to do that. You will not have to have two pages side by side.
Nor that you have to do it on any other firewall like CheckPoint for example.
For hundreds of firewall rules, you will have most probably only 1 to 5 NAT rules.
NAT is far more "set it and forget it" than a firewall rule would ever be.
Decoupling NAT is on the contrary one of the best things Sophos have done .
Paul Jr
XG18 EAP2 5 NAT have customers in small or simple environments (also true), but for example ->currently in one production environment:
127 firewall rules
37 NAT rules -> !not linked!
Try to match them :-(
Decoupling NAT is not new in Sophos. It is the same as was in UTM9 (SNAT without automatic fw rule + manually create fw rule), so we have long bad experience with it.
Decoupling NAT is possible if you will see DIRECTLY IN FW RULE THE NAT RESULT!
Jindrich Rosicka
awin IT
Ok.
One have an Exchange server. One NAT rule.
One WEB server. One NAT rule.
One Terminal Server. One NAT rule.
Two or three subnets. One Hide-Behind-the Firewall Mask rule.
That covers 90% of businesses.
Do you NAT that much internally or externally ? Why ?
Some examples please.
Paul Jr
More likely to consider the new Interface (Zone) Matching Criteria. You can match NAT Rules quite easily without having to match anything.
SNAT (MASQ). One Rule - Done.
Inbound NAT - One Rule - Done.
One Server has a specific SNAT (Full NAT) need? One Rule over your Default Nat - Done.
__________________________________________________________________________________________________________________
I was critical of this change and how it was presented in the UI at first. I know the presentation is going to be fixed and will make sense once it is. The training actually does a good job of explaining this (after I watched it and read the supplement; the video alone doesn't do enough in my opinion).
We have been in the Astaro/UTM/XG ecosystem for a long time now and I forgot how everyone else does this. Once I took a step back and looked at this through the lens of the other firewall vendors, it makes total sense. Some of those other vendors have a fair amount of default NAT rules as well. They didn't have the conundrum like Sophos has with trying to migrate the rules from an old system to this new style. I can appreciate the stance Sophos has taken to be cautious and just do a one for one when upgrading.
In the end, this is by far the best change they are implementing, in my opinion.
We have published how-to video guide exclusive for NAT enhancements in v18. This covers SNAT, DNAT and PAT with deployment examples; explains migration from v17.x, caveats, additional details and troubleshooting guidance.
Here is the how-to video guide link: NAT Configurations in XG firewall v18
Sincerely,
Your Sophos XG Firewall Product Team
So my first experience upgrading from 17 to 18, ughh... horrible, supposed to work flawlessly with no impact. I upgraded and now my internet connection does NOT work at all, traffic doesn't seem to get from the LAN to WAN interface as before in 17, for no apparent reason. So I even tried creating an any/any accept firewall rule, and global NAT rule and still nothing.
Something is horrendously broken in the upgrade process fr me, and unfortunately I can't sit with downtime all week long trying to troubleshoot it.
Thanks,
Dan.Creed@thcreeds.net
How many rules and networks do you have in there ?
For my curiosity ...
Paul Jr
Just and internal and WAN interface... this is a small install in my home. Maybe 6 rules.
I have upgraded four firewalls as of now without a glitch. Except for the fact that a wireless device backup will not be uploadable on a non wireless device.
Paul Jr
Hi,
if you upgraded to the latest version v18 MR-1, I suggest you roll back to v17 there appears to be a bug in v18 MR-1 which is causing traffic to be blocked.
Ian
XGS118 - v21.5 EAP
XG115 converted to software licence v21.0.1 MR-1
If a post solves your question please use the 'Verify Answer' button.
Hi Dan,
Thanks for your feedback.
I will send you PM for more details purpose.