RV016 incomming sip-requests filtering

[tapkiplus]

Good day,

i have a trouble setting up Cisco RV016 router to correctly handle SIP requests.

Here what i have:

LAN - 10.1.0.0/24

10.1.0.1 - LAN IP of RV016

10.1.0.2 - IP on NIC of software IP-PBX "3CX Phone SYSTEM"

RV016 have two WAN interfaces configured, to work with different ISP's.

I also have an VoIP service provider somewhere throught the internet, who is handlling both incomming and outgoing calls.

In order for incomming VoIP-calls to work correctly, i made some port-forwarding rules:

SIP -  all incomming connections to WAN interface and destination port 5060 are translated to the 10.1.0.2

RTP - all incommming connections to WAN interface, and destination ports 9000-9015 are translated to the 10.1.0.2

It works fine, but with one very unpleasant fact - everybody from the internet can send SIP-register requests to my IP-PBX, so in a short time i have non-stop "register" attempts from different IP's. I tried to make some Firewall Access rules, but RV016 just ignores them, when Port-Forwarding rule is applied.

In previous solution i used, there was the simple possibility to make rule to allow incoming connection on WAN port just from the single source IP-address, but, sadly, RV016 doesn't have such a feature.

Here what is the question:

What should i do? I can't leave the situation as it is, but i really don't want to change the router.

Can someone please help me with advice?

[Te-Kai Liu · Accepted solution]

Here is an example showing how to add access rules on top of a port forwarding rule.

When an Access Rule is  defined on top of a port forwarding rule (e.g. SSH service), you want to  first add a Deny rule to deny all IP addresses coming from the WAN side  and then add an Allow rule to allow specific IP address entering from  the WAN side.

Allow      SSH       WAN1     [specific IP]     [private address]

Deny      SSH       WAN1     Any                 [private address]

[tapkiplus]

Thank you, that is exactly what i was looking for.

Thanks again.