There is a feature standard to many routers, including Sonicwalls that Peplink does not currently have. I have a large opportunity to replace Sonicwalls with pepwaves, but need this feature.
Use case:
Packet comes across speedfusion VPN connection to an interface on the pepwave, say to port 3520
Pepwave forwards it out to a LAN interface TO the broadcast address and FROM the LAN interface IP of the pepwave.
(Why?), because a number of legacy POS systems will only accept callerid UDP packet if sent TO the broadcast address (some will not accept if unicast to each POS station), and MUST be from a local IP (since sending to broadcast from a non-local IP violates the ISO).
Current limitations:
- no source-ip translation. This part is easy. Just add a checkbox and when selected rewrite the source IP to the LAN interface IP.
- currently, port forwarding only exists for WAN interfaces and NAT-mode VPN. We cannot use NAT mode on the VPNs due to other limitations.
Suggested solution (again, matching Sonicwall) is to allow port forwarding on LAN interfaces.
Also allow port forwarding to be TO same interface as the FROM, so long as port translated so no loop.
We would then address the packet to the LAN interface IP of the pepwave.
Example:
Pepwave with a WAN and cellular, with speedfusion VPN to data center. LAN interface for POS) 10.17.100.1/24 Lan interface 2 (for phones) 10.107.2.33/28
subnet 10.17.100.0/24 is reachable over VPN from data center
Goal is to send callerid UDP packets to 10.17.100.255 on port 3520
Rule for port forwarding,
on interface 10.17.100.1 UDP port 3521
Translate TO port 3520
translate FROM ip to “interface IP”
Server port 10.17.100.255
Interface “POS network” 10.17.100.1
We send packet to 10.17.100.1 port 3521
Result is UDP packet to the broadcast IP of the POS subnet, appearing to be sent FROM (not through) the pepwave