# Configuring Sierra Wireless RV55 for IVPN

After figuring out a problem after hours of struggle, the simplicity of the result often belies the difficulty of the process. When I look at the final configuration that I came up with in ACEManager, everything looks simple and obvious, but the process was far from it. That’s the case nearly every time I configure a new feature on my Sierra Wireless RV55 LTE router. This device is not made for consumers. It’s built for ambulances, traffic lights, Greyhound buses, remote gas pipelines, and their ilk. Not bozos like myself boondocking in their RVs. Lucky for me, I know my way around this thing pretty well now.

The task at hand this week was configuring VPN, which is generally very simply on the RV55. After all, under the hood it runs Linux and runs OpenVPN (albeit an ancient version). However, problems arise when you need to configure something for which the UI is confusing or non-existent. You can’t simply edit an openvpn.conf.

This is the final result in ACEManager. The problems I ran into along the way, as with most VPN services, is that they provide no documentation for a “generic” OpenVPN configuration – which is the closest thing to your Sierra Wireless device as you can hope for. What you can do, however, is open up a VPN provider’s .ovpn files and start plugging the values into ACEManager.

The trickiest part was knowing what to do for MSSFix (--mssfix) and Fragment (--fragment). Without knowing the esoteric fact that IVPN does not provide mssfix and fragment directives on their end, you can’t possibly know that you need to disable them in your RV55 config. Furthermore, you can’t possibly know that a 0 value in the ACEManager UI removes the directive from the local OpenVPN client configuration that the RV55 generates (granted, it should be your first guess). While I did guess that I was having mssfix/fragment issues based on the following error message:

Mar 17 13:10:23 err openvpn-1[1937]: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented

It wasn’t clear that I had actually fixed it, because I also had Compression disabled the first time I attempted setting mssfix/fragment to 0 (both default to 1400 and 1300 respectively), and a different error was thrown that I mistook for a fragment problem.

That brings us to compression. If you look at the .ovpn files that ivpn provides, you (I) might misinterpret the following directive to mean that compression should be disabled: comp-lzo no in ACEManager. Indeed not. Compression needs to be Enabled in the UI, which presumably puts OpenVPN in adaptive mode, to allow the server side to define compression settings.

It’s always a wild journey with “Enterprise” hardware and software. I hope this helps someone else, but it’ll be a useful note-to-self either way.

Cheers