Open dxdemetriou opened 2 years ago
im not sure if this might be a BUG?
where are you seeing the gateway ip?
if you go into the details tab of the device, you can see a list of all its ip addresses and gateways etc?
you can also go to the main my Devices
then select the List
icon on the right (second one in),
then click the cog thats underneath, and select Agent IP address, and you will then see the devices IP address that meshcentral sees it on (external ip is the device is remote or internal ip if the MC server is local)
Probably not a bug because I couldn't find something like "X-Forwarded-For" or "trustedProxy" in those cases. It happens when an agent has to go through a Default Gateway either because of a VLAN (in which the DG IP is shown) or because of a VPN (in which the VPN IP is shown).
The gateway IP is shown in "Last agent address" and in "Address" on MyDevices
In the details tab every ethernet and their details are shown correctly
The IP shown it depends where the computer is. When the computer is outside, if the user is not connected with VPN we have it's correct IP, and when it's connected with VPN we have the IP of our VPN. When the computer is inside it's the same as before with addition of the VLANs that every agent is shown with the DG IP.
In this case as there is an agent, probably it's possible to track the correct IP, that's why I opened it as a feature request
I think its a bug but I never reported it. I have my mesh central operating behind a router and i've changed to a different port (just port forwarding my non standard port to 443 inside my network). In my device list, all of the computers (both in my lan and remote locations) list the local gateway IP for the server as the device IP. If I go into the Interfaces, the last agent address at the top shows the mesh server gateway ip, but scrolling down to the various interfaces do show the correct IP address.
It's the same behavior as with skip2fa option in config. I have MeshCentral in DMZ in which there is no access from dmz to internal network.
From computer in untagged (VLAN0) the agent IP is correct and I can skip 2fa.
From computer on a VLAN# The agent's IP is the gateway's IP and I cannot skip 2fa.
From computer either inside or outside, if it's connected with VPN the agent's IP is the VPN's IP and cannot skip 2fs.
From outside computers which is not connected with VPN everything is ok.
Another not directly connected but similar, it's the scanning for AMT computers (with every required port allowed, also tested internally), the hostnames of the computers are shown only in untagged VLAN0, but in any VLAN only IPs are shown (other nbtscan tools can resolve the correct hostnames on VLANs). In the opposite, If I use the setup command directly on computers they are connected to MeshCentral but every computer on a VLAN has the gateway's IP
In the "settings" section of the config.json, add this line:
"TrustedProxy": "1.2.3.4",
Replace "1.2.3.4" with the internal IP address of your gateway. This is the IP address you see everywhere that your agents seem to be coming from. If you have multiple trusted gateways, you can do this:
"TrustedProxy": ["1.1.1.1", "2.2.2.2", "3.3.3.3"],
When a request comes to MeshCentral with a X-Forward-For
header, the header is only considered when it's coming from a trusted proxy.
Let me know if this helps.
I tried it already, and now with the latest version, it's not working. I have included default gateways of both sides and the firewall in the TrustedProxy.
$ traceroute [IP] traceroute to [IP] ([IP]), 30 hops max, 60 byte packets 1 gateway (10.XX.XX.3) 0.407 ms 0.361 ms 0.344 ms 2 wpad (192.XX.XX.2) 0.670 ms 0.634 ms 0.657 ms 3 [IP] ([IP]) 13.523 ms !X 13.522 ms !X 13.495 ms !X
Ok. Go in "My Server" / "Trace" tab and enable "Web Server HTTP headers" like this:
Then, when a request comes in, you should see a new entry and click on it to see all HTTP headers for that request:
The headers are in JSON format, but you can use a JSON lint tool to make it look better. Check if you see the "X-Forward-For" header and if the right IP address for that request is in the header.
In my case here, I don't have that header... but you should have it. If it's there and the request is from a trusted IP address and it still does not work, there is certainly a problem. Post me anything you can that would allow me to replicate the problem.
It shows the gateway's or VPN's IP
..CERTIFICATE-----","x-forwarded-for":"[IP]","x-forwarded-host":"[MeshCentral_IP]","x-forwarded-server":"[MeshCentral_IP]","upgrade":"WebSocket","connection":..
I tried a lot of times on different webapps to find how to get the real IP from devices behind of our VPN and Default Gateways but I couldn't find any info of how the x-forwarded-for can be handled in these cases. Configuring apache/nginx on VPN didn't worked as it's only for VPN's website. About the default gateway I couldn't find anything yet.
So, [IP] is the gateway IP address? If so, obviously MeshCentral is not receiving the correct IP address from the reverse proxy and this is not a MeshCentral issue. As long as the source IP is a trusted proxy and the "x-forward-for" is correct, MeshCentral should take the "x-forward-for" as the source IP address of the incoming connection. I am not sure I can debug this beyond this, but let me know if any MeshCentral changes need to be made.
If it's impossible to be determined by the server itself, then it could be awesome if it could be determined by the agent's information
Two possible changes I'm suggesting are:
-If the "Last agent address" is the same with any "Gateway" then take the "IP" from "Networking":
-If the "Last agent address" is the same with any of the "trustedProxy" IPs:
Those combinations could also solve the showing of the same Gateway's IP to every VLAN's computer when on "AMT - Setup" the "meshcmd amtconfig --url .." command is used by clients
Well, the problem is that the local network IP address is not always the same as the external IP address used by the agent. Often agents are behind NAT and so, you really want to have the last external IP address used by the agent. This is useful for IP address location tracking.
There is also a security issue here, you don't want someone sending you a fake external IP address as a X-Forward-For header.
The best is just to set your trustedproxy to your reverse proxy internal IP address and have MeshCentral use the X-Forward-For header to get the right IP address.
Sure, I didn't mean to be used for giving access, just for tracking purposes, and a possible way to be used those information by an administrator if it's more complicated otherwise. It could be helpful to have an extra column on "My Devices" showing the active ethernet.
For the X-Forward-For header, I'm trying to troubleshooting yet. I don't know yet if it's possible or some configuration is needed on the switches for using the correct IP between VLANs. The same with OpenVPN server that I don't know yet if it's possible. Probably somebody more experienced needed for those cases.
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] `I have to go to each client's "Details" tab for finding their IP address or their IPs addresses
Describe the solution you'd like A clear and concise description of what you want to happen. `If it's possible to show the IP address used when agent contacted the MeshCentral
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. `Or to show an array of every IP address (in case of multiple IP addresses on the machine)
Additional context Add any other context or screenshots about the feature request here. `It could be great if the filtering weren't only for Hostnames but for User and Address too