Messages

I think I might have an alias issue with policy based routing. have you found a fix to this?

I took the plunge and upgraded from 26.1. The upgrade went fairly smoothly, but now my wireguard pia gateways aren't functioning at all. They show online and the gateway monitor has them online but they aren't actually routing any traffic. Anyone else run into this issue?

It's almost like the importer isn't recognizing the delimiting character and is attempting to parse the full line as the UUID

Yes, and the code (if I'm looking in the right place) looks at the header line and chooses the delimiter based on which appears first (comma or semicolon), which is why I asked.

I took your header line and the example line from your earlier post, and it imports fine for me ...

I picked just that line and the header as shown below and still get the same error. That's weird it worked for you.

@uuid;enabled;nonat;nosync;sequence;interface;ipprotocol;protocol;source_net;source_not;source_port;destination_net;destination_not;destination_port;target;target_port;staticnatport;log;categories;tag;tagged;description
;1;0;0;101;wan;inet;any;lan;0;;any;0;;;;0;0;;;;"LAN to WAN"

Edit

So realizing it was a parsing issue I went ahead and removed the spaces from my description thinking that might be throwing it off. After replacing all the spaces and qutation marks it successfully imported without issue. So to further troubleshoot I created a test rule in the new source nat with spaces and exported it. It exported and imported flawlessly with spaces. So there's something going on with the formatting for the export it seems.

Here's an example rule directly from the export tool from the migration assistant, which throws the same error.

;1;0;0;101;wan;inet;any;lan;0;;any;0;;;;0;0;;;;"LAN to WAN"

What does the first line (the header line) of the CSV file look like? The only way I can see the failure occurring is if the header line is comma separated but the actual data is semicolon-separated, but I can't imagine how that would happen....

Here's the header line.

@uuid;enabled;nonat;nosync;sequence;interface;ipprotocol;protocol;source_net;source_not;source_port;destination_net;destination_not;destination_port;target;target_port;staticnatport;log;categories;tag;tagged;description

It's semicolon. It's almost like the importer isn't recognizing the delimiting character and is attempting to parse the full line as the UUID instead of creating a new one since it isn't present.

Hi,

Is this only for the Outbound NAT?
What is with Destination NAT?

Thank you

Outbound is the old "legacy" style and is going to be changing to source / destination / one to one.

Where do you want to migrate the destination NAT rules to?

The only reason to migrate "Outbound NAT" to "SNAT" (aka "source NAT") was that this is the more common term. "Destination NAT" is already called correctly.

In the latests update the current NAT structure is changing based on the patch notes and eventually we'll have to migrate them like the old firewall rules. I'm attempting to use the migration to change from "legacy outbound NAT rules to the new Source NAT rules interface". But the original error is thrown when using the migration tool on all of my current NAT rules.

The UUID can be empty (otherwise it must be a properly formatted one):

https://github.com/opnsense/core/blob/20070de6fca7fc83605c856bd0b84753a86fa7c2/src/opnsense/mvc/app/models/OPNsense/Base/FieldTypes/ArrayField.php#L334-L348

I wonder if your CSV file somehow got corrupted with unprintable characters, or something. Did you do anything with the file other than let your browser save it during export, then open it for import? Try a different browser maybe?

Edit: ... actually, looking at your error message again, it looks like it's considering the whole line to be the UUID, so parsing the CSV seems to have failed somehow. I still wonder if something happened to corrupt the file...

Edit 2: Oooh, I have a theory - do any of your rules have a comma (,) or semicolon (;) in their description?

Here's an example rule directly from the export tool from the migration assistant, which throws the same error.

;1;0;0;101;wan;inet;any;lan;0;;any;0;;;;0;0;;;;"LAN to WAN"

No commas or semicolons in descriptions. It all looks correct to me, though.

I just upgraded to 26.1.11_5 and performed firewall rule migration without issues. I went ahead and started looking at the NAT migration. I'm using manual NAT outbound rule currently. I exported my rules without issue. When I attempt to import, though, I get validation failed for every rule with the following error.

@uuid;"Invalid UUID offered (;1;0;0;1;wan...

I added a single manual rule to see what it was expecting and upon export got

1bdd4169-e821-40ba-98b0-83fdc10c8378;1;0;0;100;lan...

So clearly the new NAT rules are expecting more than what the old ones are exporting with regard to UUID.

Is this a known error, or will it be fixed in an upcoming release? I'd prefer not to manually input all rules; I will if I have to, but if this is going to get fixed, I'll wait.

Thanks to the team for what you do.

Nobody?


Cheers,
Franco

Franco,

Sorry wasn't able to break the network again before calling it a night. People get upset during TV time. Anyways, I updated to _7, changed the alias back to URL vice Host, flushed the alias via diagnostics and it refreshed correctly pulling the information. I'll watch the logs on it and let you know if it doesn't hold.

Thanks for correcting the problem.

I had a similar issue. But also had an alias issue I fixed the alias issue and multi gateways with manual nat started working right away. This only impacted vlans using the broken aliases.

Fixing the alias issue corrected both problems. Hopefully this gets addressed.

Franco I applied the hot fix and rebooted and still have empty alias tables.

same problem

I think I found part of the problem. I had an alias with URLs in it that were failing to resolve because they didn't have https in front of them. This previously didn't cause an issue on older versions. But disalbing that alias allowed other aliases to populate. So there's an issue if an alias can't populate that it stops updating ones further down the list.

Example error message.

error fetching alias url us.archive.ubuntu.com (Invalid URL 'us.archive.ubuntu.com': No scheme supplied. Perhaps you meant https://us.archive.ubuntu.com?)

you're right, i resolved modifing the type from "url" to "Host/s" in the alias that in Content has "archive.ubuntu.com"

now the command /usr/local/opnsense/scripts/filter/update_tables.py --> {"status": "ok"}
aliases are populated now

I made that change as well and it also fixed the alias problem.

Franco I applied the hot fix and rebooted and still have empty alias tables.

same problem

I think I found part of the problem. I had an alias with URLs in it that were failing to resolve because they didn't have https in front of them. This previously didn't cause an issue on older versions. But disalbing that alias allowed other aliases to populate. So there's an issue if an alias can't populate that it stops updating ones further down the list.

Example error message.

error fetching alias url us.archive.ubuntu.com (Invalid URL 'us.archive.ubuntu.com': No scheme supplied. Perhaps you meant https://us.archive.ubuntu.com?)

Franco I applied the hot fix and rebooted and still have empty alias tables.

Gateways