Hellp with AC68U Port Forwarding / IPtables setup

[Bionic]

Need help w/ Anveo Direct sip provider most secure setup using ASUS AC68U with Latest Merlin FW.
Per Anveo Direct, For SIP Signaling I need to allow their IP addresses to reach my IP PBX. Plus I also need to open ALL RTP ports that my IP PBX is using, to be able to receive RTP (Audio Stream) from underlying carriers. What is the most secure way to do this?

I currently have everything working by forwarding ports 5061, 5060, 5010, & 10000-20000 to the internal IP address of my IP PBX. But I know this is not the most secure way to do this... I have already noticed in my logs that the hackers are already attempting to register and make international calls...

I am using an ASUS Router with Merlin Firmware. I think if I do a custom iptable to only accept incoming traffic from Anveo Direct IP's through those ports, that would stop the hackers from reaching my IP PBX server?? If so what would be the correct syntax I should use for IPTables ? Or is there a better way for me to setup Anveo Direct with out having to do any port forwards? Anveo Direct uses direct media, with out RTP forwards will the carriers be able to connect to the stream directly?

Anveo Direct IP's
67.212.84.21,
176.9.39.206,
50.22.102.242,
50.22.101.14,
72.9.149.25,

 

[Bionic]

I think I found what I should enter in IPtables... But I don't know if this should go in the Nat-Start or Firewall-Start?

-A INPUT -s 50.22.101.14/32 -p udp -m udp --dport 5060:5069 -j ACCEPT
-A INPUT -s 67.212.84.21/32 -p udp -m udp --dport 5060:5069 -j ACCEPT
-A INPUT -s 176.9.39.206/32 -p udp -m udp --dport 5060:5069 -j ACCEPT
-A INPUT -s 72.9.149.25/32 -p udp -m udp --dport 5060:5069 -j ACCEPT
-A INPUT -s 50.22.102.242/32 -p udp -m udp --dport 5060:5069 -j ACCEPT

Also is that syntax correct? I don't see where those entries tell the traffic what server the traffic should be forwarded to..
Or Perhaps, with that config, I also need to setup the port forward pointing to the server via the GUI... ??

 

[Bionic]

I have tried to get this to work using several scripts but cant seem to figure out the correct way to do this.

I first tried this in firewall-start. I dont think it worked. I ran iptables -nL to make sure the entries were applied. I then attempted to register a remote sip phone on an outside network not specified below. The phone was able to register... It is my understanding that once I have this configured correctly I should not be able to remotely access my ip pbx from any IP other than the ones specified below...

#!/bin/sh
iptables -A INPUT -s 50.22.101.14/32 -p udp -m udp --dport 5060:5069 -j ACCEPT
iptables -A INPUT -s 67.212.84.21/32 -p udp -m udp --dport 5060:5069 -j ACCEPT
iptables -A INPUT -s 176.9.39.206/32 -p udp -m udp --dport 5060:5069 -j ACCEPT
iptables -A INPUT -s 72.9.149.25/32 -p udp -m udp --dport 5060:5069 -j ACCEPT
iptables -A INPUT -s 50.22.102.242/32 -p udp -m udp --dport 5060:5069 -j ACCEPT

I have also tried this script in nat-start

#!/bin/sh

#Allow Anveo Direct VOIP to come in!
iptables -t nat -I VSERVER 3 -p tcp -m tcp -s 50.22.101.14 --dport 5060:5069 -j DNAT --to 192.168.2.10
iptables -t nat -I VSERVER 3 -p tcp -m tcp -s 67.212.84.21 --dport 5060:5069 -j DNAT --to 192.168.2.10
iptables -t nat -I VSERVER 3 -p tcp -m tcp -s 176.9.39.206 --dport 5060:5069 -j DNAT --to 192.168.2.10
iptables -t nat -I VSERVER 3 -p tcp -m tcp -s 72.9.149.25 --dport 5060:5069 -j DNAT --to 192.168.2.10
iptables -t nat -I VSERVER 3 -p tcp -m tcp -s 50.22.102.242 --dport 5060:5069 -j DNAT --to 192.168.2.10

