Nut Client Server error with ESXI
-
My conf :
NUT server installed on the Pfsense (Pfsense on a VM on an ESXI server)
NUT client installed on Ubuntu server (Ubuntu are also VM on the ESXI server)
VIB of NUT client installed on ESXINut seems to work on the Pfsense => I get all the data from my UPS (plugged on USB, with the USB dedicated to the Pfsense VM)
Nut client on Ubuntui seem's to works on the Ubuntu VM => I get all the data from my UPS plugged on the Pfsense.
The command "upsc UPS-Name@pfsense" worksBut I am not sure NUT on ESXI works...
The command "upsc UPS-Name@pfsense" does not work => timeoutOn the ESXI syslog when restarting NUT service I get :
upsmon[1609792]: Startup successful
upsmon[1609792]: Warning: running as one big root process by request (upsmon -p)
NUT: NUT client started
NUT: NUT client is runningthen
upsmon[1609792]: UPS [UPS-Name@pfsense]: connect failed: Connection failure: Connection timed out
upsmon[1609792]: Communications with UPS UPS-Name@pfsense lostThe ping pfsense works
Is there some port forwarding to do ?
Is it because the ESXI IP adress is on the managment LAN and not on the LAN with Pfsense and Ubuntu ?Thanks
-
@ewok2 NUT client requests from ESXi will originate from the IP Management Address of ESXi (Where you access the ESXi UI). So that needs to be reouted and allowed into the NUT server on your pfSense (on whatever interface packets from ESXi will arrive on)
-
Thanks for Help, but not sure to fully understand...
You mean I need to NAT from ESXI-IP:3493 to pfsense-IP:3493 ?
(with associate rules that allow) -
@ewok2 I can’t say, because I need to know your network setup details a lot better to give a clear answer. But if your ESXI servers IP adress is in the same IP subnet as the LAN interface on your pfSense, then no NAT or routing should be needed - just an allow rule from ESXi’s IP adress to pfSense LAN IP, port xxxx (NUT server port) on pfSense’s LAN interface.
-
Yes my ESXI IP is X.Y.Z.A and the pfsense adress is Y.Y.Z.B
But (i don't know if it isa problem) on ESXI I have 2 virtual LAN :
- one "Managment" for the managment with only the IP of ESXI
- one "Local" for all other VM (including pfsense)
=> All the IP are on the same subnet xith ony the last digit of the IP adress which change.
On Pfsense I have a rule in my "Local" Vlan that allow all trafic form all IP and port if in the Vlan
=> But it does not works from the ESXI
So I was wondering if the "Managment" VLAN "exist" from pfsense point of vue? or if PFSense consider VLAN only if host is in IP range X.Y.Z.0/24 ?
-
@ewok2 Two IP addresses can only talk together if:
1: They are ind the same IP Subnet and VLAN fx: 192.168.1.x/24
2: A router (default gateway) exists for both parties on each of their subnets (and normally VLAN), that can send the packets on to the destination host.In your case it sound like you ESXi’s management network and your Virtual machine network are actually on the same VLAN (This is also the default of a fresh installed ESXi).
But you have chosen to put your ESXi’s IP adress in one subnet, and your Virtual machines LAN interfaces in another subnet. So they cannot talk together - which is why it doesn’t work.
This is very bad network design - you should only have one IP subnet in one VLAN. So in your case you should consider:- Change your ESXi’s IP adress to be the same IP subnet as the Virtual machines - since they already share the same VLAN.
The alternative - with ESXi in its own management VLAN is too complicated to explain in text if you are not well versed in VLANs, IP subnets and routers.
-
Hello
Thanks for help
I check all subnet and confirm that both Local and MAnagment are in the same subnet.
Yes it not cleen ;-)
But trying to add a new IP in esxi => seem's not to work better...
Then returning to inital conf
And it works ???I should have relaunch a service that had update something...
So can't explain why exactly but it works.Thanks for help
-
@ewok2 said in Nut Client Server error with ESXI:
Is there some port forwarding to do ?
See post #2 in the NUT support thread for information on allowing network access.