Why does the latest GravityZone appliance send bootp/dhcp broadcasts?
The following is from a freshly installed GravityZone virtual appliance from the ova from their website. It is sending BOOTP/DHCP requests for some reason. I cannot install iftop because of their proprietary repository.
I have not entered the trial license key yet, because I have to set up a new email address because I already used my current work email for a trial of the cloud version.
gravityzone / # tcpdump -n -i eth0 port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:25:49.588169 IP ###.###.23.4.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:50:56:8e:3f:60, length 244
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel
gravityzone / # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:8e:3f:60 brd ff:ff:ff:ff:ff:ff
inet ###.###.23.4/24 brd 10.164.23.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe8e:3f60/64 scope link
valid_lft forever preferred_lft forever
gravityzone / # cat /etc/network/interfaces
auto lo
iface lo inet loopback
# The loopback network interface
# The primary network interface
source /etc/network/interfaces.d/*
auto eth0
iface eth0 inet static
address ###.###.23.4
netmask 255.255.255.0
gateway ###.###.23.1
dns-nameservers ###.###.###.229 ###.###.###.240
gravityzone / #
gravityzone / # cat /etc/network/interfaces.d/*
cat: '/etc/network/interfaces.d/*': No such file or directory
Best Answer
-
I've found the source to be the Azure Linux VM Agent, which is apparently installed by default in the appliance, instead of checking to see if it is actually on Azure first. I performed the following:
apt remove walinuxagent
and my server is no longer sending out DHCP/BOOTP requests.
So this fixes my problem, but the final solution needs to be for Bitdefender to fix their virtual appliance so this doesn't get installed by default for anyone not using Azure.
0
Answers
-
Hello.
Since you need help with business product, @Andrei_S Enterprise (who provides support for business products) could take a look here and help you with the issue.
Also, you can always contact the Bitdefender business support:
Regards.1 -
Thank you @Gjoksi , I look forward to any input @Andrei_S Enterprise might be able to provide.
I hoped that a quick Google search would result in an article or post about it, since it is a base freshly installed appliance. I'm trying to get it working cleanly so we can obtain a trial license to determine if Bitdefender is going to be our antivirus/host-based protection product. I have 70% of our IT team on board so far, but we have not purchased yet, so I do not yet have business support available.
0 -
Also please note that I already checked the firewall port requirements, and there is no reference to UDP 67/68 in there.
0 -
Hello @DerpGonk ,
I have seen this situation on Ubuntu environment when the static IP was not correctly configured. This is not triggered by the GravityZone, it is at the OS level.
Can you please ensure that you have set the correct static IP by following this procedure:
Kind Regards,
2 -
Yes, sir, that is what I used to configure it.
Per "You must specify the IP address, network mask, gateway address and DNS server addresses." if you look back at my original post again, you will see at the end of it that I copied and pasted the content from /etc/network/interfaces, which was populated by the "Configure Network Settings" function from the console. It includes all of that information.
I have tried rebuilding it to see if maybe I made a mistake the first time, but the problem persists.
0
