upnp sending M-SEARCH to wan, as opposed to lan ethernet interface
Hi; I am getting NAT detection errors: fs_cli: freeswitch@internal> nat_map status Nat Type: UNKNOWN, ExtIP: NAT port mapping enabled. freeswitch.log 2014-06-21 07:55:56.415860 [INFO] switch_nat.c:420 Scanning for NAT 2014-06-21 07:55:56.415860 [DEBUG] switch_nat.c:170 Checking for PMP 1/5 2014-06-21 07:55:56.415860 [ERR] switch_nat.c:201 Error checking for PMP [general error] 2014-06-21 07:55:56.415860 [DEBUG] switch_nat.c:425 Checking for UPnP 2014-06-21 07:56:08.415906 [INFO] switch_nat.c:441 No PMP or UPnP NAT devices detected! Network topology: LAN / eth0 = 192.168.1.1 WAN /eth1 = 192.0.xxx.xxx (dynamic IP) I have tracked this down to upnp M-SEARCH is being sent using the WAN, as opposed to LAN interface. From: autoload_configs/acl.conf.xml <list name="lan" default="allow"> <node type="deny" cidr="192.168.1.1/32"/> <!-- B.R. Changed from 192.168.42.0/24 --> <node type="allow" cidr="192.168.1.1/16"/> <!-- B.R. Changed from 192.168.42.42/32 --> </list> root@OpenWrt:/usr/local/freeswitch/conf# tcpdump -i eth1 | grep 1900: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 07:55:56.431306 IP 192-0-XXX-XXX.cpe.teksavvy.com.52711 > 239.255.255.250.1900: UDP, length 137 07:55:59.431423 IP 192-0-XXX-XXX.cpe.teksavvy.com.52711 > 239.255.255.250.1900: UDP, length 132 07:56:02.431512 IP 192-0-XXX-XXX.cpe.teksavvy.com.52711 > 239.255.255.250.1900: UDP, length 133 07:56:05.431642 IP 192-0-XXX-XXX.cpe.teksavvy.com.52711 > 239.255.255.250.1900: UDP, length 101 Questions: Q1: How do I coerece upnp to broadcast using eth0 (LAN), as opposed to eth1 (WAN)? Q2: What is the algorithm upnp uses to determine multicast interface? Thanks; Bill Ross
In your case you probably don’t even need it start with -nonat because all UPNP/NATPMP is used for is to discover your public IP. Start with -nonat /b On Jun 21, 2014, at 8:06 AM, Bill Ross <rossbcan@gmail.com> wrote:
Q1: How do I coerece upnp to broadcast using eth0 (LAN), as opposed to eth1 (WAN)? Q2: What is the algorithm upnp uses to determine multicast interface?
-- Brian West brian@freeswitch.org Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)
Hi Brian; As you probably noticed, this is running under OpenWrt (trunk, but with latest 1.2 series git c4a5042 2014-03-07 18:48:29Z 64bit) with both PMP and UPnP enabled. PMP is also broadcasting on public IP. I don't understand how your answer helps. Sure, I can use some alternative means of detecting public IP, but, my intent is to automatically open ports in firewall. I had this working on different (proto) H/W, but, with new (production) HW, the BIOS/Linux PNP Ethernet enumeration (guess) seems to have mucked things up. Intent is to get PMP . UPnP working, able to automatically punch through firewall. Thanks; Bill From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: June-21-14 11:28 AM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] upnp sending M-SEARCH to wan, as opposed to lan ethernet interface In your case you probably don't even need it start with -nonat because all UPNP/NATPMP is used for is to discover your public IP. Start with -nonat /b On Jun 21, 2014, at 8:06 AM, Bill Ross <rossbcan@gmail.com> wrote: Q1: How do I coerece upnp to broadcast using eth0 (LAN), as opposed to eth1 (WAN)? Q2: What is the algorithm upnp uses to determine multicast interface? -- Brian West brian@freeswitch.org Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)
Is this device your router? On Jun 21, 2014, at 10:46 AM, Bill Ross <rossbcan@gmail.com> wrote:
Hi Brian;
As you probably noticed, this is running under OpenWrt (trunk, but with latest 1.2 series git c4a5042 2014-03-07 18:48:29Z 64bit) with both PMP and UPnP enabled. PMP is also broadcasting on public IP.
I don’t understand how your answer helps. Sure, I can use some alternative means of detecting public IP, but, my intent is to automatically open ports in firewall.
I had this working on different (proto) H/W, but, with new (production) HW, the BIOS/Linux PNP Ethernet enumeration (guess) seems to have mucked things up.
Intent is to get PMP . UPnP working, able to automatically punch through firewall.
Thanks; Bill
-- Brian West brian@freeswitch.org Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)
Hi Brian; Yes, it is my router an integrated appliance which FS is part of. Regards; Bill From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: June-21-14 12:12 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] upnp sending M-SEARCH to wan, as opposed to lan ethernet interface Is this device your router? On Jun 21, 2014, at 10:46 AM, Bill Ross <rossbcan@gmail.com> wrote: Hi Brian; As you probably noticed, this is running under OpenWrt (trunk, but with latest 1.2 series git c4a5042 2014-03-07 18:48:29Z 64bit) with both PMP and UPnP enabled. PMP is also broadcasting on public IP. I don't understand how your answer helps. Sure, I can use some alternative means of detecting public IP, but, my intent is to automatically open ports in firewall. I had this working on different (proto) H/W, but, with new (production) HW, the BIOS/Linux PNP Ethernet enumeration (guess) seems to have mucked things up. Intent is to get PMP . UPnP working, able to automatically punch through firewall. Thanks; Bill -- Brian West brian@freeswitch.org Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)
If FreeSWITCH is on that device and has access to the WAN i.e. public network and the LAN i.e. the private network then the concept of UPNP/NATPMP doesn’t behave like you think. Its for when FreeSWITCH is BEHIND a router that has UPNP/NATPMP enabled so it can poke holes in the firewall in your case its not going to behave like that. On Windows it would behave this way, but not on linux. -- Brian West brian@freeswitch.org Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED) On Jun 21, 2014, at 12:14 PM, Bill Ross <rossbcan@gmail.com> wrote:
Hi Brian;
Yes, it is my router an integrated appliance which FS is part of.
Regards; Bill
Hi Brian; "doesn't behave like you think" OK, but, IMHO it should. Dug into this a bit deeper: caller code: src/switch_nat.c static int init_upnp(void) ... const char *multicastif = 0; const char *minissdpdpath = switch_core_get_variable("local_ip_v4"); ... devlist = upnpDiscover(3000, (multicastif?multicastif:0) , minissdpdpath, 0); callee code: libs/miniupnpc/miniupnpc.c struct UPNPDev * upnpDiscover(int delay, const char * multicastif, const char * minissdpdsock, int sameport) ... sockudp_r.sin_addr.s_addr = INADDR_ANY; ... if(multicastif) { struct in_addr mc_if; mc_if.s_addr = inet_addr(multicastif); sockudp_r.sin_addr.s_addr = mc_if.s_addr; if(setsockopt(sudp, IPPROTO_IP, IP_MULTICAST_IF, (const char *)&mc_if, sizeof(mc_if)) < 0) { PRINT_SOCKET_ERROR("setsockopt"); } } The Problem ( The IP address INADDR_ANY usage): When sending, a socket bound with INADDR_ANY binds to the default IP address, which is that of the lowest-numbered interface. In my case, it is binding to eth1, NOT the lowest-numbered interface (eth0) because eth0 has no IP address, since it is bridged to br-lan. Tried this: devlist = upnpDiscover(3000, minissdpdpath , minissdpdpath, 0); meaning it will always transmit on "local_ip_v4". I recommend this as a global change, since we always want UPnP to use lan. Results: Nat Type: UPNP, ExtIP: 192.0.XXX.XXX NAT port mapping enabled. port,proto,proto_num,sticky 5060,udp,0,0 5060,tcp,1,0 5080,udp,0,0 5080,tcp,1,0 [INFO] switch_nat.c:434 NAT detected type: upnp, ExtIP: '192.0.XXX.XXX' NAT PMP still not working and I see no requests on either interface. Will debug and advise if affects FS Regards; Bill Ross From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: June-21-14 1:54 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] upnp sending M-SEARCH to wan, as opposed to lan ethernet interface If FreeSWITCH is on that device and has access to the WAN i.e. public network and the LAN i.e. the private network then the concept of UPNP/NATPMP doesn't behave like you think. Its for when FreeSWITCH is BEHIND a router that has UPNP/NATPMP enabled so it can poke holes in the firewall in your case its not going to behave like that. On Windows it would behave this way, but not on linux. -- Brian West brian@freeswitch.org Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED) On Jun 21, 2014, at 12:14 PM, Bill Ross <rossbcan@gmail.com> wrote: Hi Brian; Yes, it is my router an integrated appliance which FS is part of. Regards; Bill
File a jira with patch and I'll review it. Sent from my iPhone
On Jun 21, 2014, at 3:54 PM, "Bill Ross" <rossbcan@gmail.com> wrote:
Hi Brian;
“doesn’t behave like you think” OK, but, IMHO it should.
Dug into this a bit deeper:
caller code: src/switch_nat.c static int init_upnp(void) ... const char *multicastif = 0; const char *minissdpdpath = switch_core_get_variable("local_ip_v4"); ... devlist = upnpDiscover(3000, (multicastif?multicastif:0) , minissdpdpath, 0);
callee code: libs/miniupnpc/miniupnpc.c struct UPNPDev * upnpDiscover(int delay, const char * multicastif, const char * minissdpdsock, int sameport) ... sockudp_r.sin_addr.s_addr = INADDR_ANY; ... if(multicastif) { struct in_addr mc_if; mc_if.s_addr = inet_addr(multicastif); sockudp_r.sin_addr.s_addr = mc_if.s_addr; if(setsockopt(sudp, IPPROTO_IP, IP_MULTICAST_IF, (const char *)&mc_if, sizeof(mc_if)) < 0) { PRINT_SOCKET_ERROR("setsockopt"); } }
The Problem ( The IP address INADDR_ANY usage): When sending, a socket bound with INADDR_ANY binds to the default IP address, which is that of the lowest-numbered interface. In my case, it is binding to eth1, NOT the lowest-numbered interface (eth0) because eth0 has no IP address, since it is bridged to br-lan.
Tried this:
devlist = upnpDiscover(3000, minissdpdpath , minissdpdpath, 0);
meaning it will always transmit on "local_ip_v4". I recommend this as a global change, since we always want UPnP to use lan.
Results:
Nat Type: UPNP, ExtIP: 192.0.XXX.XXX NAT port mapping enabled. port,proto,proto_num,sticky 5060,udp,0,0 5060,tcp,1,0 5080,udp,0,0 5080,tcp,1,0 [INFO] switch_nat.c:434 NAT detected type: upnp, ExtIP: '192.0.XXX.XXX'
NAT PMP still not working and I see no requests on either interface. Will debug and advise if affects FS
Regards; Bill Ross
From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: June-21-14 1:54 PM To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] upnp sending M-SEARCH to wan, as opposed to lan ethernet interface
If FreeSWITCH is on that device and has access to the WAN i.e. public network and the LAN i.e. the private network then the concept of UPNP/NATPMP doesn’t behave like you think. Its for when FreeSWITCH is BEHIND a router that has UPNP/NATPMP enabled so it can poke holes in the firewall in your case its not going to behave like that. On Windows it would behave this way, but not on linux.
-- Brian West brian@freeswitch.org
<image001.png>
Twitter: @FreeSWITCH , @briankwest http://www.freeswitchbook.com http://www.freeswitchcookbook.com
T: +1.918.420.9001 | F: +1.918.420.9002 | M: +1.918.424.WEST iNUM: +883 5100 1420 9001 ISN: 410*543 Skype:briankwest PGP Key: http://www.bkw.org/key.txt (AB93356707C76CED)
On Jun 21, 2014, at 12:14 PM, Bill Ross <rossbcan@gmail.com> wrote:
Hi Brian;
Yes, it is my router an integrated appliance which FS is part of.
Regards; Bill
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (2)
-
Bill Ross
-
Brian West