Rare project developers

[mc36 <>]

hi,

On 8/9/22 15:08, Edgard da Cunha Pontes wrote:
> We're still figuring out what kind of overlay we'll use for these connections.
> For now, we have tested: VXLan, GRE and Wireguard. 
for raw ip tunneling, all of these should work, and could be exported to the 
dataplanes...

> And the idea of using PolKA to enable a "network service at the ends" came up.
so polka requires an ethertype to be distinguished as upper layer protocol,
and such, wireguard cannot do the job because that one cannot carry anything
but ip... vxlan could work, but when it comes to the dataplane exports, you'll
have to xconnect a hairpinX1 with vxlan between the two nodes, and do the 
polka
on the hairpinX2...
on the other hand, gre can carry anything, including polka, even in the 
dataplanes...

> We are not sure which type of tunnel to use. Always making a 
> performance/safety/practical tradeoff...
for performance and mtu, gre is the best because it have the lowest overhead:
no udp layer at all, so the nodes don't have to deal with the outer udp 
checksum,
just the outer ip checksum...

regarding security, you can always put macsec to the tunnel interface if it 
can carry
an ethertype... it's not quite standard but heyy, if the ethertype is there, 
then
nothing can stop freerouter and dataplane to do the encapsulation this way... 
:)

br,
cs


> Thanks again for your help.
>
> Em seg., 8 de ago. de 2022   s 12:26, mc36 < <>> 
> escreveu:
>
>     imho i've an idea what happened: so the one-line installer wipes the 
> linux networking completely,
>     from that point the linux's network stack only have a 10.255.255.1/24 
> <http://10.255.255.1/24> ip and is hidden behind freerouter...
>     so imho it failed to bind to the requested ip:port pair from the 
> config... moreover, since the linuxes
>     dont have the public ips anymore, the given setup you're trying to do is 
> a double-nat case, but without
>     anything to punch through the nats, as these interface sockets should 
> have direct visibility....
>     br,
>     cs
>
>
>     On 8/8/22 17:18, mc36 wrote:
>      > hi,
>      >
>      > On 8/8/22 17:01, Edgard da Cunha Pontes wrote:
>      >> i everyone,
>      >>
>      >> Testing a socket connection between   RARE/freeRtr VMs (one line 
> install),   as in the image shown below.
>      >>
>      >> socket-connection.jpg
>      >>
>      >> I put the following settings:
>      >>
>      >> VM1 /rtr/rtr-hw.txt
>      >> ....
>      >> [other configs]
>      >> int eth2 eth [mac-vm1] [public-ip-vm1] 20004 [public-ip-vm2] 20004
>      >> ....
>      >>
>      >> VM2 /rtr/rtr-hw.txt
>      >> ....
>      >> [other configs]
>      >> int eth2 eth [mac-vm2] [public-ip-vm2] 20004 [public-ip-vm1] 20004
>      >> ....
>      >>
>      >> After restarting the VM I lost SSH access permanently.
>      >> Is there any way to make this socket connection prevent this from 
> happening?
>      >>
>      >> PS:   I'm trying to create this eth2 dynamically, ie a new internal 
> interface was not created.
>      >
>      > this one should work as long as you dont reuse nor eth2 nor the port 
> 20004...
>      > so for now i see nothing to justify why you lost the ssh access...
>      >
>      > but on the other hand, is there any reason you want to connect these 
> this way?
>      >
>      > i mean, there are plenty of other tunneling modes in freerouter that 
> can make it work:
>      > http://sources.freertr.org/cfg/conn-gre01.tst 
> <http://sources.freertr.org/cfg/conn-gre01.tst> -- is a a plain old stuff and 
> imho
>      > it have less overhead than anything else.... and it also can carry 
> layer2 frames,
>      > you just have to put a bridge-group on the tunnel...
>      >
>      > br,
>      > cs