Having an "interesting" time with Sierra Wireless WWAN router & OpenVPN

[etaoin]

Just to avoid confusion: I have modified the openvpn-install script I got from https://github.com/Angristan/OpenVPN-install/ to say tls-version-min 1.0 instead of the 1.2 it defaults to - and I have re-installed OpenVPN using the updated script to make sure that there's nothing in the way the TLS key gets generated that would disallow a downgrade to TLS 1.0. That said, I still can't get things to work even with TLS Auth completely disabled, so this is likely not the issue. And to further clarify, the cipher and authentication schemes chosen are AES-128-CBC and SHA-256 respectively. The WWAN router's VPN config options do not explicitly list an AES-128-CBC option, only AES-128, but I assume CBC to be the logical default and that had they provided a GCM option then this would have been explicitly mentioned (with GCM being far newer).

[etaoin]

I would love to know myself! Alas, Sierra Wireless do not provide this information, and the SSH console provided by the router only accepts "AT commands", none of which allow me to query the OpenVPN or OpenSSL library versions. I have looked through the firmware release notes, and have contacted Sierra Wireless via their support forum for clarification on this, but my post there has gone unanswered for a week. That said, we are talking about a $700 router designed for vehicular use by emergency respondents; not only is it a pretty solid piece of kit but firmware updates are frequent, and I am running the latest (July?) firmware on it. Since they explicitly provide an OpenVPN client, which they shout about in the product literature, I would be very surprised if it couldn't be made to work.

Agreed .. and for that sort of money they can provide support for their product.

Agreed. But what if they don't? I didn't buy the RV50 new, and can't send it back. I chose to buy a second-hand RV50 rather than a new "Chinese" device at a similar price point precisely because I wanted something that would "just work". Boy do I feel like a sucker now.

But I'm not ready to give up just yet! It would be really great if someone could give me a quick explanation of what it is I'm seeing in the syslog when the connection from the WWAN router fails. As far as I can tell, each attempt consists of the following conversation (with TLS Auth disabled):

Code: Select all

