[Shorewall-users] VoIP, getting ICMP destination unreachable

[Sebastian Tänzer]

Hello,

I've recently set up our shorewall based firewall to use our GrandStream voip phones connecting to sipgate.de.
I'm experiencing some problems as after some time (2-3 hours) the phones are still registered but when calling
so. I can't hear them (but the other side can hear me).

I tried different settings by checking the port forwardings, disabling STUN and NAT on the device itself.
I can't tell if it works now (as I can hear the other side now) but will stop working again in a couple of hours.

Traffic logs with tshark show no errors, except this:

450.767075 192.168.10.253 -> 192.168.10.160 ICMP Destination unreachable (Port unreachable)

- and it's there almost each second.

As you can see from the dump attached access between my fw (10.253) and 10.160 is wide open.
10.160 is my voip phone.

Any ideas what this is about or should I ignore this message?

Best,
Sebastian

[Jorge Armando Medina]

Post by Sebastian Tänzer
Hello,

Hi Sebastian,

Post by Sebastian Tänzer
I've recently set up our shorewall based firewall to use our GrandStream voip phones connecting to sipgate.de.
I'm experiencing some problems as after some time (2-3 hours) the phones are still registered but when calling
so. I can't hear them (but the other side can hear me).

I had a similar problem, with a Asterisk PBX behind shorewall and remote
iphones, this phones registerd but when RTP traffic appeared I got dest
unreachable messages.

What I did is read FAQ 77 and disable sip helpers, after that SIP and
RTP traffic worked.

NOTE: I was using sip helpers because a few local phones were
connectiong to a hosted pbx and I used simple traffic shapping using sip
helper for QoS, I had to change the way about simple traffic shapping.

http://www.shorewall.net/FAQ.htm#faq77

Best regards.

Post by Sebastian Tänzer
I tried different settings by checking the port forwardings, disabling STUN and NAT on the device itself.
I can't tell if it works now (as I can hear the other side now) but will stop working again in a couple of hours.
450.767075 192.168.10.253 -> 192.168.10.160 ICMP Destination unreachable (Port unreachable)
- and it's there almost each second.
As you can see from the dump attached access between my fw (10.253) and 10.160 is wide open.
10.160 is my voip phone.
Any ideas what this is about or should I ignore this message?
Best,
Sebastian
------------------------------------------------------------------------------
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Christian Vieser]

Hi Sebastian.

Post by Sebastian Tänzer
I've recently set up our shorewall based firewall to use our GrandStream voip phones connecting to sipgate.de.
I'm experiencing some problems as after some time (2-3 hours) the phones are still registered but when calling
so. I can't hear them (but the other side can hear me).

We also installed a GrandStream phone recently with sipgate and I had
the same problem in the beginning. Solution was, to disable STUN on the
device and enable the sip helper modules (nf_nat_sip, nf_conntrack_sip)
on the shorewall firewall. Only rule I made for the phone was an ACCEPT
on all outgoing UDP connections (for your case: ACCEPT
loc:192.168.10.160 net udp).

Regards,
Christian

[Mr Dash Four]

Post by Christian Vieser
Solution was, to disable STUN on the
device and enable the sip helper modules (nf_nat_sip, nf_conntrack_sip)
on the shorewall firewall.

Interesting! I've had major some major headaches with VOIP (it is fair
to say I was STUNned as well - on multiple occasions I might add) and
had to 'invent' a VOIP proxy based on the X-Tunnels protocol and route
VOIP traffic, securely and in BOTH directions, from three internal
networks via a single point externally (one machine visible from the
outside world).

This is the first time I am seeing these 'helper modules'. Where can I
find more information about them and how they are used/work?

[Mr Dash Four]

OK, I was intrigued by earlier posts in the "VoIP, getting ICMP
destination unreachable" thread and started digging up info on the above
2 modules and their use on Shorewall.

I found a good starting-point reference here -
http://wiki.freeswitch.org/wiki/Firewall, but I am still unclear as to
the function of this two modules - what are they actually 'helping'
with? The link gives brief information about the various module
parameters, but they are a bit sketchy and apart from the "ports"
parameter I am not completely clear what the rest of them mean?

So, how are these modules helping? Establishing pin holes in the
firewall for voip connection/traffic to go through? Establishing
connection tracking so that when initial connection to voip server is
made on :5060 all subsequent connections initiated/received (on random
high ports) are treated as part of this RELATED initial connection to
:5060? If so, do I need to define separate rules for them or adding just
one rule for connection to the voip server to :5060 would be enough?
What about the SELinux contexts - are they kept the same provided all
other connections are treated the same by the above 2 'helper' modules?

I am asking all these questions because up until now I had no idea about
their existence and all my voip traffic (and it is a LOT of it in my
case) is confined by explicit rules defined in the rules file (I also
use a specifically designed voip proxy which routes all my internal voip
traffic coming from all 3 subnets to an external provider). These rules
are matched/related together by defined uid/gid of the process which
runs my voip traffic show.

I checked with lsmod and the above two modules are indeed loaded on my
main firewall machine (where Shorewall is), though they are not
specifically configured in any way. Any info or experience shared on the
usage and configuration of these two modules and the appropriate
Shorewall setup is welcome!

[Tom Eastep]

Post by Mr Dash Four
OK, I was intrigued by earlier posts in the "VoIP, getting ICMP
destination unreachable" thread and started digging up info on the above
2 modules and their use on Shorewall.
I found a good starting-point reference here -
http://wiki.freeswitch.org/wiki/Firewall, but I am still unclear as to
the function of this two modules - what are they actually 'helping'
with? The link gives brief information about the various module
parameters, but they are a bit sketchy and apart from the "ports"
parameter I am not completely clear what the rest of them mean?

Application designers are in love with the notion that they can embed IP
addresses and port numbers in packets sent to their peer with the
expectation that the peer will then return packets addressed to that
embedded address/port. This has been going on forever (think FTP). That
works fine until a stateful firewall is injected between the peers. The
firewall must then deal with these return connections without knowing
about them in advance. This is the purpose of Netfilter 'helpers'.

These helpers examine packets going through the firewall and create
"expectations"; An "expectation" is essentially a temporary "hole" in
the firewall in the form of a conntrack entry that will be matched by
the return or "related" connection. This allows expecations to properly
handle NAT as well as allowing passage through the firewall.

Helper modules are not autoloaded. When using the sample Shorewall
configurations, the generated firewall script loads all helper modules
during start/restart. You can suppress the loading of individual helpers
using the DONT_LOAD option in shorewall.conf.

I've written an example of how the FTP helper works at
http://www.shorewall.net/FTP.html. Other helpers are similar.

I have no direct experience with VOIP so there is no similar article on

[Mr Dash Four]

Post by Tom Eastep
I've written an example of how the FTP helper works at
http://www.shorewall.net/FTP.html. Other helpers are similar.
I have no direct experience with VOIP so there is no similar article on
the Shorewall site concerning SIP.

[Tom Eastep]

Post by Tom Eastep
I've written an example of how the FTP helper works at
http://www.shorewall.net/FTP.html. Other helpers are similar.
I have no direct experience with VOIP so there is no similar article on