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

Changing NICs on Virtual UTM (ESXi 5.5)

Hi All,

I am hoping someone can help me as I have run into the issue of the dreaded e1000 NIC issue 'Adapter Reset'.

Backgroud:

It seems that Sophos  have known about issue this for some years, it is in the KIL - https://community.sophos.com/kb/en-us/124067 (just search for e1000), but the guidance they provide still states that the use of the e1000 is best for speeds below 1Gb, see: https://community.sophos.com/kb/en-us/119230

Rant over ...

Well I have hit this exact error on a customers Virtual UTM, I am now looking for help.

The Virtual Host I can only get (very) limited access to via an administrator, I can tell him what I want and he will action this (if he can).

in a a week or so I will ask them to change the NICs from e1000 to VMXNet3 cards, I have heard the following;

1. That this action will change the NIC order, rendering the UTM Dead in the water - is this true?

2. This NIC order can be corrected by editing the "/etc/udev/rules.d/70-persistent-net.rules" (but have also heard this sometimes doesn't work)

I would like some guidance on "2" as my system does not have this file. I have also read other articles about what is required but need clarification.

How reliable is this?



This thread was automatically locked due to age.
Parents
  • Hi Argo,

    What result do you get now with the following?

    cat /etc/udev/rules.d/70-persistent-net.rules

    I have only a couple clients that use VMs and I told them to use VMXNET3 from the start. I don't think you will find a post here that recommends e1000.  I hope someone updates KB article 119230.

    UPDATE 2019-05-20: 119230 was corrected on 23 April 2019.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply
  • Hi Argo,

    What result do you get now with the following?

    cat /etc/udev/rules.d/70-persistent-net.rules

    I have only a couple clients that use VMs and I told them to use VMXNET3 from the start. I don't think you will find a post here that recommends e1000.  I hope someone updates KB article 119230.

    UPDATE 2019-05-20: 119230 was corrected on 23 April 2019.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Children
  • Bob,

    I'm running utm under esxi 6.5.  I have that file (70-persist...) now.  It references a single nic, the one I have in passthrough which is used for WAN.  The other 4 vnics are not there.

    @OP, I believe I posted here some time ago about how to change nic order.  It involved editing the pci address of the device in esxi for that vm.  I remember posting the details somewhere.

    I can't remember if a lower or higher number change its value to lower/higher ethx.

    First 3 network adapters are vnics mapped to real nics.  Nextcloud_port is a virtual nic/switch, exists only in esxi realm.  Hopefully this helps.

  • Hi BAlfson,

    nothing, looks like this is not there

    how do put this file together?

    I have tried to compel them to update the KB, I did not consult the KIL (didn't know about it) and thus I am in this position now.

    EDIT - they updated the KB at last

    thanks BAlfson

    XG & UTM Architect (Systems: XG v18 & UTM 9.7 - Virtual, HW & SW)
    Curious enough to take it apart, skilled enough to put it back together, Clever enough to hide the extra parts when I'm Done!

  • Thanks Jay Jay,

    as I said in my op, i have very little access to the ESXi host and only through the providers, who could do this but probably won't (not the greatest ISP in the world).

    All I can ask for is to change the NICs from e1000 to VMXNet3 and keep the MAC addresses in place beyond this would require a miracle or act of god.

    Although when chatting to them they did say it wouldn't affect the UTM if they changed the NICs.

     

    thanks for responding

    XG & UTM Architect (Systems: XG v18 & UTM 9.7 - Virtual, HW & SW)
    Curious enough to take it apart, skilled enough to put it back together, Clever enough to hide the extra parts when I'm Done!

  • I don't believe them.  When I was using a virtual (vsphere) UTM, changing the NIC wreaked havoc.  I found it easiest to save the config, reinstall SG, then restore the config.

  • Hi dswartz,

    thanks for the info (I did think this was not possible)

    I am using the SMTP proxy and was wondering how to restore this will the current quarantine?

    is there any way to accomplish this?

    looking for any help with this, the rest of the logs are not necessary.

    XG & UTM Architect (Systems: XG v18 & UTM 9.7 - Virtual, HW & SW)
    Curious enough to take it apart, skilled enough to put it back together, Clever enough to hide the extra parts when I'm Done!

  • AFAIK, the quarantine is not in the backup file.  You could try saving it somewhere, then drag it back to the restored UTM?

  • Hi BAlfson & dswartz,

    I completed the change yesterday, and this is how I completed the change.

    1. Configured the 2 x UTMs as HA (Active-Passive), this way I could sync all the data.

    2. get the Virtual DC to change NICs from e1000 to VMXNet3 on backup UTM.

    3. Rebooted Backup UTM.

    - the UTM was effectively dead in the water.

    - I ran "ifconfig" and found that the interfaces were there but only one was displaying one of the MAC addresses (this was not in the correct position)

    - i ran "lspci" to check that the VMXNet3 interfaces had been recognized (they had been recognized).

    4. Used CLI console to change "71-virtual-mac-net.rules" in the /etc/udev/rules.d/ folder. (see below)

     

    5. rebooted UTM - All worked

    -------------------------------------

    here is the 71-virtual-mac-net.rules file

    # Ignore HA virtual MAC addresses, so network interface names are not renamed in 70-persistent-net.rules
    # This should not happen, but there are some buggy network cards out there, e.g. Realtek
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:1a:8c:f0:*", ATTR{type}=="1", KERNEL=="eth*", NAME="eth%n"

    **below is what I added to get it to work correctly.

    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="02:00:7f:**:**:05", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="02:00:41:**:**:05", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="02:00:61:**:**:04", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="1e:00:d8:**:**:d3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="02:00:0b:**:**:04", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"

    -------------------------------------

     

    thanks for all your help with this Bob & dswartz.

    XG & UTM Architect (Systems: XG v18 & UTM 9.7 - Virtual, HW & SW)
    Curious enough to take it apart, skilled enough to put it back together, Clever enough to hide the extra parts when I'm Done!