Updated: Feb 26, 2019
We are pleased to announce that Firmware 8 is now in Beta 3.
Supported models:
EPX, Balance, MAX, SpeedFusion Engine, FusionHub, Surf SOHO
Head over to https://www.peplink.com/open-beta-program/ and get yours now!
4 Likes
I am excited to see
ā19059
[Remote User Access] Added support for Active Directory in
remote user access.
Balance: 210 or above
MAX: 700, HD2, HD4
Series
EPXā
in the release notes. However, such poor timing for us as we just recently committed to moving the core infrastructure to hardware that could handle Active Directory integration without physical VPN/peplink tunnels.
Hi Travis. This is a bit disappointing to me. While I interpreted the choice of not letting PPTP and IPSec/L2TP to be both enabled as a security choice, with the introduction of OpenVPN I was hoping to have the choice of keeping two inbound VPN technologies to offer more availability/compatibility with clients and different remote networks conditions (for example we found networks where outbound IPSec connections were blocked). For long time in different work environments I used enthusiasts firmware platform like dd-wrt/tomato where multiple VPN solutions enabled at same time has been a reality for several years, so I think times are mature enough to find the same possibility in products like the Balance routers. Could the choice be considered again?
I have a question: can the Remote User Access on OpenVPN be used together a IPSec/L2TP service? Iām asking because currently one may just choose between PPTP and IPSec/L2TP, and canāt use both, which I quite understand since PPTP is today very insecure and one should think carefully before enabling it. OpenVPN and IPSec/L2TP both seem viable solutions and it is worth enabling both to enlarge compatibility on devices and network configurations. I didnāt try the firmware yet so I donāt know how it is the situation now.
No worry for the expiration date, latest firmware in beta or RC or GA will be released prior the expiration date.
1 Like
Hi - you can only use one method at a time.
1 Like
Iām using beta 3 right now and like it. But what happens when the beta expires? Does the router just lock up? Are we likely to get a new beta before then, or would I have to revert back to 7.x ?
fec is awesome. Iām getting really solid results to FH Solo and a Br1-mini with wansmoothing+fec both at ānormalā with WAN+CELL.
in v7 I wasnāt getting satisfactory failover times, in v8 itās like butter.
I do see a bug with receive buffer. If itās enabled, I see duplicate packets on icmp ping across the SF tunnel.
2 Likes
As usual, I get the fun of reporting a really, REALLY strange problem. And you will be tempted to reply āyou are on crackā, but I am pretty sure of what I am seeing.
I have been testing 8.0 B2 and now B3 for a while on some BR1s. This morning I upgraded two B710s that are hubs for a lot of speedfusion connections.
Layout:
Phone system in data center. Several B710s as border routers.
All remote locations have BR1 or similar for celluar backup and PEPVPN.
Phones are on unique, routed private IPs at remote locations, so no NATing involved.
Today we started getting reports of problems with some call transfers and with paging. Other than that, all phones are operating normally.
I initially assumed it was a problem in our phone system, but when I got down to doing packet captures I discovered that the SIP INVITE packets going out to the phones get no response when the invite includes an alert-info to take the phone off hook (for paging). All other invites work normally.
Nowā¦at my office my BR1 was already running 8.0 B3, and paging works fine here.
At my techās home office, their BR1 was still on latest 7.1 release. Their paging did not work.
I upgraded their BR1 to 8.0 B3 and their paging works. did same for several customers who were complaining, and it corrected it for them as well. I could not just downgrade the B710s because this is just coming into the busy time for my customers (pizza restaurants) and that is too risky. But I will do it tonight.
Note that while it was not working (remote location still on 7.1), doing a packet capture on the remote BR1 did not see the packets. DOing a packet capture on the B710 at the data center did show them.
i.e. the packet leaves the phone system, reaches the B710 (running 8.0) but does not reach the BR1 (running 7.1) over the PEPVPN.
Also - dropping the VPN did make it work. So - it is only when 8.0 <==> 7.0 pepvpn connection is in use that this fails.
My conclusion is that if you have a 8.0 B3 (pepvpn 8.00) connected to a 7.1 (pepvpn 7.00) there is some kind of VERY odd SIP manipulation being done, even though we have āservice passthrough SIPā set to compatibility mode, which should turn off SIP ALG.
Plusā¦No SIP ALG should give a ratās ass about the alert-info content. If the Peplink is looking at that level something is very wrong.
For those non-voip people (or anyone who does not get down in the weeds of SIP headers), what I am saying is that a normal INVITE from phone system IP to phone IP works fine. SLIGHTLY different INVITE from same source to same destination, differing only in a minor detail does not get to the far end.
Packet from paging (does not get through)
U 66.11.27.82:5060 ā 10.200.210.21:5060
INVITE sip:[email protected]:5060 SIP/2.0.
Via: SIP/2.0/UDP 66.11.27.82:5060;branch=z9hG4bK12b0df81;rport.
Max-Forwards: 70.
From: āPLP-131 Demoā sip:[email protected];tag=as6462120c.
To: sip:[email protected]:5060.
Contact: sip:[email protected]:5060.
Call-ID: [email protected]:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 13.19.0.
Date: Wed, 20 Feb 2019 21:08:35 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
X-PBX: 99|131-PLP|131-PLP|40||||cluster1cola.securemax.us-1550696915.75601|14544|yes|||T||700|700|94||||||en||||.
Answer-Mode: Auto.
Alert-Info: http://www.notused.com;info=alert-autoanswer;delay=0.
P-Auto-Answer: normal.
Alert-Info: Ring Answer.
Alert-Info: intercom.
Alert-Info: info=intercom.
Call-Info: answer-after=0.
Alert-Info: info=ringAutoAnswer.
Alert-Info: Info=Alert-Autoanswer.
Call-Info: ;Answer-After=0.
X-VoipMonitor-Custom1: cluster1cola.securemax.us-1550696915.75601.
P-Asserted-Identity: āPLP-131 Demoā sip:[email protected].
Content-Type: application/sdp.
Content-Length: 250.
.
v=0.
o=root 1206930005 1206930005 IN IP4 66.11.27.82.
s=Asterisk PBX 13.19.0.
c=IN IP4 66.11.27.82.
t=0 0.
m=audio 10622 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=maxptime:150.
a=sendrecv.
packet from regular call (does get through)
U 66.11.27.82:5060 ā 10.200.210.21:5060
INVITE sip:[email protected]:5060 SIP/2.0.
Via: SIP/2.0/UDP 66.11.27.82:5060;branch=z9hG4bK44bbc31a;rport.
Max-Forwards: 70.
From: āJohn Scullyā sip:[email protected];tag=as3dad97a9.
To: sip:[email protected]:5060.
Contact: sip:[email protected]:5060.
Call-ID: [email protected]:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX 13.19.0.
Date: Wed, 20 Feb 2019 21:38:48 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
X-PBX: 99|101-PLP|101-PLP|40||||cluster1cola.securemax.us-1550698728.89765|17207||||T|60|105PLP|105PLP|94||||||||||.
X-VoipMonitor-Custom1: cluster1cola.securemax.us-1550698728.89765.
P-Asserted-Identity: āJohn Scullyā sip:[email protected].
Content-Type: application/sdp.
Content-Length: 248.
.
v=0.
o=root 104264102 104264102 IN IP4 66.11.27.82.
s=Asterisk PBX 13.19.0.
c=IN IP4 66.11.27.82.
t=0 0.
m=audio 16812 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=maxptime:150.
a=sendrecv.
Iāve been able to also duplicate Johnās original issue
B710 8.0b3 ā B30 8.0b3 , phones registered via UDP , normal calls works, calls with extra data in the sip header also work.
B710 8.0b3 ā B30 7.1.2 , phones registered via UDP , normal calls works, calls with extra data in the sip header do not work.
B710 8.0b3 ā B30 7.1.2 , phones registered via TCP , normal calls works, calls with extra data in the sip header also work.
It seems that their may be a correlation on UDP packet size and backwards compatibility between a pepvpn 8 and a pepvpn 7 device.
1 Like
My Beta3 expires on Apr 24. Can you double check?
2 Likes
Something strange happened today with the B30 Iām testing the V8.xx Beta 3 on. Log in became slower and slower throughout the day, both via IC2 and direct. IC2 showed it going Red then Orange back to Green even though internet connectivity was fine locally. No clients were showing via either method. I suspect the CPU was at high load, but no way to test because I couldnāt get that far in to the GUI. I do have a diagnostic download after reboot if that will help and once restarted it is back to normal. This B30 normally runs for months with no problem so this is a bit of a concernā¦
Thanks Jonathan,
Correct, which is IP fragmentation problem in beta 3 if remote PepVPN peer version is 7.1 or below.
Fix is included in RC1 which is coming out very soon.
2 Likes
Yes, indeed Iām wrong and you are right: my beta3 has an expiration of 24 APRIL, not february. I wasnāt reading it correctly.
Nevermind!
@jmpfas, Iām curious why you find it necessary to use SIP Compatibility mode. We have a lot of SIP traffic from multiple equipment vendors among our sites connected by PepVPN and externally. Iāve never seen an issue that required SIP Compatibility mode. What was the behavior causing you to select that feature?
1 Like
Just checking back - only 4 days left, is the RC / GA still coming before?
Peplink engineers,
Has anything changed in pepvpn v8 that would prevent the pepvpn from sending fragmented udp packets? I suspect whatās happening to jmpfas and myself is similar to described in this article.
https://www.sonicwall.com/en-us/support/knowledge-base/170505805848271