Skip to Content.
Sympa Menu

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: ,
  • Subject: Re: [RARE-users] [freertr] [rare-dev] SD-WAN experiment
  • Date: Wed, 3 Aug 2022 05:47:57 +0200
hi,
so in vpdn, the prefer ipv4 knob is about the underlay...
regarding the other part, that it did not start without ipv6 on the dialer,
it sounds like a bug, i'll check and get back to you...
br,
cs


On 8/2/22 23:02, wrote:
Hi Csaba!

After many tests... I realized that even using the command "prefer ipv4" in vpdn, it
was necessary to use the command "ipv6 address dynamic dynamic" in the dialer
interface.

Only after I made this modification, besides pool6 of course, did sdwan work.

Thank you so much for your help.

Em qui., 28 de jul. de 2022 s 10:16, mc36 < <>>
escreveu:

..... 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
<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 <http://sandbox.freertr.org> 12345
> resolving sandbox.freertr.org <http://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 <http://sandbox.freertr.org> 12345
> resolving sandbox.freertr.org <http://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 <http://sandbox.freertr.org> 12345
> resolving sandbox.freertr.org <http://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>
<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> <http://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> <http://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>>>
>>>> >
<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>>> <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
<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>>>>
>>>> > >>
<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 (#466) <https://groups.io/g/freertr/message/466> | Reply To Group <> | Reply To Sender <> | Mute This Topic <https://groups.io/mt/92669551/6006518> | New Topic <https://groups.io/g/freertr/post>
Your Subscription <https://groups.io/g/freertr/editsub/6006518> | Contact Group Owner
<> | Unsubscribe <https://groups.io/g/freertr/unsub>
[]

_._,_._,_

Archive powered by MHonArc 2.6.19.

Top of Page