OPNsense Forum
Archive => 20.7 Legacy Series => Topic started by: Gcon on September 15, 2020, 04:29:50 pm
-
OPNsense is super horrible when it comes to changing interface types! SIMPLY. HORRIBLE.
I have a lab setup where I am using VMware Paravirtualsed Ethernet v3 NICS (vmxnet3) and then I found out that tagged Ethernet frames weren't working in the lab environment (GNS3 VM on ESXi 6.7) so changed to Paravirtualised Network I/O (virtio-net-pci) NICs and then rebooted. FYI the VMware NICs are vmx* in OPNsense and Virtio NICs are vtnet* in OPNsense .... and the vtnet* type did work with tagged frames but here's the thing...
Upon reboot, instead of OPNsense going "err.. all your old NICs are gone.... help me match up the previous NICs to new ones", it just says "yeah screw you buddy and your previous config that you worked so hard at and for so long - it's all gone now!! HA HA HAAAAAAA!!!!"
OPNsense devs - this is terrible. You need a cleaner separation of logical interface to physical interface mappings. Then if/when the physicals change, you prompt for this and do an **assisted remap**, and then the customer can get up and running again with **NO LOSS OF CONFIGURATION**. You don't just blow their config away!!!!!grrrrrr >:(
And no the "prevent inteface removal" doesn't help. That just stores the old interface data (with old interface types ... but does only a partial job at that) - it doesn't help with remapping to new interfaces / interface types. I don't know if you guys do much testing in virtualised environments but if you do - you can't really be pushing the boundaries of what you can do in them. Otherwise you'd have sorted this out well before now.
pfSense actually can and does do interface remappings. i.e. it handles this sanely. Here's a tip.... when you fork software... you are supposed to *improve* it.
Why does this matter? It matters because I have a full lab environment modelling two firewalls, three routers and three internet connections plus LAN switches and hosts. I have firewalls on pfSense right now and I could take the production configs with minimal massaging, and easily adapt them to the lab setup with minimal fuss. I want to be able to rebuild the pfSense lab firewalls with OPNsense as a Proof Of Concept (P.O.C.) with full production-ready pre-built configs and test everything. The idea is to work up the OPNsense configs in the lab until they are production-ready, and then rip the configs off the lab and take them into production. But with OPNsense being completely unable to handle interface type changes - I can't for the life of me see how this is going to work! I'll probably mean I will abandon any attempts to go to OPNsense - which means no support contract money for them. This stupidity has most likely cost them a customer.
Now you can fire back with all the ad hominems that you like but I couldn't care less. If there are massive problems with software I'll point it out - every single time. Constructive criticism is helpful - you should appreciate that I've taken the time to test the software, find the issue, compare and contrast to competitors (e.g. pfSense), and effectively communicate the issue to you and offer suggestions on how to fix it.
But yeah - it stinks.
-
Just set "Prevent interface removal" in the respective interface settings. Any polite forum search would tell you.
Respectfully,
Franco
-
Wow, maybe you should adjust the dosing of your rage stabilizer? Just saying...
-
@Gcon
and if without hysterics?
what did you do and when did you lose the configuration?
i don't have esxi at hand so i quick test it on hyper-v (switch intrefaces type from hn to de):
set "Prevent interface removal" on LAN and WAN (hn0, hn1 interfaces), power off vm, delete nic-s (hn0,hn1), add another nic-s (de0, de1). boot opnsense, go to 1)Assign Interfaces, assign new de0\de1 to LAN\WAN, reboot and continued working with old config.
so?
-
Constructive criticism is helpful
Indeed! ;)
-
Just set "Prevent interface removal" in the respective interface settings. Any polite forum search would tell you.
franco.
(1) You assumed I posted without first searching (incorrect), and
(2) You replied with a suggestion I explicity mentioned as not working. ::) I know this is the Internet where people rarely read beyond the headline but still...
@Gcon
and if without hysterics?
what did you do and when did you lose the configuration?
i don't have esxi at hand so i quick test it on hyper-v (switch intrefaces type from hn to de):
set "Prevent interface removal" on LAN and WAN (hn0, hn1 interfaces), power off vm, delete nic-s (hn0,hn1), add another nic-s (de0, de1). boot opnsense, go to 1)Assign Interfaces, assign new de0\de1 to LAN\WAN, reboot and continued working with old config.
so?
Fright - thanks for replying with your experience that wasn't trolling, and showed you actually read what I wrote - I do appreciate that.
I'm glad it works for you but when I switch between vmx and vtnet interfaces and reassign the "WAN" interface, it always gets reset and loses its IP address....and yes "Prevent interface removal" is always set. The static IPv4 I put in gets blown away and goes back to DHCP/DHCP6. I went several times from vmx1 to vtnet1 and back again. Each time with a "save" and "apply" and even a reboot to make sure the IP stuck, it was impossible to remap between interfaces and not lose the IP address info.
So there is definitely some sort of bug with remapping the WAN interface to different NICs - at least in the environment I have setup (not hyper-V).
**The good news is that other interfaces can be remapped successfully.** (both major interfaces and subinterfaces / VLAN-tagged interfaces). So why did I think this wouldn't work for any interface / subinterface? Well there are several reasons:
1) I tried the "WAN" first and it was no good. If it failed for that, then what hope did the other interfaces have? Very little I thought.
2) After the reboot, into the boot up with new interface types, I am greeted with something like this....
========================
*** <HOSTNAME REMOVED> OPNsense 20.7.2 (amd64/OpenSSL) ***
DATA (vtnet0) ->
TEST (vtnet3) ->
WAN1 (vtnet1) ->
TEST2 (vtnet0_vlan444) ->
<FINGERPRINT REMOVED>
<HOSTNAME REMOVED> (ttyu0)
========================
I originally had a couple more WAN interfaces and half a dozen tagged interfaces - lots of config actually - but you get the idea - none of the interface IPv4 addresses show.
3) Upon building VLANs you get shown this scary warning:
"WARNING: all existing VLANs will be cleared if you proceed!"
...which gives the user the impression that you HAVE TO START FROM SCRATCH! (sorry was that too hysterical?) A proper warning would also add "NOTE: This excludes VLANs explicitly set to 'Prevent Interface removal' .... but that is assumed knowledge, but it shouldn't have to be.
So I was there basically thinking this, "OK I tried to remap the WAN - but that's lost! Damn! Now all the interfaces are sitting there laughing at me at the console with no IP addresses, and to rub salt into the wound... it's saying even if I attempt to rebuilt my VLAN tagged interfaces - it's going to blow everything away... if it hasn't already!". GRRRR!! x 1000.
But what actually happens is that only the WAN gets lost, (and it only seems to be the WAN IP addressing... thankfully the NAT and filter rules are still there). OK I will offer some insightful sugggestions in the next post which can help this project improve....
-
franco.
(1) You assumed I posted without first searching (incorrect), and
(2) You replied with a suggestion I explicity mentioned as not working. ::) I know this is the Internet where people rarely read beyond the headline but still...
We can't solve your host shuffling interfaces in the guest. If you just want to be here to complain I'll spend my time helping others instead of reading rants. Even if you are not happy with that at least one other person can be.
Please respect my decision as much as I respect yours to barf all over this forum.
Cheers,
Franco
-
We can't solve your host shuffling interfaces in the guest.
Well for some reason, OPNsense doesn't like it when shuffling between a couple of interface types on the WAN. It blows away the IP address. No idea why. Maybe that kind of bug report feedback is helpful to you? If you're rather ignore it - that's up to you. It's likely you have more pressing bugs to sort out with this product.
If you just want to be here to complain I'll spend my time helping others instead of reading rants. Even if you are not happy with that at least one other person can be.
Please respect my decision as much as I respect yours to barf all over this forum.
You can do what you like. But do you think it is a good idea, as a OPNsense representative (?!) to belittle your users on public forums, and refer to their feedback and day-long efforts of testing and feeback to make the product better for the good of all, as "barf". Seriously?! This is unbelievable stuff.
Anyways you probably (again for the second time) didn't read what I actually wrote. At the bottom of my last post I said I would offer suggestions for fixing this pain point and improve the product.
While you were busy thinking of ways to slander me, I was writing constructive feeback ("barf" in your own words). Since I had already written this "barf", then here's a hot serve. You probably won't read it, but hopefully a mature OPNsense developer will.
====
My suggestions to improve this product for the pain points I've raised are as follows:
1. Obviously fix the WAN interface remapping (re-Assignment) bug. I can assist by providing details of my environment [edit: probably not now I've been disrespected]
2. Fix the display output! Plainly put - it's severely lacking. For example it says this after I reboot into the new interface types (all previous interfaces changed to new types - from vtnet to vmx in this example):
DATA (vtnet0) ->
TEST (vtnet3) ->
WAN1 (vtnet1) ->
TEST2 (vtnet0_vlan444) ->
When it should be something like:
DATA (vtnet0 - missing) -> 192.168.27.1/24
TEST (vtnet3 - missing) -> 10.10.10.1/24
WAN1 (vtnet1 - missing) -> 5.5.5.5/30
TEST2 (vtnet0_vlan444 - missing) -> 20.20.20.1/24
NOTE: Interfaces missing. Please shut down and correct hardware, or "Assign interfaces" (option 2.) for the interfaces listed as missing, in order to prevent the loss of their configuration data! This arose because these interfaces have "Prevent interface removal" set in the Interface configuration, and can no-longer be found by the system
Finally, when rebuilding VLAN interfaces (as one has to do on the new parent interface), for sure you can still have your scary warning (inherited from pfSense), of "WARNING: all existing VLANs will be cleared if you proceed!", but since that's not actually true, how about improve it to be actually factual? For example:
WARNING: All non-permanent VLANs (VLAN interfaces not protected by "Prevent interface removal") will be cleared if you proceed!" Any VLAN Interfaces with status of "missing" should be Assigned (option 2.) after building new VLANs, in order to prevent the loss of VLAN Iconfiguration data"
Much better!
=====
-
Can you post the /conf/config.xml parts before and after assignment and after reboot when everything is gone again? As this is a virtual system you should also have a look on the console while booting, maybe some interesting errors to see.
-
This thread is a train wreck. My favourite bits that inherently set the expected tone:
[...] SIMPLY. HORRIBLE.
[...] "yeah screw you buddy and your previous config that you worked so hard at and for so long - it's all gone now!! HA HA HAAAAAAA!!!!"
OPNsense devs - this is terrible. [...]
pfSense actually can and does do interface remappings. i.e. it handles this sanely. Here's a tip.... when you fork software... you are supposed to *improve* it.
[...]
Now you can fire back with all the ad hominems that you like but I couldn't care less. [...] Constructive criticism is helpful - you should appreciate that [...]
Thanks for all the constructive prose that seems rather pointless and petty by focusing on the one unique thing that annoys you the most. ;)
You can do what you like. But do you think it is a good idea, as a OPNsense representative (?!) to belittle your users on public forums, and refer to their feedback and day-long efforts of testing and feeback to make the product better for the good of all, as "barf". Seriously?! This is unbelievable stuff.
Let's just agree that:
OPNsense will work on writing better software.
You will work on your writing and people skills.
Any maybe some day that feature request of yours will be implemented and you will no longer run the risk of violating the forum rules. Everybody wins. <3
https://forum.opnsense.org/index.php?topic=3.0
Cheers,
Franco