Migration tool not assigning correct interface to name
Lancorp
Newbie ✭
2nd time using the Sonicwall Online Migration tool. Both times are migrating new clients that I have no hand in the original configuration. The first was an NSA --> NSA that went well. This time, it's an NSA 220 --> TZ 370.
Now, I know that the migration tool says not to migrate Gen 5 to Gen 7. But it doesn't say not to migrate Gen 5 to Gen 6 or Gen 6 to Gen 7 so I did a 2-step migration from NSA 220W to TZ400, then TZ400 to TZ 370. I mapped the ports correctly (only using X0 and X1).
After uploading the new settings to the TX370, no traffic was getting to the internet and the log showed that packets were being dropped because of error "policy not found for packet on Zones(LAN -> WAN).
Hmmm...
In looking around, I saw the Firewall policies were messed up. The policies from LAN->WAN showed LAN(X0) to WAN(X0). Wait? They can't both be X0! Why did the configuration assign X0 to the WAN? So I went through the couple of outgoing rules and change WAN(X0) to WAN(X1). Bingo! Internet works. Then, WAN -> LAN had same thing -- WAN(X0). Jeezus.
So two questions, why is this happening when I correctly mapped the ports during each stage of the migration?
And second, some rules have "WAN" and some have WAN(X0). What's the difference? We only have one WAN port. Can I change WAN(X0) to WAN?
Oh, one more thing -- the old NSA220W had WIFI and a zone WLAN. This TX370 does not have wireless but the WLAN Zone seems to have been migrated along with all the rules. Should I just leave it or delete it and all the policies/rules?
Answers
Anyone have some information on this?
@Lancorp
The only thing I can think of has to do with the options used to create the new file.
In Step 5, Export, there is the "Drop default access rules from source device" checkbox.
I have not found a reference to that field in any SonicWall documentation, and I do not know what it means, nor what the results are when checked.
For a test, you might want to try it to see if your output file comes out cleaner than what you have now.
@LARRY, thanks for the reply. I can try that but the rules that were messed up were not just default access rules (some were custom) so not sure that is solution.
Would you happen to be able to explain the difference between "WAN" and "WAN(X1)"? Why two names for the same thing?
@Lancorp - sorry, not a clue.
If you have some time to waste, you might as well get on a phone call with Support...
(As an aside, I just learned that the Feedback button on the right-hand side of the entry page doesn't work - just shows a blank pop-up window. It seems very little of the output from SonicWall is getting reviewed or checked these days.)
Ill try to answer your second question.
A "WAN" address object likely refers to ANY interface assigned to the WAN zone (as you can have multiple for failover, etc.).
A "WAN(X1)" address object refers to the specific interface (X1) that is in the WAN zone.
Issues like you are describing are why I never recommend using the migration tools (let alone for multiple version changes)...
Makes sense. I get it. My choices were to use the migration tool and get up and running in a couple hours, or spend days trying to reverse-engineer hundreds of someone else's rules and objects and them still probably have a broken system. Like I said in the beginning, this client is new and I'm inheriting this.
Over time, we can try to weed out old rules, etc., that aren't being used anymore.
Thanks, though, for your input.