Skip to Content.

rare-users - Re: [RARE-users] [freertr] [rare-dev] SD-WAN experiment

Subject: RARE user and assistance email list

List archive


Re: [RARE-users] [freertr] [rare-dev] SD-WAN experiment


Chronological Thread 
    < Chronological >      < Thread >
  • From: mc36 <>
  • To: Edgard da Cunha Pontes <>
  • Cc: "" <>
  • Subject: Re: [RARE-users] [freertr] [rare-dev] SD-WAN experiment
  • Date: Thu, 28 Jul 2022 15:16:58 +0200
..... but, what if you use your all-the-way-public _ipv6_ addresses to
overcome all the below concerns? :)

On 7/28/22 15:12, mc36 wrote:
ohh, and a final one: could you please verify if you're behind a proper nat:
https://en.wikipedia.org/wiki/Hole_punching_(networking)#Requirements

the objective here, is the client initiated port should be echoed back by the
server:

start with your home connection, because these tend to be cgn, which is,
known to not satisfy the requirements...

br,
cs


mchome#configure
mchome(cfg)#client tcp-portrange 1234 4321
mchome(cfg)#
mchome#
mchome#
mchome#telnet sandbox.freertr.org 12345
resolving sandbox.freertr.org for ipv6 ok!
connecting to 2001:738::520:f816:3eff:fe26:8e42 12345 ok!

you (2a01:36c:111:d590:1a:6e0f:402c:2540 - 3338) have been logged!

connection closed
mchome#configure
mchome(cfg)#client tcp-portrange 12345 12377
mchome(cfg)#
mchome#
mchome#telnet sandbox.freertr.org 12345
resolving sandbox.freertr.org for ipv6 ok!
connecting to 2001:738::520:f816:3eff:fe26:8e42 12345 ok!

you (2a01:36c:111:d590:1a:6e0f:402c:2540 - 12364) have been logged!

connection closed
mchome#configure
mchome(cfg)#client tcp-portrange 32768 61440
mchome(cfg)#
mchome#telnet sandbox.freertr.org 12345
resolving sandbox.freertr.org for ipv6 ok!
connecting to 2001:738::520:f816:3eff:fe26:8e42 12345 ok!

you (2a01:36c:111:d590:1a:6e0f:402c:2540 - 56278) have been logged!

connection closed
mchome#


On 7/28/22 15:02, mc36 wrote:
one more thing... after checking the sockets, we also should check the sho
ppp accessXXX


On 7/28/22 15:00, mc36 wrote:
hi,
okk, so for now, i see that the peer private addresses are advertised here...
then my previous suggestion about doing so, should be undone, on the central
node, do serv sdw / nat
after clearing the vpdns on the clients, you should be able to spot the
public ips, instead of the nat internal...
at that stage, sho ipv4 sock xxx should tell you if the two clients are able
to communicate properlY...
the thing to spot here is the proper public ips are propagted, and you have
increasing hit counts on them...
br,
cs



parents#show ipv4 sockets inet3 | hinclude sdw
lower name state iface local remote
address hit
udpCln sdwan null hairpin61 6944 6359
193.224.22.173 32629
udpCln sdwan null hairpin61 6944 6411
91.82.168.57 3435
tcpCln sdwan estab hairpin61 35195 2554
217.61.5.97 3862

parents#

meso#show ipv4 sockets inet2 | hinclude sdw
lower name state iface local remote
address hit
udpCln sdwan null sdn1.99 6824 6359
193.224.22.173 3467
udpCln sdwan null sdn1.99 6824 6411
91.82.168.57 3446
tcpCln sdwan estab sdn1.99 53703 2554
217.61.5.97 397

meso#

www#show ipv4 sockets inet | hinclude sdw
lower name state iface
local remote address hit
udpCln sdwan null ethernet1 1935
6359 193.224.22 ..173 1181074
udpCln sdwan null ethernet1 1935
6411 91.82.168.57 21061
tcpCln sdwan estab ethernet1 42643
2554 217.61.5.97 3879

www#



On 7/28/22 14:16, Edgard da Cunha Pontes wrote:
Hi Csaba! Thanks again.

This is the last update on git repository.
https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01>

freertr-home#show vpdn gcloud
user peer port num
iface
addr4 addr6
u 10.0.0.142 2554 26444 access1762124930
2.2.2.10 ::

access1762124930 is down
description:
state changed 2 times, last at 2022-07-28 11:23:02, 02:52:26 ago
last packet input never ago, output never ago, drop never ago
type is dialer, hwaddr=none, mtu=1396, bw=8000kbps, vrf=inet
ipv4 address=2.2.2.12/32 <http://2.2.2.12/32>, mask=255.255.255.255,
ifcid=433965459
received 0 packets (0 bytes) dropped 0 packets (0 bytes)
transmitted 0 packets (0 bytes) macsec=false sgt=false

