Static route to WAN interface & NAT issues on Peplink Balance 710

I appear to have static route & NAT issues with my Peplink Balance 710. As I configure a static route entry of next-hop address that is not in the same LAN segment as in Peplink Balance 710 LAN interface (the next-hop address is connected to WAN interface with proper WAN configuration), the configuration is rejected by the router. Is there any workaround to allow static route with next hop address connected with WAN interface?

As I try to specify a WAN interface for outbound address translation in Outbound Mappings, all WAN interfaces are selected by default but I am not allowed to deselect anyone of them. Is there a way that I can specify the outbound address for the NAT setting?

To route traffic to a network on a specific WAN interface you would configure an outbound policy rule under: Network> Outbound Policy.

1 Like

Hi, Ron. Thank you for your reply. May I make my query more specific for the configuration on the Balance unit. I have the following connectivity requirement:

Peplink Balance 710 WAN1 is connected with Metro Ethernet private WAN service provided by an ISP. WAN1 establishes a dozens of speedfusion tunnels with Pepwave MAX HD2 units at different remote sites. WAN2 is connected with enterprise intranet and there will be a NSS server sitting in the subnet 172.16.1.0/24.

There are servers / PCs sitting in the Peplink Balance 710 LAN and various Pepwave MAX HD2 LAN which require to synchronize network time (NTP) and virus definition update (Symantec Endpoint Protection) from the NSS Server. All Peplink Balance 710 & Pepwave Max HD2 LAN segments are subnetted to 10.0.x.0/24.

Would you review the outbound policy setting that can allow all the subnets 10.0.x.0/24 be translated to Peplink Balance 710 WAN2 IP address for outbound traffic in order to successfully synchronize the network time and virus definition update from NSS Server?

Outbound policy on Peplink Balance 710:
Service Name: NSS outbound traffic
Source: 10.0.0.0/16
Destination: 172.16.1.0/24
Protocol: Any
Algorithm: Enforced
Enforced Connection: WAN: WAN2

Do I need to enable the similar outbound policy on each Pepwave MAX HD2 units with enforced connection as PepVPN or the outbound policy on Peplink Balance 710 be advertised to all other speedfusion endpoints by OSPF?

Finally, I managed to ping the 172.16.1.0/24 from 10.0.x.0/24 in lab by defining outbound policy in Peplink Balance 710 & Pepwave MAX HD2. However, it seems the static route defined in outbound policy did not get advertised through OSPF LSA. Is this feature supported or did I miss anything? I think it would be great if the OSPF can advertise static route in outbound policy as it would reduce a lot of administrative works.

I assume your NSS server and the WAN 2 are in the same subnet? if so then you can edit the OSPF network advertising settings to include WAN2 (as well as the LAN) in the OSPF advertisement in Advanced → Firewall | OSPF & RIP2 settings page:

1 Like

The NSS Server is not in the same subnet as WAN2. There are a few hops in between.

OK, so outbound policies and static routes are different. Static routes are advertised. Outbound policies are not. So you could either connect you intranet to the LAN of the Balance 710 (perhaps in a VLAN so you can use firewall rules to control flow) and then add a static route for the 172.16.1.0/24 network which will be advertised or you can do a ‘hack’.

The ‘hack’ is to add a static route for 17.16.1.0/24 with a next hop of an IP on the current LAN subnet of the balance 710 (any IP even a made up one just not the LAN IP of the balance itself).

As its in the config as a static route it will be advertised over OSPF to the remote devices, but since you have an enforce rule outbound policy in place on the WAN2 (which has routing precedence) any traffic forwarded over the VPN for that subnet will still get routed correctly.out of WAN2.

1 Like

Thanks Martin for the detailed explanation. Since my intranet does not understand routes for 10.0.0.0 class A network (since the network has already been used internally). I will have to translate the 10.0.x.0 / 24 into some addresses that the intranet would understand. Nevermind, I would stick with the outbound policy configuration.