Sending data to influxDB through specific interface/bind IP address

[elieyal]

Hi,
I haven't seen any option to bind an IP address for sending information out from Telegraf.
I would expect to find an option to do a bind-address when configuring the outputs.
please tell me if this is possible today or is this not a valid option today?

the use case is that I have a server with multiple interfaces and the management interface (with the default GW) is not connected to the Internet and will not allow connection to the influxdb servers.
In this case I need to make Telegraf know to send the traffic through a different interface.
is it possible?

[danielnelson]

I believe this should be handled by proper configuration of your routing table. For instance on my system:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.79.40.1      0.0.0.0         UG    6      0        0 bond0
10.79.40.0      0.0.0.0         255.255.255.0   U     6      0        0 bond0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0

Data to the 192.168.122/24 networks goes to virbr0 while everything else goes out to bond0.

[poodad]

I'd like to re-open this as an issue. I'm trying to run telegraf on an OPNSense firewall. The influx server is on the other side of an ipsec tunnel. Since OPNSense ipsec is policy based (no tunnel interface to route to), I can't use telegraf because it binds to OPNsense's public IP, not the LAN IP which is not in the ipsec policy interesting traffic.

[glinton]

If a plugin listens on a socket, it is generally configurable. Check the readme for the plugin you are using and open a new issue if you are unable to listen on your desired interface.

[danielnelson]

Since OPNSense ipsec is policy based (no tunnel interface to route to), I can't use telegraf because it binds to OPNsense's public IP, not the LAN IP which is not in the ipsec policy interesting traffic.

I've never used a tunnel like this myself, how do the policies work? There must be some way to control what goes into the tunnel, since hardly any programs allow you to select the interface.

[poodad]

You configure “interesting traffic” or in other words, what local addresses and remote address are to go across IPSec. I can’t put the opnsense public ip in the interesting traffic.

…

On Tue, Sep 3, 2019 at 7:40 PM Daniel Nelson ***@***.***> wrote: Since OPNSense ipsec is policy based (no tunnel interface to route to), I can't use telegraf because it binds to OPNsense's public IP, not the LAN IP which is not in the ipsec policy interesting traffic. I've never used a tunnel like this myself, how do the policies work? There must be some way to control what goes into the tunnel, since hardly any programs allow you to select the interface. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4287?email_source=notifications&email_token=AHT4QGA6YXPVJHMUY7XPLYLQH3YYXA5CNFSM4FFADUH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5Z4MYQ#issuecomment-527681122>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHT4QGCN67JBY5BIJBMA4LTQH3YYXANCNFSM4FFADUHQ> .

[danielnelson]

Can't you just express something like: "all traffic with dest port 8086 is interesting"?

[poodad]

I've worked with Cisco ASAs, Sophos SG UTM, Sophos XG, and OPNSense ipsec VPNs, and they all only have the option to define source and destination subnets as the interesting traffic.

…

On Tue, Sep 3, 2019 at 9:27 PM Daniel Nelson ***@***.***> wrote: Can't you just express something like: "all traffic with dest port 8086 is interesting"? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4287?email_source=notifications&email_token=AHT4QGANXFU65JSBBHPHSODQH4FIPA5CNFSM4FFADUH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD52BJLY#issuecomment-527701167>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHT4QGCHOOPIDCNLKDK5TYLQH4FIPANCNFSM4FFADUHQ> .

[danielnelson]

That makes sense, similar in that respect to a routing table, but I'm still a bit confused on the network topology.

Let's say you have host "telegraf" talking to host "influxdb". Let's say that telegraf has a public address 93.184.216.34 and the LAN address 192.168.0.1. Both of these are on the same interface and the routing table just has one entry?

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    6      0        0 eth0
192.168.0.1     0.0.0.0         255.255.255.0   U     6      0        0 eth0

InfluxDB has the LAN address 192.168.0.2. So long as you list 192.168.0/24 as interesting traffic it seems like all should work. What am I missing?

[poodad]

As to the topology, using your examples, "telegraf" is a box running OPNSense (which is a fork of pfsense). It has a public IP of 1.1.1.1 and a LAN address of 192.168.1.1/24. It has an ipsec tunnel to "main" which is another OPNSense box with a public IP of 2.2.2.2 and a LAN address of 192.168.2.1/24. Host "influx" is a server at 192.168.2.100. On "telegraf" The ipsec tunnels are configured for interesting traffic of src:192.168.1.0/24 and dest: 192.168.2.0/24. "main" has interesting traffic defined as src: 192.168.2.0/24 dest: 192.168.1.0/24 Unfortunately, when telegraf starts, it binds to 1.1.1.1 instead of 192.168.1.1, so when it sends traffic to "influx", the packets have a destination IP of 192.168.2.100 and a source IP of 1.1.1.1. this means the packet doesn't match the ipsec interesting traffic rule, and gets punted of to the default gateway (the ISP in this case).

…

On Wed, Sep 4, 2019 at 8:04 PM Daniel Nelson ***@***.***> wrote: That makes sense, similar in that respect to a routing table, but I'm still a bit confused on the network topology. Let's say you have host "telegraf" talking to host "influxdb". Let's say that telegraf has a public address 93.184.216.34 and the LAN address 192.168.0.1. Both of these are on the same interface and the routing table just has one entry? Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 0.0.0.0 UG 6 0 0 eth0 192.168.0.1 0.0.0.0 255.255.255.0 U 6 0 0 eth0 InfluxDB has the LAN address 192.168.0.2. So long as you list 192.168.0/24 as interesting traffic it seems like all should work. What am I missing? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4287?email_source=notifications&email_token=AHT4QGEW6UFM4NUPML3AJJ3QIBEILA5CNFSM4FFADUH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD55MLRA#issuecomment-528139716>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHT4QGCHZQEVANLWBJ4D4VTQIBEILANCNFSM4FFADUHQ> .

[danielnelson]

What does the routing table look like?

With 192.168.2.1 -> 192.168.2.100, you may need to add a route like:

ip route add 192.168.2.0/24 dev eth0 src 191.168.2.1

What does this say?

ip route get 192.168.2.100

[topranks]

We need to source our traffic from a loopback IP.

There are many and varied kinds of systems out there. It is extremely common for all kinds of services to allow for a "bind" option to determine which IP they attach to when starting.

InfluxDB has just such an option. It wouldd be great if this were possible with telegraf too.

[iceman91176]

+1 - also have the need for binding it to a loopback-ip