Allow Packets With Custom iptables Rules

[TangoMike]

Hello, everyone!

I am currently trying to configure my RT-AC66U router (running Merlin's firmware version 376.48_3) to allow incoming VoIP packets through UDP port 5090. I have added the following code to the firewall-start script within /jffs/scripts/:

chmod a+rx /jffs/scripts/*
#!/bin/sh

iptables -I FORWARD 1 -p udp --dport 5090 -j ACCEPT

logger -t "$0" "'firewall-start' has been executed."

Immediately after executing this script, I attempt a test call and the router's system log shows the following entries:

Nov 22 18:55:17 firewall-start: 'firewall-start' has been executed.

Nov 22 18:56:02 kernel: DROP <4>DROP IN=eth0 OUT= MAC=/*router/* <1>SRC=108.168.254.32 DST=73.176.128.215 <1>LEN=1180 TOS=0x00 PREC=0x20 TTL=52 ID=0 DF PROTO=UDP <1>SPT=5090 DPT=41397 LEN=1160

Nov 22 18:56:02 kernel: DROP <4>DROP IN=eth0 OUT= MAC=/*router/* <1>SRC=108.168.254.32 DST=73.176.128.215 <1>LEN=1180 TOS=0x00 PREC=0x20 TTL=52 ID=0 DF PROTO=UDP <1>SPT=5090 DPT=41397 LEN=1160

Nov 22 18:56:03 kernel: DROP <4>DROP IN=eth0 OUT= MAC=/*router/* <1>SRC=108.168.254.32 DST=73.176.128.215 <1>LEN=1180 TOS=0x00 PREC=0x20 TTL=52 ID=0 DF PROTO=UDP <1>SPT=5090 DPT=41397 LEN=1160

The router is clearly still dropping these packets. If I run the following command:

 iptables -L FORWARD -v

The following is displayed:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
57 29893 ACCEPT udp -- any any anywhere anywhere udp dpt:5090

These packets should clearly be allowed. Why is this happening?

Thanks for your time!

- TangoMike

 

[john9527]

looks like upnp is mapping the port......from the log

SPT=5090 DPT=41397

Try changing your rule from --dport 5090 to --sport 5090

 

[TangoMike]

looks like upnp is mapping the port......from the log

SPT=5090 DPT=41397

Try changing your rule from --dport 5090 to --sport 5090

Thanks for your response. That seems pretty obvious after you mention it. Unfortunately, I am still getting the same results.

Does the fact that I have to execute this script manually have any effect? It does not appear to be running automatically after rebooting.

 

[john9527]

is your entry correct that these are the first lines in the script? or were you confirming that you marked it executable.

chmod a+rx /jffs/scripts/*
#!/bin/sh


Just in case, the shebang has to be the first line, and the chmod won't do anything for the script it's in.....

And....have you tried without any custom rules? If upnp really is taking over, it should automatically make the correct rules for you. Check by looking at the FUPNP chain.

iptables -L FUPNP -v

 

[TangoMike]

Those were the first lines of the script, yes. My bad. That is shameful.

I am trying these custom rules because the packets are being dropped. The FUPNP chain is completely empty.

 

[john9527]

I took another look at your logs....and I missed this first time around...

SRC=108.168.254.32 DST=73.176.128.215

Interesting destination address.....Is this a hardware box attached for the VoIP? If so, in a lot of cases they provide a pass thru to put the box between the modem and router which is the simplest hookup.

If you have it plugged into the router, a lot of these services set up a their own VPN that can complicate things (especially if you are also running a VPN service of some type, then you need to do selective routing to separate the box from your VPN).

Any of these apply?

 

[TangoMike]

The DST value belongs to my ISP (Comcast). The SRC value belongs to Republic Wireless which is my cell phone service provider. Incoming calls from that IP are being rejected by my firewall. This is causing calls to then route over cell which is undesirable in my case.

Here is a forum topic about this issue, if you are interested:
Incoming calls on WIFI only with the Asus RT-N66U

My setup is simply phone -> router -> modem -> internet.

I came here to see if I could get some expert input.

 

[john9527]

Ahh....now I understand what you are trying to accomplish.

I was hoping someone better at iptables than me would jump in (I usually end up in the brute force trial and error method to get things to work).

Anyway, based on what you need to do, I think you will need a PREROUTING rule to make it work. Think of it this way...the phone signal is making it to your router, but it has no idea of how your phone is actually connected to be able to pass it on. So you have to tell it what to do. Here's my best guess at what to try....

iptables -t nat -I PREROUTING -p udp -i eth0 -d `nvram get wan0_ifname` --sport 5090 -j DNAT --to-destination xxx.xxx.xxx.xxx

where the xxx.xxx.xxx.xxx is the ip address of your phone.

 

[TangoMike]

Thanks again for your response.

After replacing xxx.xxx.xxx.xxx with my phone's IP address, I executed the code that you provided which resulted in the following error message:

iptables v1.3.8: host/network `eth0' not found

Like my router, I have no idea what that is intended to be, so I can't move beyond this.

 

[john9527]

duh.....my fault....I told you this could be trial and error

iptables -t nat -I PREROUTING -p udp -i eth0 -d `nvram get wan0_ipaddr` --sport 5090 -j DNAT --to-destination xxx.xxx.xxx.xxx

 

[TangoMike]

I am not getting any other errors. Let's hope this fixes it . . .

I now have to wait several minutes and see if this works. I will definitely be back with the results.

 

[TangoMike]

In the meantime, I have a couple of more general questions:

I included a logger message in my script to confirm that it runs on command. How do I ensure that it runs automatically at startup? As far as I could tell, firewall-start is not running automatically. Are these scripts executed before the logger starts?

Why are we Republic Wireless users only having issues with this series of router? Do other routers keep better track of how our phones are connected to pass the signal on?

 

[john9527]

In the meantime, I have a couple of more general questions:

I included a logger message in my script to confirm that it runs on command. How do I ensure that it runs automatically at startup? As far as I could tell, firewall-start is not running automatically. Are these scripts executed before the logger starts?

No, logger should be up and you should see the msg. A couple of things to check:
- script is in /jffs/scripts directory
- script is named simply 'firewall-start' without any extension
- the script is marked executable
- the script first line is the shebang (correct previous problem)
- the script is indeed in unix format. This is probably the number one reason causing problems. The script was edited with a non-unix format editor. Easiest way to check is to open the script on the router with the vi editor and make sure everything looks right.

vi /jffs/scripts/firewall-script

enter :q to exit

Why are we Republic Wireless users only having issues with this series of router? Do other routers keep better track of how our phones are connected to pass the signal on?

This is a good question. I did a little searching to try and understand things, and didn't find anything else similar, which baffles me. And I really don't have a point of reference as this is my first attempt at helping on this type of setup.

But one thought just occured to me.....are you sure you have upnp enabled on the router? It's on the WAN/Internet Connection page under Basic Configuration.

 

[TangoMike]

All of those things you mentioned about the script are already true. The script has universal read/write/executable access (-rwxrwxrwx) and I have been using vi to create/edit the script.

I do have UPNP enabled already.

Another question: how should this script handle multiple phones? Should I add the PREROUTING rule for each IP address? Does that line of code differentiate between incoming calls for different IP addresses?

Thanks again!

 

[john9527]

I did a little more searching and found the following....

http://republic-wireless.wikia.com/wiki/Republic_Wireless_and_Your_Wi-Fi_Router

According to this, the ASUS routers should work just fine (there are even some mentions of the Merlin firmware). So, we should probably start looking at some other things.

A couple of things to try as far as the router setup (in order).....

On LAN/Switch control, try disabling NAT Acceleration
On WAN/NAT Passthru tab, try toggling the state for SIP Passthrough
On LAN/IPTV, try toggling the the two IGMP options
On Wireless/Professional, try toggling IGMP Snooping

Edit: Just a thought, you may get a wider response opening a thread of 'Republic Wireless problem with ASUS router'

 

[TangoMike]

After taking quite a bit of time to test the various settings mentioned above, I have concluded that they have no effect on the issue. My family member's phones were still not receiving calls. My phone, however, continued to receive calls correctly because I left the iptables rule in place. I do believe that this is the solution that I need.

To move on, I need to know the following:

how should this script handle multiple phones? Should I add the PREROUTING rule for each IP address? Does that line of code differentiate between incoming calls for different IP addresses?

I am going to go ahead and add a rule for each phone to see what changes result.

 

[sinshiva]

this is the second thread here in regards to republic wireless. not sure if the first guy ever had any success. an aside, port forwarding shouldn't be necessary. i'd try using rules with both sport and dport on the forward chain;

ie;

iptables -I FORWARD -p udp --dport 5060:5091 -j ACCEPT
iptables -I FORWARD -p udp --sport 5060:5091 -j ACCEPT
iptables -I FORWARD -p tcp --dport 5060:5091 -j ACCEPT
iptables -I FORWARD -p tcp --sport 5060:5091 -j ACCEPT

using 5060:5091 and udp/tcp to cover all your bases. then i might try playing with tcp and udp timeout settings.

good luck.

[edit/] i feel i should mention; i've no problems using t-mobile 'wifi calling' without adding rules or enabling sip passthrough. my sister also uses another service here without issues; i *think* virgin mobile or something. have had t-mobile wifi calling working without error since before the t-mobile edition ac68u was released, too. UPnP disabled.

 

[TangoMike]

Thanks for your input. I replaced the port forwarding rules with what you provided and I have the same issue.

 

[john9527]

After taking quite a bit of time to test the various settings mentioned above, I have concluded that they have no effect on the issue. My family member's phones were still not receiving calls. My phone, however, continued to receive calls correctly because I left the iptables rule in place. I do believe that this is the solution that I need.

To move on, I need to know the following:

I am going to go ahead and add a rule for each phone to see what changes result.

Ah....so the PREROUTING rule worked. Now the bad news, it won't work for multiple phones.

To see if we can come up with something for multiple phones, we need to see it the destination port is static or changes (I'm afraid it's going to be changing but we can check)

Call one of the other phones you want to add and capture the same info you did as in the beginning, like this

Nov 22 18:56:03 kernel: DROP <4>DROP IN=eth0 OUT= MAC=/*router/* <1>SRC=108.168.254.32 DST=73.176.128.215 <1>LEN=1180 TOS=0x00 PREC=0x20 TTL=52 ID=0 DF PROTO=UDP <1>SPT=5090 DPT=41397 LEN=1160

Call several times and see if the DPT changes or is the same. Also, when you call one of the other phones, does your phone ring?

But I keep coming back to this all should be handled by upnp. Are there any userids on the phone setups that reference Republic? Any options on the phone under the wireless setup referencing upnp?

 

[TangoMike]

The destination port for each phone is definitely dynamic. For example, here are a few values: 41397, 46971, 53815, and 53815.

Whenever I call the other phones, as long as they've been connected for some time, the calls are connected to the correct phone over cell. I've never received a call that was not intended for me with the PREROUTING rule enabled.

There is nothing regarding UPnP in the "Advanced WiFi" settings within Android or anywhere else that I've seen. Also, I'm not exactly sure what UserIDs on our phones would be.