Aug 20 21:38:03 myvpn ovpn-server[20695]: MULTI: multi_create_instance called
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 Re-using SSL/TLS context
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 Control Channel MTU parms [ L:1569 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 Data Channel MTU parms [ L:1569 D:1450 EF:69 EB:12 ET:0 EL:3 ]
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 Local Options String: 'V4,dev-type tun,link-mtu 1569,tun-mtu 1500,proto UDPv4,cipher AES-128-CBC,auth SHA256,keysize 128,key-method 2,tls-server'
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1569,tun-mtu 1500,proto UDPv4,cipher AES-128-CBC,auth SHA256,keysize 128,key-method 2,tls-client'
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 Local Options hash (VER=V4): 'cbc99a1e'
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 Expected Remote Options hash (VER=V4): '74006a71'
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 READ [14] from [AF_INET]44.55.66.77:50586: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 TLS: Initial packet from [AF_INET]44.55.66.77:50586, sid=ea771ecf 5cd87f06
Aug 20 21:38:03 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 WRITE [26] to [AF_INET]44.55.66.77:50586: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Aug 20 21:38:04 myvpn ovpn-server[20695]: 44.55.66.77:36001 UDPv4 WRITE [1188] to [AF_INET]44.55.66.77:36001: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1174
Aug 20 21:38:04 myvpn ovpn-server[20695]: 44.55.66.77:52777 UDPv4 WRITE [1188] to [AF_INET]44.55.66.77:52777: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1174
Aug 20 21:38:04 myvpn ovpn-server[20695]: 44.55.66.77:58779 UDPv4 WRITE [1188] to [AF_INET]44.55.66.77:58779: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1174
Aug 20 21:38:04 myvpn ovpn-server[20695]: 44.55.66.77:58787 UDPv4 WRITE [1188] to [AF_INET]44.55.66.77:58787: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1174
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 READ [22] from [AF_INET]44.55.66.77:50586: P_ACK_V1 kid=0 [ 0 ]
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:58787 UDPv4 WRITE [212] to [AF_INET]44.55.66.77:58787: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=198
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 READ [114] from [AF_INET]44.55.66.77:50586: P_CONTROL_V1 kid=0 [ ] pid=1 DATA len=100
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 WRITE [22] to [AF_INET]44.55.66.77:50586: P_ACK_V1 kid=0 [ 1 ]
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 READ [111] from [AF_INET]44.55.66.77:50586: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=97
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 WRITE [1200] to [AF_INET]44.55.66.77:50586: P_CONTROL_V1 kid=0 [ 2 ] pid=1 DATA len=1174
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 WRITE [1188] to [AF_INET]44.55.66.77:50586: P_CONTROL_V1 kid=0 [ ] pid=2 DATA len=1174
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 WRITE [212] to [AF_INET]44.55.66.77:50586: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=198
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:36001 UDPv4 WRITE [212] to [AF_INET]44.55.66.77:36001: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=198
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:52777 UDPv4 WRITE [212] to [AF_INET]44.55.66.77:52777: P_CONTROL_V1 kid=0 [ ] pid=3 DATA len=198
Aug 20 21:38:05 myvpn ovpn-server[20695]: 44.55.66.77:50586 UDPv4 READ [22] from [AF_INET]44.55.66.77:50586: P_ACK_V1 kid=0 [ 1 ]

and, a minute later:

Code: Select all

Aug 20 21:39:05 myvpn ovpn-server[20695]: 44.55.66.77:44082 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug 20 21:39:05 myvpn ovpn-server[20695]: 44.55.66.77:44082 TLS Error: TLS handshake failed
Aug 20 21:39:05 myvpn ovpn-server[20695]: 44.55.66.77:44082 SIGUSR1[soft,tls-error] received, client-instance restarting

What can you guys tell from this?

Edit: Is it worth looking at things like MTU, or is it clear from the above that the issue lies on the encryption side?

[TinCanTech]

How can we support your router when you can't even get the version of OpenVPN it has installed ?

[etaoin]

How can we support your router when you can't even get the version of OpenVPN it has installed ?

For one thing, maybe someone could explain why the OpenVPN version might matter, and what could be done to enhance interoperability between the different versions, such as choice of settings, ciphers etc. Is the backwards compatibility really that bad? Is there not some minimal basic configuration that can be tried? A "bullet proof" default for quirky clients? I'm quite happy to start over from scratch, if it means any prospect of success - should I perhaps try to install an older version of OpenVPN? Or is there maybe some way to get the OpenVPN client to identify itself? Or to glean something about its capabilities from the server log? What does the server log say anyway? What does "P_CONTROL_HARD_RESET_CLIENT_V2" and "P_CONTROL_HARD_RESET_SERVER_V2" mean, and are the responses in the log consistent with success or failure? At what point is the failure clear in the logs, other than the eventual time-out? I see a few "P_ACK_V1" coming in from the client as well? Would it help to turn verbosity up to 11? Could it have something to do with MTU and other packet metrics? Would it help if I became a paying user of OpenVPN? Could I pay you for your time? I'm over a week in the hole on this one and if I cannot find a solution then all that time will have been wasted.

I mean really, there is no end to the questions I have in my head around how OpenVPN works and what might be the cause of this issue - not being able to get answers here would be a far bigger hindrance than any lack of support from Sierra's side, since this is where the software in question comes from. Chances are if they did respond that's what they would say as well!

[etaoin]

I've just seen that there is a new thread in the Sierra forum about OpenVPN issues: https://forum.sierrawireless.com/viewto ... 49&t=10641 It looks like I might be able to get the OpenVPN client version if I push the router's syslog somewhere. Investigating.

[TinCanTech]

Openvpn is free open source software .. supported by volunteers.

Your router is not.

The simple fact is: We do not support your router.

You have my details ..

[etaoin]

Openvpn is free open source software .. supported by volunteers.

Your router is not.

The simple fact is: We do not support your router.

You have my details ..

All fair enough, and completely understood. Please don't take my frustration as criticism of OpenVPN, yourself or this forum. I very much appreciate the time you have already spent trying to help. But now I can at last report something of interest - I have configured a machine to receive the syslogs from the RV50, and lo and behold what I found in the openpvn-1.log

Code: Select all

2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] Control Channel MTU parms [ L:1573 D:138 EF:38 EB:0 ET:0 EL:0 ]
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] Data Channel MTU parms [ L:1573 D:1400 EF:73 EB:4 ET:0 EL:0 ]
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] Fragmentation MTU parms [ L:1573 D:1300 EF:73 EB:4 ET:0 EL:0 ]
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] Local Options String: 'V4,dev-type tun,link-mtu 1573,tun-mtu 1500,proto UDPv4,mtu-dynamic,cipher AES-128-CBC,auth SHA256,keysize 128,
key-method 2,tls-client'
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] Expected Remote Options String: 'V4,dev-type tun,link-mtu 1573,tun-mtu 1500,proto UDPv4,mtu-dynamic,cipher AES-128-CBC,auth SHA256,ke
ysize 128,key-method 2,tls-server'
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] Local Options hash (VER=V4): '1869f472'
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] Expected Remote Options hash (VER=V4): 'ce32147e'
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] Socket Buffers: R=[163840->131072] S=[163840->131072]
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] UDPv4 link local: [undef]
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] UDPv4 link remote: 22.33.44.55:1194
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] TLS: Initial packet from 22.33.44.55:1194, sid=90d39054 defcb0f7
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] VERIFY OK: depth=1, /CN=ChangeMe
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] VERIFY nsCertType ERROR: /CN=server, require nsCertType=SERVER
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] TLS Error: TLS object -> incoming plaintext read error
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] TLS Error: TLS handshake failed
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] TCP/UDP: Closing socket
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] SIGUSR1[soft,tls-error] received, process restarting
2017-08-20T23:38:36+00:00 RV50 openvpn-1[8692] Restart pause, 2 second(s)

