Hello, Are there general guidelines around on how to configure Shorewall for use with SIP phones ? Especially regarding (some?) Cisco SIP phones which are expecting a reply at port 5060 while sending from an arbitrary high port. Thanks ! ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412
Fred Maillou skrev den 2013-01-07 17:10:> Are there general guidelines around on how to configure Shorewall > for use with SIP phones ? Especially regarding (some?) Cisco SIP > phones which are expecting a reply at port 5060 while sending from an > arbitrary high port.for sip protocol to work there is just that shorewall must load sip conntrackers, so make sure there is sip conntracker in your kernel, thats all atleast it works with my linksys spa 2102 ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512
Benny Pedersen wrote:>> Are there general guidelines around on how to configure Shorewall >> for use with SIP phones ? Especially regarding (some?) Cisco SIP >> phones which are expecting a reply at port 5060 while sending from an >> arbitrary high port. > >for sip protocol to work there is just that shorewall must load sip >conntrackers, so make sure there is sip conntracker in your kernel, >thats all > >atleast it works with my linksys spa 2102It depends a lot on your setup. In many cases, loading SIP helper will completely screw up your connection, in others it''s needed. A good example of where NAT == Broken. Personally I make a point of disabling any SIP helper and configuring the endpoints to deal with the NAT - I find it''s more reliable. A lot depends on the capabilities of the devices on all ends of the connections. On "sensible" NAT gateways, a device can use STUN to work out it''s public IP and type of NAT, and then work reliably - don''t try this witha Zyxel router as they go out of their way to f**k stuff up. Most public VoIP providers have NAT gateways which essentially ignore the content of the ISP messages and look to see where the RTP stream actually arrives from - and then proxy that to the final destination. ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512
Simon Hobson <linux@thehobsons.co.uk> wrote:> It depends a lot on your setup. In many cases, loading SIP > helper will completely screw up your connection, in others it''s > needed. A good example of where NAT == Broken.> Personally I make a point of disabling any SIP helper and > configuring the endpoints to deal with the NAT - I find it''s > more reliable. A lot depends on the capabilities of the devices > on all ends of the connections. On "sensible" NAT gateways, a > device can use STUN to work out it''s public IP and type of NAT, > and then work reliably - don''t try this witha Zyxel router as > they go out of their way to f**k stuff up. Most public VoIP > providers have NAT gateways which essentially ignore the > content of the ISP messages and look to see where the RTP > stream actually arrives from - and then proxy that to the final > destination.I work from the router point of view. I have seen that there can be a problem with certain phones when the nf_nat_sip (and/or) nf_conntrack_sip modules are loaded. At least, that''s what it looks like at the moment - still under test. I''m looking at a simple way to have SIP support for users. Having a GUI option to unload a ''SIP helper'' (if SIP does not seem to work) is not much user friendly - a bit too arcane. Kernel is 3.0.0 for ppc arch. Any suggestions ? Thanks. ________________________________ De : Simon Hobson <linux@thehobsons.co.uk> À : shorewall-users@lists.sourceforge.net Envoyé le : mardi 8 janvier 2013 7h47 Objet : Re: [Shorewall-users] Shorewall and SIP phones Benny Pedersen wrote:>> Are there general guidelines around on how to configure Shorewall >> for use with SIP phones ? Especially regarding (some?) Cisco SIP >> phones which are expecting a reply at port 5060 while sending from an >> arbitrary high port. > >for sip protocol to work there is just that shorewall must load sip >conntrackers, so make sure there is sip conntracker in your kernel, >thats all > >atleast it works with my linksys spa 2102It depends a lot on your setup. In many cases, loading SIP helper will completely screw up your connection, in others it''s needed. A good example of where NAT == Broken. Personally I make a point of disabling any SIP helper and configuring the endpoints to deal with the NAT - I find it''s more reliable. A lot depends on the capabilities of the devices on all ends of the connections. On "sensible" NAT gateways, a device can use STUN to work out it''s public IP and type of NAT, and then work reliably - don''t try this witha Zyxel router as they go out of their way to f**k stuff up. Most public VoIP providers have NAT gateways which essentially ignore the content of the ISP messages and look to see where the RTP stream actually arrives from - and then proxy that to the final destination. ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512
On 01/08/2013 11:42 AM, Fred Maillou wrote:> > I work from the router point of view. I have seen that there can > be a problem with certain phones when the nf_nat_sip (and/or) > nf_conntrack_sip modules are loaded. At least, that''s what it > looks like at the moment - still under test. I''m looking at a > simple way to have SIP support for users. Having a GUI option to > unload a ''SIP helper'' (if SIP does not seem to work) is not much > user friendly - a bit too arcane. Kernel is 3.0.0 for ppc arch. > Any suggestions ?Given that it is easier to load a module than to unload one (which might be in use), it might make sense to prevent the module from being loaded by default (remove it from /etc/shorewall/helpers) and provide a way to load it if the default setting doesn''t work. -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 \________________________________________________ ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512