Pepwave MAX BR1 Pro 5G OpenVPN

Product Discussion Pepwave MAX
1

I have a Pepwave MAX BR1 Pro 5G running 8.2.1 build 5018 with the OpenVPN license installed. My OpenVPN server is a pfSense appliance and it’s configured correctly. My configurations tell OpenVPN to make subnet 192.168.30.0/24 available through the tunnel and nothing else - redirect IPv4 gateway is not enabled. The Pepwave seems to ignore the pushed route for 192.168.30.0/24 and sends all traffic down the tunnel. I placed an outbound policy for 192.168.30.0/24 within the Pepwave GUI with an enforced connection to the OpenVPN interface, but that doesn’t seem to make a difference either. All traffic is still being routed through the tunnel. I only want traffic destined to 192.168.30.0/24 to be routed through the tunnel. All other traffic should default out the Cellular interface. Is this not possible? I’ve also tried this on 8.3.0 build 5211 with the same results.

pfSense Log:
peplink.vpn/X.X.X.X:7637 SENT CONTROL [USERNAME-HERE]: ‘PUSH_REPLY,route 192.168.30.0 255.255.255.0,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,route-gateway 172.16.200.1,topology subnet,ping 10,ping-restart 60,ifconfig 172.16.200.2 255.255.255.240,peer-id 0,cipher AES-256-GCM’ (status=1)

Traceroutes:
MacBook-Pro ~ % traceroute yahoo.com
traceroute to yahoo.com (74.6.231.21), 64 hops max, 52 byte packets
1 max-br1-921d (192.168.50.1) 5.025 ms 5.019 ms 4.053 ms
2 172.16.200.1 (172.16.200.1) 118.316 ms
media-router-fp74.prod.media.vip.ne1.yahoo.com (74.6.231.21) 107.593 ms
172.16.200.1 (172.16.200.1) 115.670 ms

MacBook-Pro ~ % traceroute 192.168.30.24
traceroute to 192.168.30.24 (192.168.30.24), 64 hops max, 52 byte packets
1 max-br1-921d (192.168.50.1) 10.604 ms 4.572 ms 4.053 ms
2 172.16.200.1 (172.16.200.1) 114.814 ms 108.705 ms 110.508 ms
3 192.168.30.24 (192.168.30.24) 109.386 ms 117.877 ms 110.040 ms

2

I’ve discovered a work around, however; this appears to be potentially bug related with how the Peplink handles pushed routes from the OpenVPN server and how it handles outbound policies with a source of any.

  1. If the OpenVPN server is pushing route(s) to the OpenVPN client, Peplink in this case, the Peplink should respect those prefixes and route traffic towards the tunnel only if the destination falls within the pushed route.

  2. Outbound policies set to source “any” should truly be respected as any. Since the Peplink is not respecting the pushed route from the OpenVPN server, I created an outbound policy with source “any” destination “IP Network 192.168.30.0/24” and “enforced to OpenVPN”. This should have taken any source and directed it towards the OpenVPN tunnel if the source was trying to reach an IP address that falls within 192.168.30.0/24 subnet. Unfortunately, this did not work.

  3. To manipulate traffic correctly, I had to change the source from “any” to “Clients Associated SSID” and select my SSID.

3

I ran across the same issue with source “any” not being respected. I ended up defining the subnet assigned by the BR1 Pro 5G (192.168.50.0/24) as the source in the rule and it appears to be working.

I’m sure the the method you described works just as well but it doesn’t properly route the LAN ports to the VPN when it should.