the PBX set on 172.16.4.10, is registering some (not all) SIP/TLS clients connected to networks 1,2 & 3 with IP address 172.16.4.254, that is the Peplink’s router/gateway IP address;
phones randomly miss calls
Not sure if something is not configured correctly in the firewall or if any special setting is required. Basically any traffic can be routed to PBX VLAN, whilst traffic initiated from PBX VLAN to Core LAN is being blocked.
could be a few issues. outbound pollicy could be sending the tarffic out the wan. or core does not know how to route back due to what networks are advertised, or local subnets exist at multiple peer locations, causing only one to work at a time.
first the order of any outbound policies. be sure “expert mode” is enabled so that you can see the position of the “pepvpn/speedfusion cloud” route step. (really not sure why they hide this)
If you have a rule ahead of that that would force traffic to wan then move that rule below it
next look at ospf/rip V2.
Router ID must be unique if you have multiple devices connected
make sure all subnets are being advertised. If they are not, then the core cannot get back to the peer vlan network.
You can also look at status=>speedfusion at both ends and make sure both ends show all the subnets at the other end
If local subnets like 10.0.100.9/24 exist at multiple locations, then use one2one NAT to assign unique subnets. You have to rutn that on first in the blue “hide the cool features” button
Hello,
we don’t use Speedfusion at all. This is a stand alone unit used to grant routing & multi WAN access.
The issue (might be a bug in the PBX console?) is local, and has nothing to do with WAN traffic.
Assuming the PBX is not showing incorrect data, clients from other local nets are listed as the Peplink’s address…
To better understand what’s going on, maybe I should inspect traffic with Wireshark, but I was looking for a quick and dirty solution
hmm. ok start with just ping tests. if you are on say the staff vlan can you ping the pbx? can the pbx ping you?
If that does not work, neither will voip
I have discovered that the issue lies in a WAN inbound access rule that is being applied also to local routed traffic, so that this is being incorrectly NATted. If this rule is disabled, IPs from other local LANs and VLANs are shown correctly.
There must be a way to prevent this from happening