freertr-oci#show vpdn gcloud
user peer port
num iface
addr4 addr6
u 192.168.25.46 2554 1940
access1982024875 2.2.2.12 ::

access1982024875 is down
description:
state changed 2 times, last at 2022-07-28 11:23:02, 02:53:08 ago
last packet input never ago, output never ago, drop never ago
type is dialer, hwaddr=none, mtu=1396, bw=8000kbps, vrf=inet
ipv4 address=2.2.2.10/32 <http://2.2.2.10/32>, mask=255.255.255.255,
ifcid=679567661
received 0 packets (0 bytes) dropped 0 packets (0 bytes)
transmitted 0 packets (0 bytes) macsec=false sgt=false

freertr-gcloud#show sdwan gcloud
addr port user hub id prt addr port prm inner4 inner6 for since
[public-ip-home] 39679 u true 1940
4 192.168.25.46 2554
2.2.2.12 :: 02:35:48 2022-07-28
11:22:56
[public-ip-oci] 53122 u true
26444 4 10.0.0.142 2554
2.2.2.10 :: 02:35:51
2022-07-28 11:22:53


Em qui., 28 de jul. de 2022 s 07:06, mc36 < <>>
escreveu:

could you please point me to the repo to the latest configs?
also could you please share the show vpdn xxx from all the clients,
and the show sdwan xxx from the central box?
for a quick reference, here is mine below....
-all the addresses in the sho vpdn should be public, bidir reachable
addresses...
-in case of hub-spoke, the thing to spot here is that all the clients
should have the same output, whereas the hub should list all the clients...
-in case of full-mesh (default configuration), everyone should list
everyone else except himself....
thanks,
cs

parents#show vpdn vpn4
user peer port num
iface addr4
addr6
mchome 91.82.168.57 4696 12929 access1200506110
10.18.127.117 2001:db8:187f::1137
p4deb 193.224.22.173 6359 1100
access1076908568 10.18.127.122 2001:db8:187f::1152

parents#


meso#show vpdn vpn4
user peer port num
iface addr4
addr6
mchome 91.82.168.57 4696 12929 access1838629502
10.18.127.117 2001:db8:187f::1137
p4deb 193.224.22.173 6359 1100
access2099786268 10.18.127.122 2001:db8:187f::1152

meso#


www#show vpdn vpn4
user peer port num
iface addr4
addr6
mchome 91.82.168.57 4696 12929 access1710875635
10.18.127.117 2001:db8:187f::1137
p4deb 193.224.22.173 6359 1100 access564537561
10.18.127.122 2001:db8:187f::1152

www#