Finally something to go on: OpenVPN client version is 2.1 and the failure is "certificate verify failed". That should be fixable.

[etaoin]

And this right here seems to be the fundamental issue: https://openvpn.net/index.php/open-sour ... .html#mitm The Sierra client, although v2.1, sets the deprecated "ns-cert-type server" when it should be "remote-cert-tls server" - is this correct? If so, since I cannot change the client configuration (not in any way I know of anyway), could I downgrade the server version to resolve the issue, and if so how far back do I need to go?

[etaoin]

Eureka!

Code: Select all

Aug 21 02:46:28 myvpn systemd[1]: Started OpenVPN connection to server.
Aug 21 02:46:28 myvpn ovpn-server[32352]: GID set to nogroup
Aug 21 02:46:28 myvpn ovpn-server[32352]: UID set to nobody
Aug 21 02:46:28 myvpn ovpn-server[32352]: UDPv4 link local (bound): [AF_INET]22.33.44.55:1194
Aug 21 02:46:28 myvpn ovpn-server[32352]: UDPv4 link remote: [undef]
Aug 21 02:46:28 myvpn ovpn-server[32352]: MULTI: multi_init called, r=256 v=256
Aug 21 02:46:28 myvpn ovpn-server[32352]: IFCONFIG POOL: base=10.8.0.2 size=252, ipv6=0
Aug 21 02:46:28 myvpn ovpn-server[32352]: IFCONFIG POOL LIST
Aug 21 02:46:28 myvpn ovpn-server[32352]: Initialization Sequence Completed
Aug 21 02:46:43 myvpn ovpn-server[32352]: 44.55.66.77:34663 TLS: Initial packet from [AF_INET]44.55.66.77:34663, sid=5c28c286 90da20da
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 CRL CHECK OK: CN=ChangeMe
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 VERIFY OK: depth=1, CN=ChangeMe
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 CRL CHECK OK: CN=raven
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 VERIFY OK: depth=0, CN=raven
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1569', remote='link-mtu 1573'
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Aug 21 02:46:46 myvpn ovpn-server[32352]: 44.55.66.77:34663 [raven] Peer Connection Initiated with [AF_INET]44.55.66.77:34663
Aug 21 02:46:46 myvpn ovpn-server[32352]: raven/44.55.66.77:34663 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Aug 21 02:46:46 myvpn ovpn-server[32352]: raven/44.55.66.77:34663 MULTI: Learn: 10.8.0.2 -> raven/44.55.66.77:34663
Aug 21 02:46:46 myvpn ovpn-server[32352]: raven/44.55.66.77:34663 MULTI: primary virtual IP for raven/44.55.66.77:34663: 10.8.0.2
Aug 21 02:46:49 myvpn ovpn-server[32352]: raven/44.55.66.77:34663 PUSH: Received control message: 'PUSH_REQUEST'
Aug 21 02:46:49 myvpn ovpn-server[32352]: raven/44.55.66.77:34663 send_push_reply(): safe_cap=940
Aug 21 02:46:49 myvpn ovpn-server[32352]: raven/44.55.66.77:34663 SENT CONTROL [raven]: 'PUSH_REPLY,dhcp-option DNS 80.68.80.24,dhcp-option DNS 80.68.80.25,redirect-gateway def1 bypass-dhcp,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0' (status=1)

