Peplink balance one routing issue


#1

Sorry but story depends on picture from the link otherwise it’s hard to explain all details.

In my test environment I replicate some of the use cases that I use in production.

I have 2 BPL-1 in network segment there issues occurred with 6.1.2 build 1576 on both.

Please see architecture in the

https://app.box.com/s/dd2lo25yxijzsm2uiqyu

So this pretty much I had transit VoIP trafic from site Z with dynamic IP and get around Cloud PBX IP restriction I enforce VoIP over PepVPN link on egress side
on Ingress side I enforced to WAN1 with Static IP white-listed on PBX.

After update this setting is broken but strangely I was able to make it to work with using priority instead of enforce and in prioritys I select again WAN1 and Pep VPN connection to SF hub on Pep380.

Isn’t it all odd?


#2

This is strange and interesting. Can you open ticket here for us to investigate?


#3

[Ticket #743603] Peplink balance one routing issue


#4

you know what?

Now I convinced that this functionality doesn’t work right,

here is my another example there it’s broken too.

So on Ananaspep1 site with my outbound rule set to anything what goes to

pbx.pangeaequity.com

Use WAN1 or down the priority send it to CC VPN.

Here in my test scenario again all relevant to original issue on ananaspep1 site I have WAN1 Static IP whitelisted on pbx.pangeaequity.com and any WAN IPs on ccVPN site is also whitelisted on PBX.Pangeaequity.com but WAN2 is NOT whitelisted as it’s dynamic IP

and what’s why my SIP endpoints or even in the browser on PC I can’t go to PBX.pangeaequity.com

but If it would route as it should I didn’t had any issues with my SIP endpoint or PC accessing PBX.pangeaequity.com

Also As I mentioned earlier why outbound routes have redundant rules to same destinations by IP and
domain name that looks like routing by domain name doesn’t work and its broken since 6.1.1 at least.
haven’t tried it on 6.1.0


#5

Hi Andrey,

I have replied you in the ticket. Please follow up there.

Thank you.


#6

I’ve agreed for a PC may be but SIP endpoint do not cache dns.

It got broken again, on ananaspep1 device my sip traffic to destination pbx.pangeaequity.com going out via WAN2 which is not I set in the rules.


#7

ahh I can’t apply to remove DNS caching due to another issue:

https://forum.peplink.com/threads/3499-Noticed-on-balance-one-Local-DNS-settings-issue


#8

Hi Andrey,

Your case have escalated to engineering. Stay tuned.


#9

See some weird behavior with SIP traffic on this,

In my tests getting 1 way audio which is pretty much RTP traffic getting blocked somewhere.

Do you mind take a look in internals?

Details are here:
on ananaspep1 LAN PBX behind NAT on 172.16.82.35

SIP Endpoint pokes registration via UDP 213.155.221.14:5060 from to 172.16.82.35:5060 SIP WAN 1 Comcast 24

but in SIP invite phone call gets connected but RTP done via port forward of range 10000-20000 not going through.

RA is on.


#10

Hi Andrey,

Appreciate if you can upgrade to this firmware http://download.peplink.com/firmware/plb1/fw-b1_hd4-6.1.2s24-build1598.bin.


#11

Hi Andrey,

Sorry I am not Voip expert. Can you elaborate more RTP via port range 10000 - 20000? Basically the communication is from where to 172.16.82.35? In short what is the possible source IP to communicate with 172.16.82.35?


#12

in very high overview:

in this case source UDP from IP 213.155.221.14 and it uses port 5060 for registration, and then if there is a phone call after establishing session it uses UDP RTP in this case select random port in the range 10000-20000 to send UDP traffic which carries Voice packets.


#13

Andrey, Would you please start the network capture on the unit http://<Unit IP address>/cgi-bin/MANGA/support.cgi and make a call in order to reproduce the issue. Then, get the captured file and send to us?


#14

sorry on weekend, will not be able to do it now (too late) and tomorrow will be very busy day.


#15

here is another case with SOHO:

[Ticket #743987] PepVPN Outbound Custom Rules


#16

Hi Andrey,

Your ticket has been escalated to engineering team for further checking.

Thank you.