And another version in firewall-start

#!/bin/sh

#Allow Anveo Direct VOIP to come in!
iptables -A INPUT -s 50.22.101.14/32 -p udp -m udp --dport 5060:5069 -j ACCEPT -d 192.168.2.10
iptables -A INPUT -s 67.212.84.21/32 -p udp -m udp --dport 5060:5069 -j ACCEPT -d 192.168.2.10
iptables -A INPUT -s 176.9.39.206/32 -p udp -m udp --dport 5060:5069 -j ACCEPT -d 192.168.2.10
iptables -A INPUT -s 72.9.149.25/32 -p udp -m udp --dport 5060:5069 -j ACCEPT -d 192.168.2.10
iptables -A INPUT -s 50.22.102.242/32 -p udp -m udp --dport 5060:5069 -j ACCEPT -d 192.168.2.10

Can anyone give me a hand on this?

 

[RMerlin]

The INPUT chain is for traffic terminated on the router. You must use the FORWARD chain for anything that's terminated on a LAN client.

 

[Bionic]

The INPUT chain is for traffic terminated on the router. You must use the FORWARD chain for anything that's terminated on a LAN client.

Would you mind providing a link that explains how to use the Forward chain? I found this https://github.com/RMerl/asuswrt-merlin/wiki/Iptables-tips but after following those instructions for that script I still was able to access my PBX from an outside WAN that was not specified in the script... Thanks!

 

[ColinTaylor]

Try "VSERVER 1" instead of "VSERVER 3".

 

[Bionic]

So VSERVER would be the same as using FORWARD?
Also why do I need to use a number behind VSERVER?
example VSERVER 1, VSERVER 3, etc?
What purpose does the number after VSERVER serve?

Thanks..

 

[ColinTaylor]

There's some more information in this thread: http://www.snbforums.com/threads/iptables-vserver-chain.21207/ and lots more iptables information on the web.

Have a look at your routers current iptables configuration (because it will be different from other peoples) and then decide how you want to approach the problem.


VSERVER 1 will insert the rule at the beginning of the VSERVER chain (position 1).

VSERVER 3 will insert it at position 3. The problem with that is if you don't have existing rules in (at least) positions 1 and 2 the command will fail with an error.

 

[Bionic]

So I think I got it running!
Here is the script i put in nat-start

#!/bin/sh

#Allow Anveo Direct VOIP to come in!
logger -s -t "($(basename $0))" $$ Starting.... " $0${*:+ $*}"
iptables -t nat -I VSERVER 1 -p udp -m udp -s 50.22.101.14 --dport 5060:5069 -j DNAT --to 192.168.2.10
iptables -t nat -I VSERVER 1 -p udp -m udp -s 67.212.84.21 --dport 5060:5069 -j DNAT --to 192.168.2.10
iptables -t nat -I VSERVER 1 -p udp -m udp -s 176.9.39.206 --dport 5060:5069 -j DNAT --to 192.168.2.10
iptables -t nat -I VSERVER 1 -p udp -m udp -s 72.9.149.25 --dport 5060:5069 -j DNAT --to 192.168.2.10
iptables -t nat -I VSERVER 1 -p udp -m udp -s 50.22.102.242 --dport 5060:5069 -j DNAT --to 192.168.2.10
logger -s -t "($(basename $0))" $$ Completed.

Now when I run iptables -t nat -L -nv --line I get this in the Chain VSERVER list.

6        0     0 DNAT       udp  --  *      *       50.22.102.242        0.0.0.0                          
/0            udp dpts:5060:5069 to:192.168.2.10
7        0     0 DNAT       udp  --  *      *       72.9.149.25          0.0.0.0                                          
/0            udp dpts:5060:5069 to:192.168.2.10
8        0     0 DNAT       udp  --  *      *       176.9.39.206         0.0.0.0                                        
/0            udp dpts:5060:5069 to:192.168.2.10
9        0     0 DNAT       udp  --  *      *       67.212.84.21         0.0.0.0                                        
/0            udp dpts:5060:5069 to:192.168.2.10
10       0     0 DNAT       udp  --  *      *       50.22.101.14         0.0.0.0                                        
/0            udp dpts:5060:5069 to:192.168.2.10

