we are Struggeling with some IPSEC Configuration via a DSL Line on a Huawei AR169 Router.

When the Tunnel is running over an PPPoE Dialer we notice about 70% Packet Loss in the Tunnel. When the Tunnel is running via Ethernet or Cellular Link everything is fine.

We tested this behavior between the AR160 and several vendors on the opposite Side (Cisco Routers, Fortigate Firewalls, further Huawei AR a.s.o.)

Currently we are running on VRP Version 5.160 (updated to this during Troubleshooting process)

Current PPPoE Configuration:

 interface Dialer1
 link-protocol ppp
 ppp chap user XXXXXXXXXXXXX
 ppp chap password XXXXXXXXXXX
 ppp ipcp dns admit-any
 ppp ipcp dns request
 mtu 1456
 ip address ppp-negotiate
 dialer user arweb
 dialer bundle 1
 dialer-group 1
 nat outbound 2000 interface LoopBack 0 

IPSEC Tunnel related configuration

ipsec proposal IPSEC-PROP
 esp authentication-algorithm sha2-256 
 esp encryption-algorithm aes-256
ike proposal 1
 encryption-algorithm aes-cbc-256
 dh group2
 authentication-algorithm sha2-256
 prf hmac-sha2-256
ike peer IKE-PEER v1
 pre-shared-key simple XXXXXXXXXX
 ike-proposal 1
 local-address XXXXXX
 remote-address XXXXXXXX
ipsec profile IPSEC-PROFIL
 ike-peer IKE-PEER
 proposal IPSEC-PROP
 sa duration time-based 43200   
interface Tunnel0/0/0
 tcp adjust-mss 1300
 ip address unnumbered interface Vlanif1
 tunnel-protocol ipsec
 source LoopBack0
 destination XXXXXXXXXXX
 ipsec profile IPSEC-PROFIL

This is my Setup:

SiteA --- AR169 --- Internet --- Cisco C886VA --- SiteB
  1. Ping between AR169 and C886 (LAN-to-LAN) => OK
  2. Ping from AR169 to systems in SiteA => OK
  3. Ping from AR169 to systems in SiteB => NOK
  4. Ping from C886 to systems in SiteB => OK
  5. Ping from C886 to systems in SiteA => NOK
  6. Replacing the DSL Line at AR169 by some other WAN Technology (Ethernet, Cellular) => OK

First i thought of an MTU issue because the DSL is the only media that doesn't support the MTU of 1500 bytes. But that doesn't explain the huge amount of loss during PINGs with standard packet size.

"display ipsec statistics esp" doesn't show any drops.

Can anybody give me a hint how to isolate the root cause of this drops?

Thanks in advance Andreas


During troubleshooting we found an interesting behavior. Sending packets that are too large to be transported by tunnel MTU, so that have to be fragmented by the Router, are transported with 100% Success. So: - "ping -l 1363 " => Packet Loss - "ping -l 1364 " => 100% Success

--UPDATE 2--

Doing a packet capture on the AR160 has the Effect that Traffic is running fine. As soon as the Capture stops, we see the PL again. So i think the root cause is to find somewhere in the VPN hardware acceleration (i think that fragmentation and traffic capturing is process-switched by the CPU and not offloaded to an ASIC or some different silicon). Meanwhile we are in contact with some engineers of Huawei. I will keep you informed.

  • What do your logs and debugging look like when this happens?
    – Ron Maupin
    Commented Jul 10, 2017 at 14:42
  • Hi, The logs are without any entrys. Can you give me a hin which debugs could have interesting output? Commented Jul 10, 2017 at 15:06
  • If you do a "show int dialer1" does the interface show any input errors, CRC or anything like that?
    – user36472
    Commented Jul 10, 2017 at 15:51
  • Have you double checked the MTU? Which of the pings above use IPsec, which are plain?
    – Zac67
    Commented Jul 10, 2017 at 17:40
  • Hi, ... output of "display int dialer 1" is without any noticeable errors or drops... Internet connectivity is fine. MTU of 1456 is correct due to PPPoE via L2TP... we have hundrets of Ciscos that are running fine with this configuration. PING Tests 1,3, 5 and 6 are transported via IPSEC. Commented Jul 11, 2017 at 7:01

1 Answer 1


Huawei confirmed a bug in their Software. The Fix will be enrolled in the september-patch. We have a hot-fix that solves the problem in our testing environment.

  • You should accept your answer so that the question doesn't keep popping up forever, looking for an answer.
    – Ron Maupin
    Commented Aug 27, 2017 at 19:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.