Problem getting ip phones to work with iptables.
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
Problem getting ip phones to work with iptables.
by Tom Diehl
::
Rate this Message:
Hi,
I have a network that has 1 public ip address say 72.99.50.76 The router uses nat to access various machines on the internal network of 192.168.1.0/24. They have a couple of ip phones that access their phone switch from the internet. The phone switch has an internal address of 192.168.1.12. The problem I am seeing is that when I reboot the router the ip phones refuse to connect to the phone switch for 3-4 days after the reboot. Then all of the sudden the phones sync up and all is well until we reboot the router again. I have looked at the packets with tcpdump when the phones will not connect and the packets are getting dropped on the external interface. I have a .fw file with the following iptables rules in it: # Rule 4 (NAT) # echo "Rule 4 (NAT)" # # dnat rule fone-swt -> remote fone $IPTABLES -t nat -A PREROUTING -p udp -m udp -s ! 192.168.1.0/24 -d 72.99.50.76 --dport 59101 -j DNAT --to-destination 192.168.1.12 # The above rule in fwbuilder looks like this: Orig src Orig dst orig svc translated svc translated src translated dst !192.168.1.0/24 72.99.50.76 udp 59101 Original Original 192.168.1.12 # echo "Rule 28 (global)" # # Ports fwded to the fone swt # $IPTABLES -N RULE_28 $IPTABLES -A OUTPUT -p udp -m udp -s ! 192.168.1.0/24 -d 72.99.50.76 --dport 59101 -m state --state NEW -j RULE_28 $IPTABLES -A OUTPUT -p udp -m udp -s ! 192.168.1.0/24 -d 192.168.1.12 --dport 59101 -m state --state NEW -j RULE_28 $IPTABLES -A INPUT -p udp -m udp -s ! 192.168.1.0/24 -d 72.99.50.76 --dport 59101 -m state --state NEW -j RULE_28 $IPTABLES -A FORWARD -p udp -m udp -s ! 192.168.1.0/24 -d 192.168.1.12 --dport 59101 -m state --state NEW -j RULE_28 $IPTABLES -A RULE_28 -j LOG --log-level warning --log-prefix "fwb(t-ports -> foneswt)" $IPTABLES -A RULE_28 -j ACCEPT The above rule in fwbuilder looks like this: src dst service interface direction action !192.168.1.0/24 192.168.1.12 and the ext int udp 59101 all both allow. logging is enabled. When the phones will not sync, I get the following log entries in the syslog: Nov 1 00:04:16 router.mchugh2.local kernel: fwb(t-ports -> foneswt)IN=eth0.1 OUT= MAC=00:21:29:71:25:59:00:90:1a:a0:b4:e0:08:00:45:08:00:44 SRC=71.199.26.14 DST=72.99.50.76 LEN=68 TOS=0x08 PREC=0x00 TTL=123 ID=21930 DF PROTO=UDP SPT=59147 DPT=59101 LEN=48 Once the phones sync, the above log entries go away. According to the phone vendor, all I need for the phones to work is udp 59101 natted from the outside to the internal ip address of the phone switch. We confirmed this is true when we had the phones synced up. One thing that seems strange is that a given ip phone always uses the same source port when trying to connect to the phone switch via udp 59101. I suspect that this is how the switch identifies which phone it is talking to but I could be wrong. Does anyone have any idea what I am doing wrong? Does this even make sense? Note, public ip addresses have been obscured. Regards, -- Tom Diehl tdiehl@... Spamtrap address mtd123@... ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fwbuilder-discussion mailing list Fwbuilder-discussion@... https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
|
|
Re: Problem getting ip phones to work with iptables.
by Vadim Kurland ✎
::
Rate this Message:
Tom,
first of all, you should not need to use external interface object in the policy rule 28 because NAT happens before the filtering. So the filter rule should always see internal address 192.168.1.12. If it sees external address, then NAT did not happen for whatever reason. You should not need to use !192.168.1.0/24 in the source of nat and filtering rules either, unless you have some internal machines on this net hitting the firewall trying to reach back onto the same subnet. That happens, but is unusual. Basically, I always try to simplify rules as much as possible as a first step to remove all factors that could interfere to make debugging easier. the log entry lists ingress interface eth0.1 . What is it, is it vlan ? Is this correct external interface ? the NAT rule looks correct to me. Please try iptables -L -n to check the actual loaded rules right after reboot just to see what is there really. --vk On Sun, Nov 1, 2009 at 5:44 AM, Tom Diehl <tdiehl@...> wrote: Hi, ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fwbuilder-discussion mailing list Fwbuilder-discussion@... https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
|
|
Re: Problem getting ip phones to work with iptables.
by Tom Diehl
::
Rate this Message:
Hi Vadim,
On Sun, 1 Nov 2009, Vadim Kurland wrote: > Tom, > > first of all, you should not need to use external interface object in the > policy rule 28 because NAT happens before the filtering. So the filter rule > should always see internal address 192.168.1.12. If it sees external > address, then NAT did not happen for whatever reason. I agree, I am not sure why I did that. > > You should not need to use !192.168.1.0/24 in the source of nat and > filtering rules either, unless you have some internal machines on this net > hitting the firewall trying to reach back onto the same subnet. That > happens, but is unusual. OK, I dropped those also. Both policy rule 28 and NAT rule 4 now say src any. > Basically, I always try to simplify rules as much as possible as a first > step to remove all factors that could interfere to make debugging easier. > > the log entry lists ingress interface eth0.1 . What is it, is it vlan ? Is > this correct external interface ? Yes, the box is a wrt54GL running openwrt kamikaze. > the NAT rule looks correct to me. Please try iptables -L -n to check the > actual loaded rules right after reboot just to see what is there really. Ok, now I am really confused! After making the above changes, the packets are never seeing the fwb(t-ports -> foneswt) rule according to the log entry below. Nov 1 07:49:40 router.mchugh2.local kernel: fwb(DROPnLOG) IN=eth0.1 OUT= MAC=00:21:29:71:25:59:00:90:1a:a0:b4:e0:08:00:45:08:00:44 SRC=71.199.26.14 DST=72.99.50.76 LEN=68 TOS=0x08 PREC=0x00 TTL=123 ID=21930 DF PROTO=UDP SPT=59147 DPT=59101 LEN=48 The DROPnLOG rule is a catchall rule. It simply says any, any, any, deny. It is the last rule. iptables -L -n shows the following: RULE_28 udp -- 0.0.0.0/0 192.168.1.12 udp dpt:59101 state NEW RULE_28 udp -- 0.0.0.0/0 192.168.1.12 udp dpt:59101 state NEW Since iptables -L -n does not show the NAT rule, I also ran iptables-save it shows the following: -A PREROUTING -d 72.99.50.76 -p udp -m udp --dport 59101 -j DNAT --to-destination 192.168.1.12 -A FORWARD -d 192.168.1.12 -p udp -m udp --dport 59101 -m state --state NEW -j RULE_28 -A OUTPUT -d 192.168.1.12 -p udp -m udp --dport 59101 -m state --state NEW -j RULE_28 Do you see a problem with the above? They look OK to me but iptables rules make my brain hurt. That is why I use fwb. :-) Thanks for looking into this. Regards, -- Tom Diehl tdiehl@... Spamtrap address mtd123@... > > --vk > > > On Sun, Nov 1, 2009 at 5:44 AM, Tom Diehl <tdiehl@...> wrote: > >> Hi, >> >> I have a network that has 1 public ip address say 72.99.50.76 The router >> uses >> nat to access various machines on the internal network of 192.168.1.0/24. >> They have a couple of ip phones that access their phone switch from the >> internet. The phone switch has an internal address of 192.168.1.12. >> >> The problem I am seeing is that when I reboot the router the ip phones >> refuse >> to connect to the phone switch for 3-4 days after the reboot. Then all of >> the >> sudden the phones sync up and all is well until we reboot the router again. >> >> I have looked at the packets with tcpdump when the phones will not connect >> and >> the packets are getting dropped on the external interface. >> >> I have a .fw file with the following iptables rules in it: >> >> # Rule 4 (NAT) >> # >> echo "Rule 4 (NAT)" >> # >> # dnat rule fone-swt -> remote fone >> $IPTABLES -t nat -A PREROUTING -p udp -m udp -s ! 192.168.1.0/24 -d >> 72.99.50.76 --dport 59101 -j DNAT --to-destination 192.168.1.12 >> # >> >> The above rule in fwbuilder looks like this: >> >> Orig src Orig dst orig svc translated svc >> translated src translated dst >> !192.168.1.0/24 72.99.50.76 udp 59101 Original >> Original 192.168.1.12 >> >> # >> echo "Rule 28 (global)" >> # >> # Ports fwded to the fone swt >> # >> $IPTABLES -N RULE_28 >> $IPTABLES -A OUTPUT -p udp -m udp -s ! 192.168.1.0/24 -d 72.99.50.76 >> --dport 59101 -m state --state NEW -j RULE_28 >> $IPTABLES -A OUTPUT -p udp -m udp -s ! 192.168.1.0/24 -d 192.168.1.12 >> --dport 59101 -m state --state NEW -j RULE_28 >> $IPTABLES -A INPUT -p udp -m udp -s ! 192.168.1.0/24 -d 72.99.50.76 >> --dport 59101 -m state --state NEW -j RULE_28 >> $IPTABLES -A FORWARD -p udp -m udp -s ! 192.168.1.0/24 -d 192.168.1.12 >> --dport 59101 -m state --state NEW -j RULE_28 >> $IPTABLES -A RULE_28 -j LOG --log-level warning --log-prefix "fwb(t-ports >> -> foneswt)" >> $IPTABLES -A RULE_28 -j ACCEPT >> >> The above rule in fwbuilder looks like this: >> >> src dst service interface >> direction action >> !192.168.1.0/24 192.168.1.12 and the ext int udp 59101 all >> both allow. logging is enabled. >> >> When the phones will not sync, I get the following log entries in the >> syslog: >> Nov 1 00:04:16 router.mchugh2.local kernel: fwb(t-ports -> >> foneswt)IN=eth0.1 OUT= >> MAC=00:21:29:71:25:59:00:90:1a:a0:b4:e0:08:00:45:08:00:44 SRC=71.199.26.14 >> DST=72.99.50.76 LEN=68 TOS=0x08 PREC=0x00 TTL=123 ID=21930 DF PROTO=UDP >> SPT=59147 DPT=59101 LEN=48 >> >> Once the phones sync, the above log entries go away. >> >> According to the phone vendor, all I need for the phones to work is udp >> 59101 >> natted from the outside to the internal ip address of the phone switch. We >> confirmed this is true when we had the phones synced up. One thing that >> seems >> strange is that a given ip phone always uses the same source port when >> trying >> to connect to the phone switch via udp 59101. I suspect that this is how >> the >> switch identifies which phone it is talking to but I could be wrong. >> >> Does anyone have any idea what I am doing wrong? >> >> Does this even make sense? >> >> Note, public ip addresses have been obscured. >> >> Regards, >> >> -- >> Tom Diehl tdiehl@... Spamtrap address >> mtd123@... >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Fwbuilder-discussion mailing list >> Fwbuilder-discussion@... >> https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion >> > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fwbuilder-discussion mailing list Fwbuilder-discussion@... https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
|
|
Re: Problem getting ip phones to work with iptables.
by Vadim Kurland ✎
::
Rate this Message:
Hi Tom,
On Sun, Nov 1, 2009 at 5:38 PM, Tom Diehl <tdiehl@...> wrote:
you can get nat rules using iptables -t nat -L -n If you add -v, it will also print hit counter for each rule. -A PREROUTING -d 72.99.50.76 -p udp -m udp --dport 59101 -j DNAT --to-destination 192.168.1.12 these seem to be correct. The log entry indicates that the packet never matched the NAT rule so its address never got translated and therefore the packet did not match any policy rule. Try iptables -t nat -L -n -v to see what nat rules you really have there. I assume you did check that the address 72.99.50.76 used in the rule really matches address of eth0.1, right ? --vk Do you see a problem with the above? They look OK to me but iptables rules ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fwbuilder-discussion mailing list Fwbuilder-discussion@... https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
|
|
Re: Problem getting ip phones to work with iptables.
by Tom Diehl
::
Rate this Message:
Hi Vadim,
On Sun, 1 Nov 2009, Vadim Kurland wrote: > Hi Tom, > > > On Sun, Nov 1, 2009 at 5:38 PM, Tom Diehl <tdiehl@...> wrote: > >> >> the NAT rule looks correct to me. Please try iptables -L -n to check the >>> actual loaded rules right after reboot just to see what is there really. >>> >> >> >> Ok, now I am really confused! >> >> After making the above changes, the packets are never seeing the >> fwb(t-ports -> foneswt) rule according to the log entry below. >> >> Nov 1 07:49:40 router.mchugh2.local kernel: fwb(DROPnLOG) IN=eth0.1 OUT= >> MAC=00:21:29:71:25:59:00:90:1a:a0:b4:e0:08:00:45:08:00:44 SRC=71.199.26.14 >> DST=72.99.50.76 LEN=68 TOS=0x08 PREC=0x00 TTL=123 ID=21930 DF PROTO=UDP >> SPT=59147 DPT=59101 LEN=48 >> >> The DROPnLOG rule is a catchall rule. It simply says any, any, any, deny. >> It is >> the last rule. >> >> iptables -L -n shows the following: >> >> RULE_28 udp -- 0.0.0.0/0 192.168.1.12 udp dpt:59101 >> state NEW >> RULE_28 udp -- 0.0.0.0/0 192.168.1.12 udp dpt:59101 >> state NEW >> >> Since iptables -L -n does not show the NAT rule, I also ran iptables-save >> it shows the >> following: >> >> > you can get nat rules using iptables -t nat -L -n > > If you add -v, it will also print hit counter for each rule. > > > > >> -A PREROUTING -d 72.99.50.76 -p udp -m udp --dport 59101 -j DNAT >> --to-destination 192.168.1.12 >> -A FORWARD -d 192.168.1.12 -p udp -m udp --dport 59101 -m state --state NEW >> -j RULE_28 >> -A OUTPUT -d 192.168.1.12 -p udp -m udp --dport 59101 -m state --state NEW >> -j RULE_28 >> >> > these seem to be correct. The log entry indicates that the packet never > matched the NAT rule so its address never got translated and therefore the > packet did not match any policy rule. > > Try iptables -t nat -L -n -v to see what nat rules you really have there. I > assume you did check that the address 72.99.50.76 used in the rule really > matches address of eth0.1, right ? Yes, the address is correct. I just double checked. iptables -t nat -L -n -v shows the following: root@router:~# iptables -t nat -L -n -v Chain PREROUTING (policy ACCEPT 19988 packets, 2143K bytes) pkts bytes target prot opt in out source destination 0 0 DNAT udp -- * * 0.0.0.0/0 72.99.50.76 udp dpt:59101 to:192.168.1.12 As you can see the above shows no hits, yet the log entry says we are dropping 59101. This makes no sense to me. Do you have any more ideas? I am at a loss at this point. Regards, -- Tom Diehl tdiehl@... Spamtrap address mtd123@... > > --vk > > > >> Do you see a problem with the above? They look OK to me but iptables rules >> make my brain hurt. That is why I use fwb. :-) >> >> Thanks for looking into this. >> >> >> Regards, >> >> -- >> Tom Diehl tdiehl@... Spamtrap address >> mtd123@... >> >> >> >>> --vk >>> >>> >>> On Sun, Nov 1, 2009 at 5:44 AM, Tom Diehl <tdiehl@...> wrote: >>> >>> Hi, >>>> >>>> I have a network that has 1 public ip address say 72.99.50.76 The router >>>> uses >>>> nat to access various machines on the internal network of 192.168.1.0/24 >>>> . >>>> They have a couple of ip phones that access their phone switch from the >>>> internet. The phone switch has an internal address of 192.168.1.12. >>>> >>>> The problem I am seeing is that when I reboot the router the ip phones >>>> refuse >>>> to connect to the phone switch for 3-4 days after the reboot. Then all of >>>> the >>>> sudden the phones sync up and all is well until we reboot the router >>>> again. >>>> >>>> I have looked at the packets with tcpdump when the phones will not >>>> connect >>>> and >>>> the packets are getting dropped on the external interface. >>>> >>>> I have a .fw file with the following iptables rules in it: >>>> >>>> # Rule 4 (NAT) >>>> # >>>> echo "Rule 4 (NAT)" >>>> # >>>> # dnat rule fone-swt -> remote fone >>>> $IPTABLES -t nat -A PREROUTING -p udp -m udp -s ! 192.168.1.0/24 -d >>>> 72.99.50.76 --dport 59101 -j DNAT --to-destination 192.168.1.12 >>>> # >>>> >>>> The above rule in fwbuilder looks like this: >>>> >>>> Orig src Orig dst orig svc translated svc >>>> translated src translated dst >>>> !192.168.1.0/24 72.99.50.76 udp 59101 Original >>>> Original 192.168.1.12 >>>> >>>> # >>>> echo "Rule 28 (global)" >>>> # >>>> # Ports fwded to the fone swt >>>> # >>>> $IPTABLES -N RULE_28 >>>> $IPTABLES -A OUTPUT -p udp -m udp -s ! 192.168.1.0/24 -d 72.99.50.76 >>>> --dport 59101 -m state --state NEW -j RULE_28 >>>> $IPTABLES -A OUTPUT -p udp -m udp -s ! 192.168.1.0/24 -d 192.168.1.12 >>>> --dport 59101 -m state --state NEW -j RULE_28 >>>> $IPTABLES -A INPUT -p udp -m udp -s ! 192.168.1.0/24 -d 72.99.50.76 >>>> --dport 59101 -m state --state NEW -j RULE_28 >>>> $IPTABLES -A FORWARD -p udp -m udp -s ! 192.168.1.0/24 -d >>>> 192.168.1.12 >>>> --dport 59101 -m state --state NEW -j RULE_28 >>>> $IPTABLES -A RULE_28 -j LOG --log-level warning --log-prefix >>>> "fwb(t-ports >>>> -> foneswt)" >>>> $IPTABLES -A RULE_28 -j ACCEPT >>>> >>>> The above rule in fwbuilder looks like this: >>>> >>>> src dst service interface >>>> direction action >>>> !192.168.1.0/24 192.168.1.12 and the ext int udp 59101 all >>>> both allow. logging is enabled. >>>> >>>> When the phones will not sync, I get the following log entries in the >>>> syslog: >>>> Nov 1 00:04:16 router.mchugh2.local kernel: fwb(t-ports -> >>>> foneswt)IN=eth0.1 OUT= >>>> MAC=00:21:29:71:25:59:00:90:1a:a0:b4:e0:08:00:45:08:00:44 >>>> SRC=71.199.26.14 >>>> DST=72.99.50.76 LEN=68 TOS=0x08 PREC=0x00 TTL=123 ID=21930 DF PROTO=UDP >>>> SPT=59147 DPT=59101 LEN=48 >>>> >>>> Once the phones sync, the above log entries go away. >>>> >>>> According to the phone vendor, all I need for the phones to work is udp >>>> 59101 >>>> natted from the outside to the internal ip address of the phone switch. >>>> We >>>> confirmed this is true when we had the phones synced up. One thing that >>>> seems >>>> strange is that a given ip phone always uses the same source port when >>>> trying >>>> to connect to the phone switch via udp 59101. I suspect that this is how >>>> the >>>> switch identifies which phone it is talking to but I could be wrong. >>>> >>>> Does anyone have any idea what I am doing wrong? >>>> >>>> Does this even make sense? >>>> >>>> Note, public ip addresses have been obscured. >>>> >>>> Regards, >>>> >>>> -- >>>> Tom Diehl tdiehl@... Spamtrap address >>>> mtd123@... >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>>> is the only developer event you need to attend this year. Jumpstart your >>>> developing skills, take BlackBerry mobile applications to market and stay >>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>>> http://p.sf.net/sfu/devconference >>>> _______________________________________________ >>>> Fwbuilder-discussion mailing list >>>> Fwbuilder-discussion@... >>>> https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion >>>> >>>> >>> > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fwbuilder-discussion mailing list Fwbuilder-discussion@... https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
|
|
Re: Problem getting ip phones to work with iptables.
by Vadim Kurland ✎
::
Rate this Message:
On Mon, Nov 2, 2009 at 6:07 AM, Tom Diehl <tdiehl@...> wrote:
could there be another nat rule in the PREROUTING chain that matches the same source - destination - protocol above this one? Can I see the whole list ?
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Fwbuilder-discussion mailing list Fwbuilder-discussion@... https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion |
| Free embeddable forum powered by Nabble | Forum Help |
