RARE user and assistance email list

[Frédéric LOUI <>]

HI Gabriel,

Don’t over complexity things. In order to better breakdown your problem step 
by step.
 
You can deal with your problem without freeRtr first in order to better 
understand the network plumbing.

Replace all yours host by Debian/Ubuntu VM:

- interconnect them with your favorite Virtual machine bridge or point to 
point link
- Create Wireguard between them with ubuntu (you’ll find a lot of resource on 
the web)
- Enable Linux forwarding 
- Start with with Linux static routes

Check linux routing with: ip route show

Once you get your overlay up and running (underlay being basic linux 
interconnect) you can fire up your prometheus conrtainer with docker daemon

Try to establish the connectivity you’d like to achieve.
When you’ll solve this and understood how and why connectivity works you’d be 
able to figure out what you need when you’ll use freeRtr

This is actually not a freeRtr problem but mostly a very good  network 
routing exercise.

Good luck,
Frederic

> Le 31 août 2022 à 17:49, Gabriel Tetzner 
> <> a écrit :
> 
> Hi Frédéric,
> 
> Good,
> I'll try to do that, there was an advice from Csaba to install freeRouter 
> after I run the container and docker installation, I think it's fair to try 
> this configuration...
> I'll give you more details later, here in this thread.
> 
> Thank you,
> 
> Att: Gabriel Tetzner
> 
> Em qua., 31 de ago. de 2022 às 11:24, Frédéric LOUI 
> <> escreveu:
> Hi Gabriel,
> 
> I think that I almost start to figure out what you are trying to do … But 
> still don’t have a clear idea.
> Generally speaking forget now the underlay as you mention that your overlay 
> is working and that you are able to ping.
> 
> So now please draw a L3 diagram with your overlay only and indicate IP 
> accordingly on each segment.
> 
> Once you got your diagram, now think about how your prometheus server is 
> connected to freertr-rtr3 _AT_LAYER_3.
> I’m not sure if your prometheus container is running in host mode or is 
> NAT’ed behind docker0 but if you think network plumbing but you need to 
> figure out how the prometheus server is discussing with the outer world.
> 
> Next question you need to figure out is: how freertr-r3 is seeing this 
> docker bridge.
> 
> show ipv4 route <YOUR_OVERLAY_VRF>
> 
> Should give you the answer. If you don’t see docker network subnet, it 
> means that freertr-r3 does not know how to reach prometheus server
> 
> In order to simplify the problem I would use an external prometheus/grafana 
> server and make sure that the prometheus subnet is seen and  advertised in 
> your network.
> 
> Once it is working, just replicate the setup but with docker network 
> environment.
> 
> Your real problem here are not the Wireguard tunnels here. Your solution is 
> to figure out how to make freertr-r3 aware of docker subnet. 
> Once this subnet is « Injected » into the VRF you’d just have to advertise 
> it with any routing protocol of your choice.
> 
> Maybe you’ll have to use pcapInt and a combination of veth pair and 
> configure it into the hw config file
> 
> Sorry but again as it is unclear from my part this is just a guess ...
> 
> > Le 31 août 2022 à 15:46, Gabriel Tetzner 
> > <> a écrit :
> > 
> > Hi Frederic,
> > 
> > answering the first question, I want a tunnel wireguard from another 
> > network to reach the end of another tunnel wireguard from another 
> > network. 
> > 
> > A little crazy I know haha,
> > 
> > answering the question, with Csaba's help I chose a routing protocol and 
> > isolated the underlay and overlay with VRF, and I am using the EIGRP4 
> > protocol for routing, I wanted to know if this is a good protocol as 
> > well, some attempts gave error, but it worked in the end.
> > 
> > "What is the IP of the Debian machine ? Is it the machine running freeRtr 
> > ? A machine connected to freertr-r3 ?  " ->
> > 
> > So it would be the machine running freeRouter, this machine is in the 
> > cloud, however I have a prometheus server on it, and it is not the 
> > prometheus agent but the server running in docker on the machine with 
> > freeRouter:
> > 
> > https://prometheus.io/
> > 
> > <image.png>
> > 
> > This machine in the topology would be the freeRtr-r3, it is in aws and 
> > its IP configuration:
> > 
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65535 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: enX0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc 
> > fq_codel state UP group default qlen 1000
> >     link/ether 02:b1:02:dc:c6:18 brd ff:ff:ff:ff:ff:ff
> > 3: br-122d8c7c1e50: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
> > noqueue state UP group default 
> >     link/ether 02:42:61:21:c7:60 brd ff:ff:ff:ff:ff:ff
> >     inet 172.18.0.1/16 brd 172.18.255.255 scope global br-122d8c7c1e50
> >        valid_lft forever preferred_lft forever
> > 4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
> > state DOWN group default 
> >     link/ether 02:42:f3:e6:60:b3 brd ff:ff:ff:ff:ff:ff
> >     inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
> >        valid_lft forever preferred_lft forever
> > 10: tap20001: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel 
> > state UNKNOWN group default qlen 1000
> >     link/ether 00:00:4e:2c:4e:2b brd ff:ff:ff:ff:ff:ff
> >     inet 10.255.255.1/24 scope global tap20001
> >        valid_lft forever preferred_lft forever
> >     inet6 2001:db8:ffff:ffff:200:4eff:fe2c:4e2b/64 scope global dynamic 
> > mngtmpaddr 
> >        valid_lft 2419189sec preferred_lft 604789sec
> >     inet6 fe80::200:4eff:fe2c:4e2b/64 scope link 
> >        valid_lft forever preferred_lft forever
> > 23381: veth4b2630d@if23380: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 
> > qdisc noqueue master br-122d8c7c1e50 state UP group default 
> >     link/ether d2:6f:3c:b2:e3:63 brd ff:ff:ff:ff:ff:ff link-netnsid 0
> > 23383: vethdad3c9c@if23382: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 
> > qdisc noqueue master br-122d8c7c1e50 state UP group default 
> >     link/ether 5e:d6:da:31:4a:2f brd ff:ff:ff:ff:ff:ff link-netnsid 1
> > 
> > "In this topology consider that there is a prometheus server running on 
> > top of freeRtr-r3 debian and I need to talk to 10.0.0.3? »
> > Do you mean freertr server running Prometheus agent ?
> > 
> > Answer: As I mentioned in the text, the prometheus agent will only be on 
> > the other end (freeeRtr-r2), the prometheus server is running in a 
> > container on the debian machine freeRtr-3.
> > 
> > Now the big question arises for me:
> > 
> > I need the debian machine where freeRtr-3 is running, to reach the ip of 
> > the other end, in my view if freeRouter reaches through a tunnel 
> > wireguard and a routing protocol, the host machine (debian) of freeRtr 
> > should recognize it too.
> > 
> > Or the way I set it up is also wrong, but I think there is a way, either 
> > create a tap, or connect another tunnel wireguard from inside freeRtr-r3 
> > to inside her host vm, so there will be communication. 
> > 
> > I need this so that the prometheus server can reach the endpoint of the 
> > tunnel wireguard of freeRtr-r2 so that it can monitor the network 
> > interfaces of freeRtr-r2 through an agent running on top of it.
> > 
> > Here is a picture of the topology to help:
> > 
> > <image.png>
> > 
> > 
> > Background: I am working on this topology to ensure that there is 
> > monitoring with network isolation.
> > 
> > Honestly I am lost, I need help... 
> > 
> > Thank you,
> > 
> > Att: Gabriel Tetzner
> > 
> > 
> > 
> > 
> > 
> > Em qua., 31 de ago. de 2022 às 06:27, Frédéric LOUI 
> > <> escreveu:
> > Hi Gabriel,
> > 
> > Good to see that you did progress thanks to Csaba’s advice.
> > Looking at your question, something is not clear for me, what are you 
> > trying to achieve ?
> > Which end to end connectivity do you want to enable here?
> > 
> > You mention: "debian machine in freeRtr-r3 ping the ip of the freeRtr-2 
> > tunnel"
> > 
> > What is the IP of the Debian machine ? Is it the machine running freeRtr 
> > ? A machine connected to freertr-r3 ?
> > 
> > You also mention:
> > "In this topology consider that there is a prometheus server running on 
> > top of freeRtr-r3 debian and I need to talk to 10.0.0.3? »
> > Do you mean freertr server running Prometheus agent ? 
> > 
> > Is it possible to share configs of r1/r2 and r3 ?
> > 
> > Or please elaborate.
> > 
> > Thanks
> > Frederic
> > 
> > > Le 26 août 2022 à 22:17, Gabriel Tetzner 
> > > <> a écrit :
> > > 
> > > Now I am left with a question, how do I make the debian machine in 
> > > freeRtr-r3 ping the ip of the freeRtr-2 tunnel?
> > > 
> > > In this topology consider that there is a prometheus server running on 
> > > top of freeRtr-r3 debian and I need to talk to 10.0.0.3?
> > 
>