Eleven days after I set out to try and get this to work, god knows how many hours I've spent on it, how many litres of coffee I've drunk, how elaborately I have been turning the air blue with profanities - but it now works. And as usual with the most painful class of computer related problems, it all came down to one single line of code: namely the addition of

Code: Select all

set_var EASYRSA_NS_SUPPORT yes

to easy-rsa's "vars" file before generating the server certfificate. Boom, Netscape extensions are now present:

Code: Select all

            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Key Usage: 
                Digital Signature, Key Encipherment
            Netscape Comment: 
                Easy-RSA Generated Certificate
            Netscape Cert Type: 
                SSL Server

As weird as it is to see a name I associate mainly with the previous century, and as p****d off as I am at Sierra for shipping crappy firmware, I'm just going to sit here for a little while and look at that "Connected" status on the RV50's admin UI, content with having beaten this thing into submission.

[conradneilands]

There is an undisclosed bug with the RV50, From my understanding the device get confused about an appropriate MTU for the cellular network and will drop packets without warning. Specially setting the MTU value to 1358 on servers and clients results in the least number of problems. I have chosen values that work, but others may know a better combination.

so in my server I add the line MTU=1358 in /etc/sysconfig/network-scripts/ifcfg-eth0

It should be noted that only udp connection are possible with the RV50 and our particular cellular carrier (Australia / Telstra) had chosen to block this port by default, we were able to get it unblocked by asking YMMV.

In my openvpn server.conf I match setting to ones I will choose in the RV50 web interface
dev tun
proto udp
port 1194
tun-mtu 1358
mssfix 1338
fragment 1300
tls-server
tls-version-min 1.0
tls-auth ta.key 0
cipher AES-256-CBC
auth sha256
comp-lzo

# If you don't enable the Split tunnel option router side connections can only be made via the vpn once established
Goto VPN Tab
Split Tunnel -> Incoming Out of Band -> Allowed
-> Outgoing Management Out of Band -> Allowed
-> Outgoing Host Out of Band -> Allowed

VPN 1 -> General
-> VPN 1 Type -> OpenVPN Tunnel
-> Peer Port -> 1194
-> Peer Identity -> server.somewhere.com
-> Encryption Algorithm -> AES-256
-> Authentication Algorithm -> SHA-256
-> Compression -> LZO
-> Load Root Certificate -> ca.crt
-> Client Certificate -> Enable
-> Load Client Certificate -> Client.crt
-> Load Client Certificate Key -> Client.key
-> Username -> Leave Blank
-> User Password -> Leave Blank
-> Additional TLS Auth -> Enable
-> Load Client TLS Key -> ta.key
VPN 1 -> Advanced
-> Tunnel-MTU -> 1358
-> MSS-Fix -> 1338
-> Fragment -> 1300
-> Allow Peer Dynamic IP -> Enable
-> Re-negotiation -> 20
-> Tunnel Restart -> 120
-> NAT -> Enable

Goto Admin Tab
Log -> Configure Logging -> VPN -> Verbosity -> Debug
-> VPN -> Display in Log -> Yes
-> Linux Syslog -> Display

[axelf911]

It looks like this problem is fixed in ALEOS 4.9.0 firmware update for RV50. They have added a --ns-cert-type drop down in the OpenVPN settings.