On 7/28/22 11:45, Edgard da Cunha Pontes wrote:
> Hi Csaba! After a few weeks... Thank you very much for all the
good tips.
>
> But... Unfortunately, some problems have remained.
>
> #1 I gave up using loopback. For a while.
>
> #2 I gave up using VMs for testing on OpenStack, as they don't
have Public IP for each.
>
> #3 I'm using a VM on OCI to simulate another client on SD-WAN
(GCloud).
>
> #4 I have a router purchased on Aliexpress, at my house, which I
already configured the RARE/freeRtr and pointed to the SD-WAN (GCloud).
>
> #5 I'm using a one-line install on all VMs and on the physical
router.
>
> #6 The access* interfaces are still down.
>
> Is there some setting I'm missing?
>
> PS: I'll put the configuration I'm using in the GitHub
repository to make the problem easier to understand. Hiding public IPs, always!
: )
>
>
> Em qua., 13 de jul. de 2022 s 02:42, mc36 < <>
< <>>> escreveu:
>
> ahhh yeahhh, and a bit about security... as you're
exposing a publicip:port thing on your gcloud,
> all these servers needs to be secured... please look
around access-? things and apply as much as you can.... :)
> br,
> cs
>
>
>
> On 7/13/22 07:30, mc36 wrote:
> > hi
> > so being behind the same neting device usually
does not work,
> > because then the nating have to send back the
packet on the same
> > interface where it came from... for example ovs
cannot do that...
> > but nevermind, on the server side have a knob to
distribute
> > the client learned addresses instead of the
server learnt ones,
> > i thought about mpls l3 vpns, but it also
applies to your case...
> > (but be warned, this way your gcloud loopback
will not be reachable!)
> >
> > gcloud#serv sdw xxx
> > no natted
> > end
> >
> > after this, you may need to re-trigger cloning
at your clients
> > clntX#cle vpdn xxx
> >
> > after these, your access interfaces should go up
soon...
> > once your accesses are up and you could ping in
between the clients,
> > you could configure your routing stuff to your
dialers on the clients..
> > one you're done, you should re-trigger again on
them...
> >
> >
> > On 7/13/22 05:04, Edgard da Cunha Pontes wrote:
> >> Hi Csaba,
> >>
> >> Only now I was able to continue the tests with
the SD-WAN.
> >>
> >> After doing some testing, I got the following
progress:
> >>
> >> *On SD-WAN server (GCloud VM)*
> >> freertr#show sdwan gcloud
> >> addr port user hub id prt addr port prm inner4 inner6 for since
> >> [my-public-ip] 35206 u true 28694 4 192.168.25.43 2554 2.2.2.10 :: 00:55:00 2022-07-13 03:51:04
> >> [my-public-ip] 35520 u true 31270 4 192.168.25.45 2554 2.2.2.12 :: 00:08:32 2022-07-13 04:37:33
> >>
> >> *On client VMs:*
> >> freertr#show vpdn gcloud
> >> user peer port num iface addr4 addr6
> >> u
[my-public-ip] 2554 28694
access334989981 2.2.2.10 ::
> >>
> >> freertr#show vpdn gcloud
> >> user peer port num iface addr4 addr6
> >> u
[my-public-ip] 2554 31270 access782128584
2.2.2.12 ::
> >>
> >> I still don't have connectivity (ping) between the VMs
over the IPs (2.2.2.10 and 2.2.2.12). The dialer and "access..." interfaces are down.
> >>
> >> *i) Is it normal for the dialer and "access..."
interfaces to be down?
> >> *
> >> *ii) Is it now that I need to configure
a dynamic routing protocol between these nodes?*
> >>
> >> Thanks again.
> >>
> >> Em seg., 11 de jul. de 2022 s 12:58, mc36 < <> < <>> < <> <
<>>>> escreveu:
> >>
> >> hi,
> >> so these
vpdns should point to the eth1's ip of the gcloud node, assuming that ip is public or
at least reachable to the clients...
> >> if you want
to make that private addressed loopback on the gcloud node reachable to the clients
then you'll have to add the
> >> client config
knobs to the gcloud node itselt too... btw please note that this sdwan server just
creates a bunch of l2tp
> >> back and
forth between the clients (marked as hub).. to move further, you'll need to run a
routing protocol above these...
> >> feel free to use
the following as an example: http://sources.freertr.org/cfg/serv-sdwan01.tst
<http://sources.freertr.org/cfg/serv-sdwan01.tst>
<http://sources.freertr.org/cfg/serv-sdwan01.tst
<http://sources.freertr.org/cfg/serv-sdwan01.tst>>
> <http://sources.freertr.org/cfg/serv-sdwan01.tst
<http://sources.freertr.org/cfg/serv-sdwan01.tst>
<http://sources.freertr.org/cfg/serv-sdwan01.tst
<http://sources.freertr.org/cfg/serv-sdwan01.tst>>>
> >> to run it
locally on your computer, you can do the following:
> >> wget freertr.org/rtr.zip
<http://freertr.org/rtr.zip> <http://freertr.org/rtr.zip <http://freertr.org/rtr.zip>>
<http://freertr.org/rtr.zip
<http://freertr.org/rtr.zip> <http://freertr.org/rtr.zip
<http://freertr.org/rtr.zip>>>
> >> unzip rtr.zip
> >> cd src
> >> ./c.sh
> >> ./tw.sh
serv-sdwan01
> >> afterward all
the above, you can reach the router described in the test case by
> >> telnet
localhost 20001
> >> telnet
localhost 20002
> >> telnet
localhost 20003
> >> telnet
localhost 20004
> >> br,
> >> cs
> >>
> >>
> >> On 7/11/22
16:56, Edgard da Cunha Pontes wrote:
> >> >
Hi everyone!
> >> >
> >> >
While I was testing RARE/freeRtr's SD-WAN functionality, the following (noob) question
came up:
> >> >
> >> > On client VMs, how to point to a loopback interface, on VM/GCloud (SD-WAN server) that is behind an associated public IP? I was in doubt which target
I should
> put in the
> >> vpdn settings.
> >> >
> >> > I
made a basic description of the settings I am using:
> >> >
> >> >
https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01>
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01>>
>
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01>
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01>>>
> >>
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01>
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01>>
>
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01>
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01
<https://github.com/edgardcunha/freeRouter/tree/main/sdwan/01>>>>
> >> >
> >> > I
hope this basic description can help you to understand this doubt.
> >>
>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#443): https://groups.io/g/freertr/message/443
Mute This Topic: https://groups.io/mt/92667272/6006518
Group Owner:
Unsubscribe: https://groups.io/g/freertr/unsub []
-=-=-=-=-=-=-=-=-=-=-=-



Archive powered by MHonArc 2.6.19.

Top of Page