Everything seems to be working, and I can no longer register a remote sip phone via port 5060 on my pbx! I will keep a eye on the logs just to verify this has killed all the hackers attempting to register and make international calls on my pbx... Thanks for you help @RMerlin & @ColinTaylor !

.

 

[RMerlin]

So VSERVER would be the same as using FORWARD?
Also why do I need to use a number behind VSERVER?
example VSERVER 1, VSERVER 3, etc?
What purpose does the number after VSERVER serve?

Thanks..

VSERVER is only used if you actually have port forwarding enabled.

 

[ColinTaylor]

VSERVER is only used if you actually have port forwarding enabled.

That doesn't appear to be quite correct. At least on my N66U running Johns fork.

The VUPNP and VSERVER chains are always present even if those features are disabled (the chains exist but are empty) and VSERVER is always called with this:

-A PREROUTING -d 81.102.xxx.yyy -j VSERVER

Port Forwarding disabled and UPnP disabled:

# Generated by iptables-save v1.3.8 on Thu Jul 30 12:41:35 2015
*nat
:PREROUTING ACCEPT [64:2928]
:POSTROUTING ACCEPT [1:425]
:OUTPUT ACCEPT [1:425]
:DNSFILTER - [0:0]
:LOCALSRV - [0:0]
:VSERVER - [0:0]
:VUPNP - [0:0]
-A PREROUTING -d 81.102.xxx.yyy -j VSERVER
-A POSTROUTING -s ! 81.102.xxx.yyy -o eth0 -j MASQUERADE
-A POSTROUTING -m mark --mark 0xd001 -j MASQUERADE
-A VSERVER -j VUPNP
COMMIT

 

[RMerlin]

That doesn't appear to be quite correct. At least on my N66U running Johns fork.

The VUPNP and VSERVER chains are always present even if those features are disabled (the chains exist but are empty) and VSERVER is always called with this:

-A PREROUTING -d 81.102.xxx.yyy -j VSERVER

Doesn't sound efficient then to have a port forward switch on the webui, yet still jump to that chain even if it's disabled - I'd call that a design flaw. I'm not sure I'd rely too heavily on this remaining the case in the future - safer to use the FORWARD chain instead.

 

[ColinTaylor]

Doesn't sound efficient then to have a port forward switch on the webui, yet still jump to that chain even if it's disabled - I'd call that a design flaw. I'm not sure I'd rely too heavily on this remaining the case in the future - safer to use the FORWARD chain instead.

Forgive my ignorance, as I'm not an expert with iptables. But wouldn't we need an entry somewhere in the NAT table to do the DNAT'ing to the destination.

So using your example for RDP in the wiki (https://github.com/RMerl/asuswrt-merlin/wiki/Iptables-tips) we would use PREROUTING instead of VSERVER 3:

iptables -t nat -I PREROUTING -p tcp -m tcp -s 10.10.10.10 --dport 3389 -j DNAT --to 192.168.1.100

We would then normally need something in the filter FORWARD chain, but there are already rules in there, like so:

-A FORWARD -i eth0 -m state --state INVALID -j DROP
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ! br0 -o eth0 -j DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT
-A FORWARD -i br0 -j ACCEPT

and I'm guessing that this existing line is all that's needed?

-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT

It looks like the wiki entry needs updating?

 

[john9527]

Doesn't sound efficient then to have a port forward switch on the webui, yet still jump to that chain even if it's disabled - I'd call that a design flaw. I'm not sure I'd rely too heavily on this remaining the case in the future - safer to use the FORWARD chain instead.

Just to add to the mystery....I looked at the fork code (and the current master), and there is code in there to bypass setting up the last VUPNP jump if upnp is not enabled. But it's either commented out or taken out with conditional compile statements. My guess is that they tried but ran into some problem.