One question I have is, for OpenVPN server such as PFSense, am I supposed to connect using Peer to Peer (shared key) or Peer to Peer SSL/TLS ? This is for a Site to Site kind of VPN Setup.

For Peer to Peer Shared key, it doesn't look like there is any way to put in the IPv4 Remote networks in the RV50:
https://doc.pfsense.org/index.php/OpenVPN_Site_To_Site

However, for Peer to Peer (SSL/TLS), the IPv4 Remote networks are pushed to the client via an iroute:
https://doc.pfsense.org/index.php/OpenV ... _PKI_(SSL)

Is Peer to Peer (SSL/TLS) setup the only way the RV50 OpenVPN will work?

I know that the Roadwarrior setup doesn't work either.

[TinCanTech]

for Peer to Peer (SSL/TLS), the IPv4 Remote networks are pushed to the client via an iroute

--iroute is used by the server to mark which client the remote route is behind.
--iroute is not pushed to the client.

[axelf911]

Thanks for clarifying the iroute. On Pfsense Server to Pfsense Client, the configuration to make Peer to Peer (SSL/TLS) is quite clear. However, if we use the Sierra Wireless RV50 OpenVPN client, this isn't so clear.

I have gotten the PFSense Peer to Peer (SSL/TLS) setup to work and connect successfully with the RV50 OpenVPN client. However, not much is routable to the VPN tunnel it seems.

-From the RV50 Ethernet DHCP Addresses I can ping the OpenVPN Client Tunnel IP (10.0.8.2). However, I cannot ping anything else on the 10.0.8.0/24 tunnel network. I believe the PFSense OpenVPN server gets a Tunnel IP (10.0.8.1), which I cannot ping or vice versa.
-From RV50 Ethernet DHCP Addresses I cannot ping any local LAN networks on the PFSense OpenVPN server through the VPN tunnel.
-From PFSense OpenVPN server, I cannot ping any Remote LAN networks on the RV50 through the VPN tunnel.

Do I need to add a policy route? Is there any special routing or firewall settings on the RV50 that I need to add?

There doesn't seem to be a route from the Ethernet port to anything through the VPN tunnel, except for the tunnel client itself. How to force all local host traffic through the Tunnel?

Any help would be appreciated figuring out what needs to be changed on the RV50.

[axelf911]

Thanks for clarifying the iroute. On Pfsense Server to Pfsense Client, the configuration to make Peer to Peer (SSL/TLS) is quite clear. However, if we use the Sierra Wireless RV50 OpenVPN client, this isn't so clear.

I have gotten the PFSense Peer to Peer (SSL/TLS) setup to work and connect successfully with the RV50 OpenVPN client. However, not much is routable to the VPN tunnel it seems.

-From the RV50 Ethernet DHCP Addresses I can ping the OpenVPN Client Tunnel IP (10.0.8.2). However, I cannot ping anything else on the 10.0.8.0/24 tunnel network. I believe the PFSense OpenVPN server gets a Tunnel IP (10.0.8.1), which I cannot ping or vice versa.
-From RV50 Ethernet DHCP Addresses I cannot ping any local LAN networks on the PFSense OpenVPN server through the VPN tunnel.
-From PFSense OpenVPN server, I cannot ping any Remote LAN networks on the RV50 through the VPN tunnel.

Do I need to add a policy route? Is there any special routing or firewall settings on the RV50 that I need to add?

There doesn't seem to be a route from the Ethernet port to anything through the VPN tunnel, except for the tunnel client itself. How to force all local host traffic through the Tunnel?

Any help would be appreciated figuring out what needs to be changed on the RV50.

Okay I figured out the issue. The OpenVPN server has to match the RV50 OpenVPN Client advanced settings verbatim. In my case the RV50 OpenVPN advanced settings are such:

Tunnel-MTU: 1500
MSS Fix: 1400
Fragment: 1300

Thus, the PFSense OpenVPN server needs the exact same settings. Under OpenVPN server-> Advanced Configuration I added the following:

tun-mtu 1500;mssfix 1400;fragment 1300


Once I put in the above settings, voila everything is pingable!