Hi List, After having solved my logging problem i am still struggling with our voip adapter. I have basically the same setup like in the actual postings that are flooding around here (http://sourceforge.net/mailarchive/forum.php?thread_name=450EB7580E6AE7469F8826BFBF09BAB60889F1%40earwax.uent.com&forum_name=shorewall-users) Short sum up. Internet (EXT) -> linux router with shorewall (FW) -> LAN (INT) -> VOIP Adapter Now the problem is that the voip adapter cannot connect to the sip provider. First of all, this is what i can exclude. The VOIP works and is setup right, it works at my home lan and it works in the office directly connected the internet without firewall. Shorewall works too very fine and did everything as should up to now. Route int to ext and let pass some connections from ext to int like imap, http and so on. I tried several settings within shorewall now, none with success and i am a bit desperate now. Attached is the actual shorewall dump, i hope somebody can help me. Ah, i almost forgot that. I logged the shorewall traffic, but all i could see were packets getting out of the net to proxy.live.sipgate.de, but none ever returned. The i started tshark and watched the internet connected interface. There i always get these three messages: 462.312900 77.20.237.113 -> 217.10.68.147 SIP Request: REGISTER sip:sipgate.de 466.312000 77.20.237.113 -> 217.10.68.147 IP Fragmented IP protocol (proto=UDP 0x11, off=0) 466.312026 77.20.237.113 -> 217.10.68.147 SIP Request: REGISTER sip:sipgate.de Googling didnt help me either. I also setup the voip adapter to log error messages to my server and there i get the following messages: Sep 23 13:11:41 192.168.15.9 001D7ED5812B System started: ip@192.168.15.9, reboot reason:H0 Sep 23 13:11:41 192.168.15.9 001D7ED5812B System started: ip@192.168.15.9, reboot reason:H0 Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Proxy:sipgate.de Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Proxy:sipgate.de Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Outbound Proxy:proxy.live.sipgate.de Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Outbound Proxy:proxy.live.sipgate.de Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Proxy: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Proxy: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Outbound Proxy: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Outbound Proxy: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule:/init.cfg Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule:/init.cfg Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule B: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule B: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule C: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule C: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule D: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule D: Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Preferred Codec:G711u Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Preferred Codec:G711u Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Preferred Codec:G711u Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Preferred Codec:G711u Sep 23 13:11:41 192.168.15.9 001D7ED5812B RTP Packet Size:0.020 Sep 23 13:11:41 192.168.15.9 001D7ED5812B RTP Packet Size:0.020 Sep 23 13:11:41 192.168.15.9 001D7ED5812B [0]Reg Addr Change(0) 0:0->d90a4493:5060 Sep 23 13:11:56 192.168.15.9 last message repeated 3 times Sep 23 13:14:58 192.168.15.9 001D7ED5812B [0]Reg Addr Change(0) 0:5060->d90a4493:5060 Sep 23 13:15:03 192.168.15.9 last message repeated 3 times Thanks in Advance Sven ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
On 9/23/09 6:09 AM, "Sven Richter" <sveri80@googlemail.com> wrote:> Hi List, > > After having solved my logging problem i am still struggling with our > voip adapter. I have basically the same setup like in the actual > postings that are flooding around here > (http://sourceforge.net/mailarchive/forum.php?thread_name=450EB7580E6AE7469F88 > 26BFBF09BAB60889F1%40earwax.uent.com&forum_name=shorewall-users) > > Short sum up. > Internet (EXT) -> linux router with shorewall (FW) -> LAN (INT) -> VOIP > Adapter > > Now the problem is that the voip adapter cannot connect to the sip provider. > > First of all, this is what i can exclude. > The VOIP works and is setup right, it works at my home lan and it > works in the office directly connected the internet without firewall. > Shorewall works too very fine and did everything as should up to now. > Route int to ext and let pass some connections from ext to int like > imap, http and so on. > > I tried several settings within shorewall now, none with success and i > am a bit desperate now. > > Attached is the actual shorewall dump, i hope somebody can help me. > > Ah, i almost forgot that. > > I logged the shorewall traffic, but all i could see were packets > getting out of the net to proxy.live.sipgate.de, but none ever > returned. > The i started tshark and watched the internet connected interface. > There i always get these three messages: > 462.312900 77.20.237.113 -> 217.10.68.147 SIP Request: REGISTER sip:sipgate.de > 466.312000 77.20.237.113 -> 217.10.68.147 IP Fragmented IP protocol > (proto=UDP 0x11, off=0) > 466.312026 77.20.237.113 -> 217.10.68.147 SIP Request: REGISTER sip:sipgate.de > > Googling didnt help me either. > > I also setup the voip adapter to log error messages to my server and > there i get the following messages: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B System started: > ip@192.168.15.9, reboot reason:H0 > Sep 23 13:11:41 192.168.15.9 001D7ED5812B System started: > ip@192.168.15.9, reboot reason:H0 > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Proxy:sipgate.de > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Proxy:sipgate.de > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Outbound > Proxy:proxy.live.sipgate.de > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Outbound > Proxy:proxy.live.sipgate.de > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Proxy: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Proxy: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Outbound Proxy: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Outbound Proxy: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule:/init.cfg > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule:/init.cfg > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule B: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule B: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule C: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule C: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule D: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule D: > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Preferred Codec:G711u > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Preferred Codec:G711u > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Preferred Codec:G711u > Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Preferred Codec:G711u > Sep 23 13:11:41 192.168.15.9 001D7ED5812B RTP Packet Size:0.020 > Sep 23 13:11:41 192.168.15.9 001D7ED5812B RTP Packet Size:0.020 > Sep 23 13:11:41 192.168.15.9 001D7ED5812B [0]Reg Addr Change(0) > 0:0->d90a4493:5060 > Sep 23 13:11:56 192.168.15.9 last message repeated 3 times > Sep 23 13:14:58 192.168.15.9 001D7ED5812B [0]Reg Addr Change(0) > 0:5060->d90a4493:5060 > Sep 23 13:15:03 192.168.15.9 last message repeated 3 times > > > Thanks in Advance > Sven > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® 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/devconf > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-usersI am far from an expert, however, even without reading your shorewall dump, I can tell you that SIP is incredibly finicky when it comes to NAT. Although this url refers to Asterisk (open-source PBX), it is very applicable to issues involving SIP and NAT. http://www.voip-info.org/wiki/view/Asterisk+SIP+NAT+solutions I''d assume in your case the reason you are getting no returns from your sip provider to your VOIP adapter behind the shorewall is because the sip server is responding to the internal address of the SIP adapter. You''ll need to use a SIP proxy, STUN, or one-to-one NAT''ing and / or port forwarding to get it all to work properly. Some VOIP adapters have the ability to enter a private IP AND a public IP so that the packets are properly forwarded upstream. -- Keith Mitchell CTO Productivity Associates, Inc. 5625 Ruffin Rd STE 220 San Diego, CA 92123 858-495-3528 (Work) 858-495-3540 (Fax) ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
Thank you for the hints. At least they lead me to a solution. I found a website where settings for VOIP Adapters are explained, meaning which one should be used where and when: http://spakonfig.de/ And i did a firmware update with my adapter. I cannot say which action at least caused the adapter to get online, but it does work now. So it was not the fault of shorewall like i thought but some of this weird settings in the voip adapter. Thanks all who helped. Greetings Sven On Wed, Sep 23, 2009 at 10:06 PM, Keith Mitchell <keithm@paisd.com> wrote:> > On 9/23/09 6:09 AM, "Sven Richter" <sveri80@googlemail.com> wrote: > >> Hi List, >> >> After having solved my logging problem i am still struggling with our >> voip adapter. I have basically the same setup like in the actual >> postings that are flooding around here >> (http://sourceforge.net/mailarchive/forum.php?thread_name=450EB7580E6AE7469F88 >> 26BFBF09BAB60889F1%40earwax.uent.com&forum_name=shorewall-users) >> >> Short sum up. >> Internet (EXT) -> linux router with shorewall (FW) -> LAN (INT) -> VOIP >> Adapter >> >> Now the problem is that the voip adapter cannot connect to the sip provider. >> >> First of all, this is what i can exclude. >> The VOIP works and is setup right, it works at my home lan and it >> works in the office directly connected the internet without firewall. >> Shorewall works too very fine and did everything as should up to now. >> Route int to ext and let pass some connections from ext to int like >> imap, http and so on. >> >> I tried several settings within shorewall now, none with success and i >> am a bit desperate now. >> >> Attached is the actual shorewall dump, i hope somebody can help me. >> >> Ah, i almost forgot that. >> >> I logged the shorewall traffic, but all i could see were packets >> getting out of the net to proxy.live.sipgate.de, but none ever >> returned. >> The i started tshark and watched the internet connected interface. >> There i always get these three messages: >> 462.312900 77.20.237.113 -> 217.10.68.147 SIP Request: REGISTER sip:sipgate.de >> 466.312000 77.20.237.113 -> 217.10.68.147 IP Fragmented IP protocol >> (proto=UDP 0x11, off=0) >> 466.312026 77.20.237.113 -> 217.10.68.147 SIP Request: REGISTER sip:sipgate.de >> >> Googling didnt help me either. >> >> I also setup the voip adapter to log error messages to my server and >> there i get the following messages: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B System started: >> ip@192.168.15.9, reboot reason:H0 >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B System started: >> ip@192.168.15.9, reboot reason:H0 >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Proxy:sipgate.de >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Proxy:sipgate.de >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Outbound >> Proxy:proxy.live.sipgate.de >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Outbound >> Proxy:proxy.live.sipgate.de >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Proxy: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Proxy: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Outbound Proxy: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Outbound Proxy: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule:/init.cfg >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule:/init.cfg >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule B: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule B: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule C: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule C: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule D: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule D: >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Preferred Codec:G711u >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Preferred Codec:G711u >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Preferred Codec:G711u >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Preferred Codec:G711u >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B RTP Packet Size:0.020 >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B RTP Packet Size:0.020 >> Sep 23 13:11:41 192.168.15.9 001D7ED5812B [0]Reg Addr Change(0) >> 0:0->d90a4493:5060 >> Sep 23 13:11:56 192.168.15.9 last message repeated 3 times >> Sep 23 13:14:58 192.168.15.9 001D7ED5812B [0]Reg Addr Change(0) >> 0:5060->d90a4493:5060 >> Sep 23 13:15:03 192.168.15.9 last message repeated 3 times >> >> >> Thanks in Advance >> Sven >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® 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/devconf >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users > > I am far from an expert, however, even without reading your shorewall dump, > I can tell you that SIP is incredibly finicky when it comes to NAT. > > Although this url refers to Asterisk (open-source PBX), it is very > applicable to issues involving SIP and NAT. > > http://www.voip-info.org/wiki/view/Asterisk+SIP+NAT+solutions > > I''d assume in your case the reason you are getting no returns from your sip > provider to your VOIP adapter behind the shorewall is because the sip server > is responding to the internal address of the SIP adapter. You''ll need to > use a SIP proxy, STUN, or one-to-one NAT''ing and / or port forwarding to get > it all to work properly. > > Some VOIP adapters have the ability to enter a private IP AND a public IP so > that the packets are properly forwarded upstream. > > > -- > Keith Mitchell > CTO > Productivity Associates, Inc. > 5625 Ruffin Rd STE 220 > San Diego, CA 92123 > 858-495-3528 (Work) > 858-495-3540 (Fax) > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® 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/devconf > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
Hm, i was a bit to early to be happy. I can register with my account, but that is almost all i can do :( I also can call the phone at the voip adapter, but, thats it. If i take up the call i dont hear anything and if i try to call from the phone at the adapter i never hear it ringing. That is sad, really sad. What seems suspicious to me is that the overview of the adapter shows me receiving a lot of sip messages and bytes, but the counter for rtp packages and bytes always remains zero. Again seems like a NAT problem? Is there a way to allow all traffic to that one adapter with shorewall, so to say to a fixed ip? Without interupting anything? Greetings Sven On Thu, Sep 24, 2009 at 10:00 AM, Sven Richter <sveri80@googlemail.com> wrote:> Thank you for the hints. At least they lead me to a solution. > > I found a website where settings for VOIP Adapters are explained, > meaning which one should be used where and when: > http://spakonfig.de/ > > And i did a firmware update with my adapter. I cannot say which action > at least caused the adapter to get online, but it does work now. > So it was not the fault of shorewall like i thought but some of this > weird settings in the voip adapter. > > Thanks all who helped. > > > Greetings > Sven > > > On Wed, Sep 23, 2009 at 10:06 PM, Keith Mitchell <keithm@paisd.com> wrote: >> >> On 9/23/09 6:09 AM, "Sven Richter" <sveri80@googlemail.com> wrote: >> >>> Hi List, >>> >>> After having solved my logging problem i am still struggling with our >>> voip adapter. I have basically the same setup like in the actual >>> postings that are flooding around here >>> (http://sourceforge.net/mailarchive/forum.php?thread_name=450EB7580E6AE7469F88 >>> 26BFBF09BAB60889F1%40earwax.uent.com&forum_name=shorewall-users) >>> >>> Short sum up. >>> Internet (EXT) -> linux router with shorewall (FW) -> LAN (INT) -> VOIP >>> Adapter >>> >>> Now the problem is that the voip adapter cannot connect to the sip provider. >>> >>> First of all, this is what i can exclude. >>> The VOIP works and is setup right, it works at my home lan and it >>> works in the office directly connected the internet without firewall. >>> Shorewall works too very fine and did everything as should up to now. >>> Route int to ext and let pass some connections from ext to int like >>> imap, http and so on. >>> >>> I tried several settings within shorewall now, none with success and i >>> am a bit desperate now. >>> >>> Attached is the actual shorewall dump, i hope somebody can help me. >>> >>> Ah, i almost forgot that. >>> >>> I logged the shorewall traffic, but all i could see were packets >>> getting out of the net to proxy.live.sipgate.de, but none ever >>> returned. >>> The i started tshark and watched the internet connected interface. >>> There i always get these three messages: >>> 462.312900 77.20.237.113 -> 217.10.68.147 SIP Request: REGISTER sip:sipgate.de >>> 466.312000 77.20.237.113 -> 217.10.68.147 IP Fragmented IP protocol >>> (proto=UDP 0x11, off=0) >>> 466.312026 77.20.237.113 -> 217.10.68.147 SIP Request: REGISTER sip:sipgate.de >>> >>> Googling didnt help me either. >>> >>> I also setup the voip adapter to log error messages to my server and >>> there i get the following messages: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B System started: >>> ip@192.168.15.9, reboot reason:H0 >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B System started: >>> ip@192.168.15.9, reboot reason:H0 >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Proxy:sipgate.de >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Proxy:sipgate.de >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Outbound >>> Proxy:proxy.live.sipgate.de >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Outbound >>> Proxy:proxy.live.sipgate.de >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Proxy: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Proxy: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Outbound Proxy: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Outbound Proxy: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule:/init.cfg >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule:/init.cfg >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule B: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule B: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule C: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule C: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule D: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Profile Rule D: >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Preferred Codec:G711u >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 1 Preferred Codec:G711u >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Preferred Codec:G711u >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B Line 2 Preferred Codec:G711u >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B RTP Packet Size:0.020 >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B RTP Packet Size:0.020 >>> Sep 23 13:11:41 192.168.15.9 001D7ED5812B [0]Reg Addr Change(0) >>> 0:0->d90a4493:5060 >>> Sep 23 13:11:56 192.168.15.9 last message repeated 3 times >>> Sep 23 13:14:58 192.168.15.9 001D7ED5812B [0]Reg Addr Change(0) >>> 0:5060->d90a4493:5060 >>> Sep 23 13:15:03 192.168.15.9 last message repeated 3 times >>> >>> >>> Thanks in Advance >>> Sven >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® 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/devconf >>> _______________________________________________ >>> Shorewall-users mailing list >>> Shorewall-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >> I am far from an expert, however, even without reading your shorewall dump, >> I can tell you that SIP is incredibly finicky when it comes to NAT. >> >> Although this url refers to Asterisk (open-source PBX), it is very >> applicable to issues involving SIP and NAT. >> >> http://www.voip-info.org/wiki/view/Asterisk+SIP+NAT+solutions >> >> I''d assume in your case the reason you are getting no returns from your sip >> provider to your VOIP adapter behind the shorewall is because the sip server >> is responding to the internal address of the SIP adapter. You''ll need to >> use a SIP proxy, STUN, or one-to-one NAT''ing and / or port forwarding to get >> it all to work properly. >> >> Some VOIP adapters have the ability to enter a private IP AND a public IP so >> that the packets are properly forwarded upstream. >> >> >> -- >> Keith Mitchell >> CTO >> Productivity Associates, Inc. >> 5625 Ruffin Rd STE 220 >> San Diego, CA 92123 >> 858-495-3528 (Work) >> 858-495-3540 (Fax) >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® 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/devconf >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
Sven Richter wrote:> Hm, i was a bit to early to be happy. > I can register with my account, but that is almost all i can do :( > I also can call the phone at the voip adapter, but, thats it. > > If i take up the call i dont hear anything and if i try to call from > the phone at the adapter i never hear it ringing. > That is sad, really sad. > > What seems suspicious to me is that the overview of the adapter shows > me receiving a lot of sip messages and bytes, but the counter for rtp > packages and bytes always remains zero. Again seems like a NAT > problem?If so, your log show be showing dropped rtp packets.> > Is there a way to allow all traffic to that one adapter with > shorewall, so to say to a fixed ip? > Without interupting anything?a) Remove any DNAT rules that you have for the adapter. b) Change any remaining DNAT rules with ''net'' as the SOURCE to DNAT+ rules. c) Change any REDIRECT rules with ''net'' as the SOURCE to REDIRECT+ rules. d) Change any ACCEPT rules with ''net'' as the SOURCE to ACCEPT+ rules. e) At the bottom of your rules file, add: DNAT net loc:<adapter ip> Before you do that though, you might have a look at Shorewall FAQ 77. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
Sven Richter wrote:>I can register with my account, but that is almost all i can do :( >I also can call the phone at the voip adapter, but, thats it. > >If i take up the call i dont hear anything and if i try to call from >the phone at the adapter i never hear it ringing. >That is sad, really sad. > >What seems suspicious to me is that the overview of the adapter shows >me receiving a lot of sip messages and bytes, but the counter for rtp >packages and bytes always remains zero. Again seems like a NAT >problem? > >Is there a way to allow all traffic to that one adapter with >shorewall, so to say to a fixed ip? >Without interupting anything?<rant>Welcome to the world of NAT - a completely and utterly broken network by design. I want to throttle anyone who tries to tell me that it not broken or is a good idea - it''s bodge that breaks lots of stuff and has significantly contributed to the delays in getting IPv6 going mainstream (because clueless f***wits think NAT is a fix for lack of address space in IPv4). It breaks both rules of IP addressing - IP address must be globally unique, and IP addresses must be globally routable.</rant> Here are the steps you need to take to get SIP working. 1) Make sure any SIP helper (or Application Level Gateway (ALG)) is disabled in your router. These try to help, but as often as not simply break things even more. 2) Check the label on the front of your NAT gateway/router. If it says Zyxel, bin it and save yourself some headaches. Zyxel take NAT to new levels of broken that I''d previously considered unreachable. Now comes the fun bit ! If your VoIP provider has a NAT proxy then use it. These simply take your SIP traffic, ignore the IP address and port info in them, substitute the actual address/port seen in the packet header, and logs into the SIP server on your behalf. For RTP traffic, again they look at the actual address/port seen in the packet headers you send out, and send their end of the conversation to that instead of what your SIP device says. Trust me, for a single device this is by far the simplest and most reliable way to do it. If this isn''t available then continue : 3) Check what RTP ports your device uses - it should have a range defined in the config somewhere. Configure your router to allow inbound traffic to these udp ports and forward it to your device. Also do the same with SIP (port 5060 on udp, or possibly on tcp as well). If you have a fixed address, then look at the SIP device and find a setting where you can tell it what it''s outside address is. Put your fixed public address in there and your device will use that in all it''s messages instead of it''s actual (internal) network address. Failing that, configure your device to use STUN (Simple Traversal of UDP through NAT). This feature will talk to an external STUN server to probe the network (with help from the external server) and discover what sort of NAT is in use and what your public IP is. Why all this hassle ? Embedded in the SIP messages are IP address/port pairs. When you set up a call, one ends says "I have a call for you, you should send the RTP stream to address:port". The other end replies "OK, I''m going to use address:port for my end". Each end then sends the RTP data packets to the address:port specified - and if that happens to be a non-routable 192.168.x.y address instead of a real address then that half of the conversation ''just disappears''. Part of the reason it''s done this way is that the SIP ''exchange'' device doesn''t have to route the packets - it''s perfectly possible to have the two end devices send the RTP packets directly to each other while the SIP exchange does nothing but pass control messages (ie setup and end the call). NAT just completely f***s this up, and it is NOT possible to configure an ALG that can handle all possible permutations of f**k up. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
Hi Simon, thank you for your long and explaining email. I was afraid that i''ll face someday a problem like that. A nat problem. I read some things about the specification and about how f**** up it is, but never cared. However, my router is a linux box with shorewall. I "natted" all traffic (ports 5060 and 16384-16482) to my adapter, but that wont do the trick. Looking at the logs i think i see the problem: Sep 24 18:29:39 192.168.15.9 SIP/2.0 200 OK^M Record-Route: <sip:217.10.68.147;lr=on;ftag=65bbf9ec3a01a2cco0>^M Via: SIP/2.0/UDP 192.168.15.9:5060;branch=z9hG4bK-201f4727;rport=5060^M From: Richter <sip:1666030e0@sipgate.de>;tag=65bbf9ec3a01a2cco0^M To: <sip:217.10.68.147>;tag=efae1b206a1df22b5fbc395b5a747d13.8532^M Call-ID: 630bee6c-a79e384c@192.168.15.9^M CSeq: 79 NOTIFY^M Content-Length: 0^M ^M There at the and i see the internal ip and not the external one. But, my adapter has both abilities, the one to use the stun server and the one to enter an external ip (i dont have a fixed one, but our dynamic ip only changes all few weeks). I tried both options, but neither worked. Here is the log with stun server enabled: Sep 24 18:31:51 192.168.15.9 [0]On Hook Sep 24 18:31:53 192.168.15.9 [0]Off Hook Sep 24 18:31:58 192.168.15.9 [5060]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [16444]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [16445]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [16446]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [16447]STUN trying 0 Sep 24 18:31:58 192.168.15.9 [0:0]CC:STUN OK:c0a80f09->4d14ed71, 5060->5060 16444->16444 Sep 24 18:31:58 192.168.15.9 Calling:016099107562@sipgate.de:0 Sep 24 18:31:58 192.168.15.9 [0:0]AUD ALLOC CALL (port=16444) Sep 24 18:31:58 192.168.15.9 [0:0]RTP Rx Up Sep 24 18:31:58 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:58 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:58 192.168.15.9 INVITE sip:016099107562@sipgate.de SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-5fa7a07e;rport^M From: Richter <sip:1666030e0@sipgate.de>;tag=a1e57602f246d1deo0^M To: <sip:016099107562@sipgate.de>^M Call-ID: b85693d2-522bce4e@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 442^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 93561 93561 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16444 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:31:58 192.168.15.9 Sep 24 18:31:58 192.168.15.9 Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:59 192.168.15.9 INVITE sip:016099107562@sipgate.de SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-5fa7a07e;rport^M From: Richter <sip:1666030e0@sipgate.de>;tag=a1e57602f246d1deo0^M To: <sip:016099107562@sipgate.de>^M Call-ID: b85693d2-522bce4e@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 442^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 93561 93561 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16444 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:31:59 192.168.15.9 Sep 24 18:31:59 192.168.15.9 Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:31:59 192.168.15.9 NOTIFY sip:217.10.68.147 SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-6d7849d0;rport^M From: Richter <sip:1666030e0@sipgate.de>;tag=65bbf9ec3a01a2cco0^M To: <sip:217.10.68.147>^M Call-ID: 630bee6c-a79e384c@192.168.15.9^M CSeq: 93 NOTIFY^M Max-Forwards: 70^M Event: keep-alive^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 0^M ^M Sep 24 18:49:29 192.168.15.9 Sep 24 18:49:29 192.168.15.9 Sep 24 18:49:29 192.168.15.9 [0:5060]<<217.10.68.147:5060 Sep 24 18:49:29 192.168.15.9 [0:5060]<<217.10.68.147:5060 Sep 24 18:49:29 192.168.15.9 SIP/2.0 200 OK^M Record-Route: <sip:217.10.68.147;lr=on;ftag=36bb74bb43384db3o0>^M Via: SIP/2.0/UDP 192.168.15.9:5060;branch=z9hG4bK-c62ea4f2;rport=5060^M From: Richter <sip:1666030e0@sipgate.de>;tag=36bb74bb43384db3o0^M To: <sip:217.10.68.147>;tag=efae1b206a1df22b5fbc395b5a747d13.d026^M Call-ID: 724726db-8a434213@192.168.15.9^M CSeq: 3 NOTIFY^M Content-Length: 0^M ^M Sep 24 18:49:29 192.168.15.9 [messages repeating] Sep 24 18:32:30 192.168.15.9 Sep 24 18:32:30 192.168.15.9 Sep 24 18:32:30 192.168.15.9 [0:0]AUD Rel Call Sep 24 18:32:30 192.168.15.9 CC:Failed w/ Calling Sep 24 18:32:30 192.168.15.9 Sess Terminated And here is the one with the external ip enabled: Sep 24 18:51:29 192.168.15.9 [0]On Hook Sep 24 18:51:30 192.168.15.9 [0]Off Hook Sep 24 18:51:30 192.168.15.9 [0]CID interrupted Sep 24 18:51:35 192.168.15.9 Calling:03419612642@sipgate.de:0 Sep 24 18:51:35 192.168.15.9 [0:0]AUD ALLOC CALL (port=16410) Sep 24 18:51:35 192.168.15.9 [0:0]RTP Rx Up Sep 24 18:51:35 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:35 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:35 192.168.15.9 INVITE sip:03419612642@sipgate.de SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-e55ce0da;rport^M From: Richter <sip:1666030e0@sipgate.de>;tag=b82078c374d3f749o0^M To: <sip:03419612642@sipgate.de>^M Call-ID: 5c3829cb-8914b9e1@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 440^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 7857 7857 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16410 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:51:35 192.168.15.9 Sep 24 18:51:35 192.168.15.9 Sep 24 18:51:36 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:36 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:36 192.168.15.9 INVITE sip:03419612642@sipgate.de SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-e55ce0da;rport^M From: Richter <sip:1666030e0@sipgate.de>;tag=b82078c374d3f749o0^M To: <sip:03419612642@sipgate.de>^M Call-ID: 5c3829cb-8914b9e1@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 440^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 7857 7857 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16410 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:51:36 192.168.15.9 Sep 24 18:51:36 192.168.15.9 Sep 24 18:51:37 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:37 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:37 192.168.15.9 INVITE sip:03419612642@sipgate.de SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-e55ce0da;rport^M From: Richter <sip:1666030e0@sipgate.de>;tag=b82078c374d3f749o0^M To: <sip:03419612642@sipgate.de>^M Call-ID: 5c3829cb-8914b9e1@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 440^M Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 7857 7857 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M m=audio 16410 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M Sep 24 18:51:37 192.168.15.9 Sep 24 18:51:37 192.168.15.9 Sep 24 18:51:38 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:38 192.168.15.9 [0:5060]->217.10.68.147:5060 Sep 24 18:51:38 192.168.15.9 NOTIFY sip:217.10.68.147 SIP/2.0^M Via: SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-52ed5778;rport^M From: Richter <sip:1666030e0@sipgate.de>;tag=ac368516db778115o0^M To: <sip:217.10.68.147>^M Call-ID: cccf0fda-c308d521@192.168.15.9^M CSeq: 8 NOTIFY^M Max-Forwards: 70^M Event: keep-alive^M User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 0^M ^M [messages repeating] Sep 24 18:52:07 192.168.15.9 Sep 24 18:52:07 192.168.15.9 Sep 24 18:52:07 192.168.15.9 [0:0]AUD Rel Call Sep 24 18:52:07 192.168.15.9 CC:Failed w/ Calling Sep 24 18:52:07 192.168.15.9 Sess Terminated In both you can see the following line: <sip:217.10.68.147>^M Call-ID: cccf0fda-c308d521@192.168.15.9 I supsect that this is the faulty one. But maybe i am wrong? However, all that doesnt work. I didnt find my provider (sipgate.de) to have a nat proxy. But i read something about sip server or something like that? Any other ideas what is going on here? Thanks Sven On Thu, Sep 24, 2009 at 2:25 PM, Simon Hobson <linux@thehobsons.co.uk> wrote:> Sven Richter wrote: > >>I can register with my account, but that is almost all i can do :( >>I also can call the phone at the voip adapter, but, thats it. >> >>If i take up the call i dont hear anything and if i try to call from >>the phone at the adapter i never hear it ringing. >>That is sad, really sad. >> >>What seems suspicious to me is that the overview of the adapter shows >>me receiving a lot of sip messages and bytes, but the counter for rtp >>packages and bytes always remains zero. Again seems like a NAT >>problem? >> >>Is there a way to allow all traffic to that one adapter with >>shorewall, so to say to a fixed ip? >>Without interupting anything? > > <rant>Welcome to the world of NAT - a completely and utterly broken > network by design. I want to throttle anyone who tries to tell me > that it not broken or is a good idea - it''s bodge that breaks lots of > stuff and has significantly contributed to the delays in getting IPv6 > going mainstream (because clueless f***wits think NAT is a fix for > lack of address space in IPv4). It breaks both rules of IP addressing > - IP address must be globally unique, and IP addresses must be > globally routable.</rant> > > > Here are the steps you need to take to get SIP working. > > 1) Make sure any SIP helper (or Application Level Gateway (ALG)) is > disabled in your router. These try to help, but as often as not > simply break things even more. > > 2) Check the label on the front of your NAT gateway/router. If it > says Zyxel, bin it and save yourself some headaches. Zyxel take NAT > to new levels of broken that I''d previously considered unreachable. > > > Now comes the fun bit ! > > > If your VoIP provider has a NAT proxy then use it. These simply take > your SIP traffic, ignore the IP address and port info in them, > substitute the actual address/port seen in the packet header, and > logs into the SIP server on your behalf. For RTP traffic, again they > look at the actual address/port seen in the packet headers you send > out, and send their end of the conversation to that instead of what > your SIP device says. > > Trust me, for a single device this is by far the simplest and most > reliable way to do it. > > > If this isn''t available then continue : > > 3) Check what RTP ports your device uses - it should have a range > defined in the config somewhere. Configure your router to allow > inbound traffic to these udp ports and forward it to your device. > Also do the same with SIP (port 5060 on udp, or possibly on tcp as > well). > > > > If you have a fixed address, then look at the SIP device and find a > setting where you can tell it what it''s outside address is. Put your > fixed public address in there and your device will use that in all > it''s messages instead of it''s actual (internal) network address. > > > Failing that, configure your device to use STUN (Simple Traversal of > UDP through NAT). This feature will talk to an external STUN server > to probe the network (with help from the external server) and > discover what sort of NAT is in use and what your public IP is. > > > > Why all this hassle ? > > Embedded in the SIP messages are IP address/port pairs. When you set > up a call, one ends says "I have a call for you, you should send the > RTP stream to address:port". The other end replies "OK, I''m going to > use address:port for my end". Each end then sends the RTP data > packets to the address:port specified - and if that happens to be a > non-routable 192.168.x.y address instead of a real address then that > half of the conversation ''just disappears''. Part of the reason it''s > done this way is that the SIP ''exchange'' device doesn''t have to route > the packets - it''s perfectly possible to have the two end devices > send the RTP packets directly to each other while the SIP exchange > does nothing but pass control messages (ie setup and end the call). > > NAT just completely f***s this up, and it is NOT possible to > configure an ALG that can handle all possible permutations of f**k up. > > -- > Simon Hobson > > Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed > author Gladys Hobson. Novels - poetry - short stories - ideal as > Christmas stocking fillers. Some available as e-books. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® 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/devconf > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
Wow, i should have taken a look at faq 77 of shorewall. I removed both modules like said in the faq and it works now. What a wonderful world. Thanks to all who helped me out. I really appreciated your engagement. Greetings Sven On Thu, Sep 24, 2009 at 6:55 PM, Sven Richter <sveri80@googlemail.com> wrote:> Hi Simon, > > thank you for your long and explaining email. I was afraid that i''ll > face someday a problem like that. A nat problem. I read some things > about the specification and about how f**** up it is, but never cared. > > However, my router is a linux box with shorewall. I "natted" all > traffic (ports 5060 and 16384-16482) to my adapter, but that wont do > the trick. > > Looking at the logs i think i see the problem: > > Sep 24 18:29:39 192.168.15.9 SIP/2.0 200 OK^M Record-Route: > <sip:217.10.68.147;lr=on;ftag=65bbf9ec3a01a2cco0>^M Via: SIP/2.0/UDP > 192.168.15.9:5060;branch=z9hG4bK-201f4727;rport=5060^M From: Richter > <sip:1666030e0@sipgate.de>;tag=65bbf9ec3a01a2cco0^M To: > <sip:217.10.68.147>;tag=efae1b206a1df22b5fbc395b5a747d13.8532^M > Call-ID: 630bee6c-a79e384c@192.168.15.9^M CSeq: 79 NOTIFY^M > Content-Length: 0^M ^M > > There at the and i see the internal ip and not the external one. But, > my adapter has both abilities, the one to use the stun server and the > one to enter an external ip (i dont have a fixed one, but our dynamic > ip only changes all few weeks). > I tried both options, but neither worked. > > Here is the log with stun server enabled: > > Sep 24 18:31:51 192.168.15.9 [0]On Hook > Sep 24 18:31:53 192.168.15.9 [0]Off Hook > Sep 24 18:31:58 192.168.15.9 [5060]STUN trying 0 > Sep 24 18:31:58 192.168.15.9 [16444]STUN trying 0 > Sep 24 18:31:58 192.168.15.9 [16445]STUN trying 0 > Sep 24 18:31:58 192.168.15.9 [16446]STUN trying 0 > Sep 24 18:31:58 192.168.15.9 [16447]STUN trying 0 > Sep 24 18:31:58 192.168.15.9 [0:0]CC:STUN OK:c0a80f09->4d14ed71, > 5060->5060 16444->16444 > Sep 24 18:31:58 192.168.15.9 Calling:016099107562@sipgate.de:0 > Sep 24 18:31:58 192.168.15.9 [0:0]AUD ALLOC CALL (port=16444) > Sep 24 18:31:58 192.168.15.9 [0:0]RTP Rx Up > Sep 24 18:31:58 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:31:58 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:31:58 192.168.15.9 INVITE sip:016099107562@sipgate.de > SIP/2.0^M Via: SIP/2.0/UDP > 77.20.237.113:5060;branch=z9hG4bK-5fa7a07e;rport^M From: Richter > <sip:1666030e0@sipgate.de>;tag=a1e57602f246d1deo0^M To: > <sip:016099107562@sipgate.de>^M Call-ID: > b85693d2-522bce4e@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M > Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M > User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 442^M Allow: > ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: > x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- > 93561 93561 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 > 0^M m=audio 16444 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 > PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M > a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 > G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M > a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 > telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M > Sep 24 18:31:58 192.168.15.9 > Sep 24 18:31:58 192.168.15.9 > Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:31:59 192.168.15.9 INVITE sip:016099107562@sipgate.de > SIP/2.0^M Via: SIP/2.0/UDP > 77.20.237.113:5060;branch=z9hG4bK-5fa7a07e;rport^M From: Richter > <sip:1666030e0@sipgate.de>;tag=a1e57602f246d1deo0^M To: > <sip:016099107562@sipgate.de>^M Call-ID: > b85693d2-522bce4e@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M > Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M > User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 442^M Allow: > ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: > x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- > 93561 93561 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 > 0^M m=audio 16444 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 > PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M > a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 > G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M > a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 > telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M > Sep 24 18:31:59 192.168.15.9 > Sep 24 18:31:59 192.168.15.9 > Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:31:59 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:31:59 192.168.15.9 NOTIFY sip:217.10.68.147 SIP/2.0^M Via: > SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-6d7849d0;rport^M From: > Richter <sip:1666030e0@sipgate.de>;tag=65bbf9ec3a01a2cco0^M To: > <sip:217.10.68.147>^M Call-ID: 630bee6c-a79e384c@192.168.15.9^M CSeq: > 93 NOTIFY^M Max-Forwards: 70^M Event: keep-alive^M User-Agent: > Linksys/PAP2T-5.1.1(LS)^M Content-Length: 0^M ^M > > Sep 24 18:49:29 192.168.15.9 > Sep 24 18:49:29 192.168.15.9 > Sep 24 18:49:29 192.168.15.9 [0:5060]<<217.10.68.147:5060 > Sep 24 18:49:29 192.168.15.9 [0:5060]<<217.10.68.147:5060 > Sep 24 18:49:29 192.168.15.9 SIP/2.0 200 OK^M Record-Route: > <sip:217.10.68.147;lr=on;ftag=36bb74bb43384db3o0>^M Via: SIP/2.0/UDP > 192.168.15.9:5060;branch=z9hG4bK-c62ea4f2;rport=5060^M From: Richter > <sip:1666030e0@sipgate.de>;tag=36bb74bb43384db3o0^M To: > <sip:217.10.68.147>;tag=efae1b206a1df22b5fbc395b5a747d13.d026^M > Call-ID: 724726db-8a434213@192.168.15.9^M CSeq: 3 NOTIFY^M > Content-Length: 0^M ^M > Sep 24 18:49:29 192.168.15.9 > > [messages repeating] > > Sep 24 18:32:30 192.168.15.9 > Sep 24 18:32:30 192.168.15.9 > Sep 24 18:32:30 192.168.15.9 [0:0]AUD Rel Call > Sep 24 18:32:30 192.168.15.9 CC:Failed w/ Calling > Sep 24 18:32:30 192.168.15.9 Sess Terminated > > > And here is the one with the external ip enabled: > > Sep 24 18:51:29 192.168.15.9 [0]On Hook > Sep 24 18:51:30 192.168.15.9 [0]Off Hook > Sep 24 18:51:30 192.168.15.9 [0]CID interrupted > Sep 24 18:51:35 192.168.15.9 Calling:03419612642@sipgate.de:0 > Sep 24 18:51:35 192.168.15.9 [0:0]AUD ALLOC CALL (port=16410) > Sep 24 18:51:35 192.168.15.9 [0:0]RTP Rx Up > Sep 24 18:51:35 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:51:35 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:51:35 192.168.15.9 INVITE sip:03419612642@sipgate.de > SIP/2.0^M Via: SIP/2.0/UDP > 77.20.237.113:5060;branch=z9hG4bK-e55ce0da;rport^M From: Richter > <sip:1666030e0@sipgate.de>;tag=b82078c374d3f749o0^M To: > <sip:03419612642@sipgate.de>^M Call-ID: > 5c3829cb-8914b9e1@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M > Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M > User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 440^M Allow: > ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: > x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 7857 > 7857 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M > m=audio 16410 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 > PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M > a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 > G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M > a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 > telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M > Sep 24 18:51:35 192.168.15.9 > Sep 24 18:51:35 192.168.15.9 > Sep 24 18:51:36 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:51:36 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:51:36 192.168.15.9 INVITE sip:03419612642@sipgate.de > SIP/2.0^M Via: SIP/2.0/UDP > 77.20.237.113:5060;branch=z9hG4bK-e55ce0da;rport^M From: Richter > <sip:1666030e0@sipgate.de>;tag=b82078c374d3f749o0^M To: > <sip:03419612642@sipgate.de>^M Call-ID: > 5c3829cb-8914b9e1@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M > Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M > User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 440^M Allow: > ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: > x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 7857 > 7857 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M > m=audio 16410 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 > PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M > a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 > G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M > a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 > telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M > Sep 24 18:51:36 192.168.15.9 > Sep 24 18:51:36 192.168.15.9 > Sep 24 18:51:37 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:51:37 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:51:37 192.168.15.9 INVITE sip:03419612642@sipgate.de > SIP/2.0^M Via: SIP/2.0/UDP > 77.20.237.113:5060;branch=z9hG4bK-e55ce0da;rport^M From: Richter > <sip:1666030e0@sipgate.de>;tag=b82078c374d3f749o0^M To: > <sip:03419612642@sipgate.de>^M Call-ID: > 5c3829cb-8914b9e1@192.168.15.9^M CSeq: 101 INVITE^M Max-Forwards: 70^M > Contact: Richter <sip:1666030e0@77.20.237.113:5060>^M Expires: 240^M > User-Agent: Linksys/PAP2T-5.1.1(LS)^M Content-Length: 440^M Allow: > ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER^M Supported: > x-sipura, replaces^M Content-Type: application/sdp^M ^M v=0^M o=- 7857 > 7857 IN IP4 77.20.237.113^M s=-^M c=IN IP4 77.20.237.113^M t=0 0^M > m=audio 16410 RTP/AVP 8 0 2 4 18 96 97 98 100 101^M a=rtpmap:8 > PCMA/8000^M a=rtpmap:0 PCMU/8000^M a=rtpmap:2 G726-32/8000^M > a=rtpmap:4 G723/8000^M a=rtpmap:18 G729a/8000^M a=rtpmap:96 > G726-40/8000^M a=rtpmap:97 G726-24/8000^M a=rtpmap:98 G726-16/8000^M > a=rtpmap:100 NSE/8000^M a=fmtp:100 192-193^M a=rtpmap:101 > telephone-event/8000^M a=fmtp:101 0-15^M a=ptime:20^M a=sendrecv^M > Sep 24 18:51:37 192.168.15.9 > Sep 24 18:51:37 192.168.15.9 > Sep 24 18:51:38 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:51:38 192.168.15.9 [0:5060]->217.10.68.147:5060 > Sep 24 18:51:38 192.168.15.9 NOTIFY sip:217.10.68.147 SIP/2.0^M Via: > SIP/2.0/UDP 77.20.237.113:5060;branch=z9hG4bK-52ed5778;rport^M From: > Richter <sip:1666030e0@sipgate.de>;tag=ac368516db778115o0^M To: > <sip:217.10.68.147>^M Call-ID: cccf0fda-c308d521@192.168.15.9^M CSeq: > 8 NOTIFY^M Max-Forwards: 70^M Event: keep-alive^M User-Agent: > Linksys/PAP2T-5.1.1(LS)^M Content-Length: 0^M ^M > > [messages repeating] > > Sep 24 18:52:07 192.168.15.9 > Sep 24 18:52:07 192.168.15.9 > Sep 24 18:52:07 192.168.15.9 [0:0]AUD Rel Call > Sep 24 18:52:07 192.168.15.9 CC:Failed w/ Calling > Sep 24 18:52:07 192.168.15.9 Sess Terminated > > In both you can see the following line: <sip:217.10.68.147>^M > Call-ID: cccf0fda-c308d521@192.168.15.9 > I supsect that this is the faulty one. But maybe i am wrong? > > However, all that doesnt work. I didnt find my provider (sipgate.de) > to have a nat proxy. > But i read something about sip server or something like that? > > Any other ideas what is going on here? > > > Thanks > Sven > > On Thu, Sep 24, 2009 at 2:25 PM, Simon Hobson <linux@thehobsons.co.uk> wrote: >> Sven Richter wrote: >> >>>I can register with my account, but that is almost all i can do :( >>>I also can call the phone at the voip adapter, but, thats it. >>> >>>If i take up the call i dont hear anything and if i try to call from >>>the phone at the adapter i never hear it ringing. >>>That is sad, really sad. >>> >>>What seems suspicious to me is that the overview of the adapter shows >>>me receiving a lot of sip messages and bytes, but the counter for rtp >>>packages and bytes always remains zero. Again seems like a NAT >>>problem? >>> >>>Is there a way to allow all traffic to that one adapter with >>>shorewall, so to say to a fixed ip? >>>Without interupting anything? >> >> <rant>Welcome to the world of NAT - a completely and utterly broken >> network by design. I want to throttle anyone who tries to tell me >> that it not broken or is a good idea - it''s bodge that breaks lots of >> stuff and has significantly contributed to the delays in getting IPv6 >> going mainstream (because clueless f***wits think NAT is a fix for >> lack of address space in IPv4). It breaks both rules of IP addressing >> - IP address must be globally unique, and IP addresses must be >> globally routable.</rant> >> >> >> Here are the steps you need to take to get SIP working. >> >> 1) Make sure any SIP helper (or Application Level Gateway (ALG)) is >> disabled in your router. These try to help, but as often as not >> simply break things even more. >> >> 2) Check the label on the front of your NAT gateway/router. If it >> says Zyxel, bin it and save yourself some headaches. Zyxel take NAT >> to new levels of broken that I''d previously considered unreachable. >> >> >> Now comes the fun bit ! >> >> >> If your VoIP provider has a NAT proxy then use it. These simply take >> your SIP traffic, ignore the IP address and port info in them, >> substitute the actual address/port seen in the packet header, and >> logs into the SIP server on your behalf. For RTP traffic, again they >> look at the actual address/port seen in the packet headers you send >> out, and send their end of the conversation to that instead of what >> your SIP device says. >> >> Trust me, for a single device this is by far the simplest and most >> reliable way to do it. >> >> >> If this isn''t available then continue : >> >> 3) Check what RTP ports your device uses - it should have a range >> defined in the config somewhere. Configure your router to allow >> inbound traffic to these udp ports and forward it to your device. >> Also do the same with SIP (port 5060 on udp, or possibly on tcp as >> well). >> >> >> >> If you have a fixed address, then look at the SIP device and find a >> setting where you can tell it what it''s outside address is. Put your >> fixed public address in there and your device will use that in all >> it''s messages instead of it''s actual (internal) network address. >> >> >> Failing that, configure your device to use STUN (Simple Traversal of >> UDP through NAT). This feature will talk to an external STUN server >> to probe the network (with help from the external server) and >> discover what sort of NAT is in use and what your public IP is. >> >> >> >> Why all this hassle ? >> >> Embedded in the SIP messages are IP address/port pairs. When you set >> up a call, one ends says "I have a call for you, you should send the >> RTP stream to address:port". The other end replies "OK, I''m going to >> use address:port for my end". Each end then sends the RTP data >> packets to the address:port specified - and if that happens to be a >> non-routable 192.168.x.y address instead of a real address then that >> half of the conversation ''just disappears''. Part of the reason it''s >> done this way is that the SIP ''exchange'' device doesn''t have to route >> the packets - it''s perfectly possible to have the two end devices >> send the RTP packets directly to each other while the SIP exchange >> does nothing but pass control messages (ie setup and end the call). >> >> NAT just completely f***s this up, and it is NOT possible to >> configure an ALG that can handle all possible permutations of f**k up. >> >> -- >> Simon Hobson >> >> Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed >> author Gladys Hobson. Novels - poetry - short stories - ideal as >> Christmas stocking fillers. Some available as e-books. >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® 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/devconf >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
Sven Richter wrote:>Wow, i should have taken a look at faq 77 of shorewall. I removed both >modules like said in the faq and it works now.Mentioned earlier in the thread ! My experience is that SIP ALGs are more likely to break stuff than help. It caught me out one time when setting up a new router - and suddenly the PBX stopped working with SIP trunks. Took a while to twig that Linux (Debian Etch in this case) had defaulted to including the SIP helper. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf
On Thu, Sep 24, 2009 at 8:49 PM, Simon Hobson <linux@thehobsons.co.uk> wrote:> Sven Richter wrote: >>Wow, i should have taken a look at faq 77 of shorewall. I removed both >>modules like said in the faq and it works now. > > Mentioned earlier in the thread ! >Yea, i know. But i was a bit overinformed with everything. My fault. Of course my one.> My experience is that SIP ALGs are more likely to break stuff than > help. It caught me out one time when setting up a new router - and > suddenly the PBX stopped working with SIP trunks. Took a while to > twig that Linux (Debian Etch in this case) had defaulted to including > the SIP helper. >This is what i dont like about the "we do it all for you" solutions. Of course, they save a lot of time normally, but in some cases you need all that time again to find out what is already done and what is wrong about that. However, thank you all once more. I learned a lot in this lesson. Greetings Sven> > -- > Simon Hobson > > Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed > author Gladys Hobson. Novels - poetry - short stories - ideal as > Christmas stocking fillers. Some available as e-books. > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® 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/devconf > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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/devconf