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 ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
Jorge Armando Medina
2010-Sep-06 22:32 UTC
Re: ***UNCHECKED*** VoIP, getting ICMP destination unreachable
On 09/06/2010 02:53 AM, Sebastian Tänzer wrote:> Hello,Hi Sebastian,> > 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.> > 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 > > > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > 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 > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- Compugraf ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd
Hi Sebastian.> 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 ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev
> 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? ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev
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! ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 10:54 AM, Mr Dash Four wrote:> 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 the Shorewall site concerning SIP. From the list it is clear that some people find that the SIP helpers actuall break VOIP (See Shorewall FAQ 77) while others claim that the SIP helpers are essential Hope this helps. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> 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. From the list it is clear that some > people find that the SIP helpers actuall break VOIP (See Shorewall FAQ > 77) while others claim that the SIP helpers are essential >I read the now famous FAQ 77 (this is actually what I have started with), though I was hoping to get more help on the above modules themselves and their integration into Shorewall - apart from specifying the startup options (in the ''modules'' file) is there anything in particular that Shorewall uses to ''help'' with such tracking or is it a case of leaving this to the modules themselves after they are loaded? This concept is new to me and although I had (rather vague) idea of how ftp connections were tracked, voip is not the same (there are multiple ''data'' channels - so it is not just one). If this modules can help track my voip data connections I won''t burden myself implementing unnecessary rules and SELinux contexts - a big IF, I know, hence why I''d like to learn more about these two modules. Is there a more detailed help/reference about these somewhere? ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
Tom Eastep wrote:>From the list it is clear that some >people find that the SIP helpers actuall break VOIP (See Shorewall FAQ >77) while others claim that the SIP helpers are essentialIndeed - and not just with Linux devices either as SIP ALGs (Application Level Gateways) are appearing in more and more stuff now. There are two issues - one which you mention. The other part of the equation is that if you embed your local address as (say) 192.168.1.57 - the remote end will try and send packets to that address but they''ll be dropped fairly quickly and never reach you. So the second part of the ALG is to fiddle with the contents of the packet and alter the address/port to suit. Personally, I prefer to disable ALGs as my experience suggest they cause more problems than they solve. For one thing, in the general case it is simply not possible for a SIP ALG to know the full topology of the entire network and it''s not possible to correctly alter the packet content in all cases. The other problem is that they can sometimes have false positives and erroneously alter packets they shouldn''t - this being one of the FAQs for at least one torrent application ! My preference is to use devices that can determine their public IP and the type of NAT via STUN and then craft the correct packets in the first place. That breaks on devices designed by clueless f***wits who think forcing randomisation of port mapping is a good idea - with the attitude that they don''t care if it doesn''t work, at least you are safe ! Yes, there is a popular and well known vendor of network equipment (both consumer and pro) that does just that, and has just that attitude. For SIP, the requirement to open up the corresponding ports isn''t normally an issue. The audio is carried by UDP packets, and so when the device at one end starts sending it''s packets, that inherently opens up the corresponding inbound connection for packets from the other end. You may lose a few packets until this happens, but that''s just a very short pause on the beginning of a phone call. Alternatively, it''s more admin but also more reliable to statically configure everything. Manually configure each SIP device to use a different port for it''s SIP traffic, and a different port range for it''s RTP traffic. Configure them with knowledge of their public IP, and manually configure your firewall with all the corresponding NAT mappings. What definitely doesn''t work is top mix techniques. If your device does STUN and your gateway has a SIP ALG - then your correct packets sent by the device will be mangled by the ALG. There is a very real reason why SIP embeds IP address/port information in the packets. Unlike most protocols, the device doing the call setup/control is not required to be the same device that is the source or sink of any of the actual call content. Ie, it''s perfectly legal for two VOIP phones to send the audio stream directly to each other with no intermediate call routing system. The "PBX" merely controls the calls and passes information to each endpoint on the progress of call setup and where each device needs to send it''s media stream. Few systems are setup like this for the simple reason that it''s completely borked by NAT. Leading to ... <mounts soapbox> The real answer is to persuade the world and his dog that NAT == Broken. By definition, NAT breaks rule 1 of IP connectivity that requires every device to have a globally unique and routeable address. If only as much effort was put into making IPv6 as ubiquitous as IPv4 as is put into trying to work round (eg writing ALGs to put into NAT gateways) the fundamental breakage of NAT then I think IPv6 would be a lot further on than it is. -- 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. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
On 9/14/10 1:00 PM, Mr Dash Four wrote:> >> 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. From the list it is clear that some >> people find that the SIP helpers actuall break VOIP (See Shorewall FAQ >> 77) while others claim that the SIP helpers are essential >> > I read the now famous FAQ 77 (this is actually what I have started > with), though I was hoping to get more help on the above modules > themselves and their integration into Shorewall - apart from specifying > the startup options (in the ''modules'' file) is there anything in > particular that Shorewall uses to ''help'' with such tracking or is it a > case of leaving this to the modules themselves after they are loaded?The latter. Incidentally, if you have LOAD_HELPERS_ONLY=Yes in shorewall.conf, it is actually the /usr/share/shorewall/helpers file that lists the modules to be loaded. I''ll add that to the shorewall-modules(5) manpage.> > This concept is new to me and although I had (rather vague) idea of how > ftp connections were tracked, voip is not the same (there are multiple > ''data'' channels - so it is not just one). > > If this modules can help track my voip data connections I won''t burden > myself implementing unnecessary rules and SELinux contexts - a big IF, I > know, hence why I''d like to learn more about these two modules. Is there > a more detailed help/reference about these somewhere?I just told you there is nothing on the Shorewall site, and you can use Google as well as any of us can. But please let us know if you find anything useful and I''ll add a link on the site. -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 \________________________________________________ ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> I just told you there is nothing on the Shorewall site, and you can use > Google as well as any of us can. But please let us know if you find > anything useful and I''ll add a link on the site. >Already tried google, but am getting nowhere! Also tried the netfilter web site - no joy there either. I''ll look for a newsgroup or mailing list in the hope of getting better luck. If I have time during the weekend I will be experimenting with this because if it works it will take a LOT of the headaches I''ve had in the past with VOIP away for good! ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> Alternatively, it''s more admin but also more reliable to statically > configure everything. Manually configure each SIP device to use a > different port for it''s SIP traffic, and a different port range for > it''s RTP traffic. Configure them with knowledge of their public IP, > and manually configure your firewall with all the corresponding NAT > mappings. >THAT is exactly what I have been doing for the past year or so - very painful experience, though once done it works for good (well, most of the time!). I am also strongly against using STUN as, for me, this is an abomination and should never EVER be used.> <mounts soapbox> > The real answer is to persuade the world and his dog that NAT == > Broken. By definition, NAT breaks rule 1 of IP connectivity that > requires every device to have a globally unique and routeable address. > If only as much effort was put into making IPv6 as ubiquitous as IPv4 > as is put into trying to work round (eg writing ALGs to put into NAT > gateways) the fundamental breakage of NAT then I think IPv6 would be > a lot further on than it is. >OK, I have a confession to make - when I first looked at your post, it reminded me of something, but I couldn''t put my finger on it until I came across the above paragraph and then I remembered - when I started looking over the web for more info about the above two modules I read a thread (I think it was in one of the Shorewall mailing lists from a while ago) containing a rather well-thought-out well-drilled rant by somebody (it might have been you, actually, in which case hats off to you, sir!) about SIP/NAT and the like - it made me laugh out loud because every single word of that rant was 100% true! Pure genius! ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
Mr Dash Four wrote:> > Alternatively, it''s more admin but also more reliable to statically >> configure everything. Manually configure each SIP device to use a >> different port for it''s SIP traffic, and a different port range for >> it''s RTP traffic. Configure them with knowledge of their public IP, >> and manually configure your firewall with all the corresponding NAT >> mappings. >> >THAT is exactly what I have been doing for the past year or so - very >painful experience, though once done it works for good (well, most of >the time!). I am also strongly against using STUN as, for me, this is an >abomination and should never EVER be used.I agree, STUN is an abomination. However, as long as we have NAT (also an affront to common sense) then we need tools to work around the breakage. My experience is that, given a well behaved gateway, STUN is actually highly effective. Where it breaks down is gateways that are designed by people with the strange idea that randomising ports is a good idea. When that happens, the device cannot determine it''s outside port since it will change between doing STUN and doing VOIP. For that reason I always advise strongly against having anything to do with Zyxel in your network if you also want to do VOIP. Commercial VOIP providers (we use Gradwell at work) get round these problems by providing NAT proxies that ignore the address/port combinations in the SIP packets and instead look at the actual address/port the SIP and RTP packets come from. I think you can probably tell what''s been driving me nuts for the last few years ! When I started 5 years ago, they were just experimenting with VOIP at work - and all the phones were on public IPs outside the firewall because they hadn''t (at the time) figured out how to make them work otherwise. Fortunately we had the IPs available because of our hosting services. -- 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. ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
> I think you can probably tell what''s been driving me nuts for the > last few years ! When I started 5 years ago, they were just > experimenting with VOIP at work - and all the phones were on public > IPs outside the firewall because they hadn''t (at the time) figured > out how to make them work otherwise. Fortunately we had the IPs > available because of our hosting services. >I don''t have as much experience in voip as you, but I share your sentiments. I can''t resist the itch, though, and have a go at the two modules - I just want to see what they do and how they work as I''ve never tried them before (in my own configuration even though they are loaded by Shorewall they are not ''active'' as my voip port is not 5060) - so I may as well take the plunge and see how they perform (the reason why I am so eager to get as much info about these modules as possible before I start). ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
Hi everybody, I have a very old and home made Asterisk PBX. Recently I can see other annoying server in the net are trying to register SIP accounts on the asterisk bound to my eth1 interface which has a public IP, directly connected to the router. I''m using shorewall 2.2.3 on a Debian Sarge (I said it was very old!). Yes...I''ve almost ready a pretty new PBX with Debian Lenny and Shorewall 4.0.15 but all I''d like to know is if the current "attacks" on my sip ports are due to the old kernel/shorewall or my configuration. Here the (old) cfg: Policy (everything dropped): fw all ACCEPT net all DROP info Rules (only udp traffic from my sip provider): ACCEPT net:[my authorized sip provider IP] fw udp 1024:65535 Interfaces: net eth1 detect tcpflags I''m really curious because despite this configuration I''m receiving SIP traffic from other unwanted IP. Thanx ------------------------------------------------------------------------------ Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that''s accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
On 12/22/2010 04:21 AM, d.davolio@mastertraining.it wrote:> Hi everybody, > I have a very old and home made Asterisk PBX. Recently I can see other > annoying server in the net are trying to register SIP accounts on the > asterisk bound to my eth1 interface which has a public IP, directly > connected to the router. I''m using shorewall 2.2.3 on a Debian Sarge (I > said it was very old!). Yes...I''ve almost ready a pretty new PBX with > Debian Lenny and Shorewall 4.0.15 but all I''d like to know is if the > current "attacks" on my sip ports are due to the old kernel/shorewall or > my configuration. > Here the (old) cfg: > > Policy (everything dropped): > fw all ACCEPT > net all DROP info > > Rules (only udp traffic from my sip provider): > ACCEPT net:[my authorized sip provider IP] fw udp 1024:65535 > > Interfaces: > net eth1 detect tcpflags > > I''m really curious because despite this configuration I''m receiving SIP > traffic from other unwanted IP.Hard to say without specifics. Please show us: - The output of ''iptables -L -n -v'' - The output of ''cat /proc/net/ip_conntrack'' Please collect this output when you are seeing unwanted traffic. Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that''s accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
:( Seems they don''t like my asterisk server no more. The attack is ended one day ago. As soon as it start again I''ll collect the data!! Thanks On 12/22/2010 05:17 PM, Tom eastep wrote:> On 12/22/2010 04:21 AM, d.davolio@mastertraining.it wrote: >> Hi everybody, >> I have a very old and home made Asterisk PBX. Recently I can see other >> annoying server in the net are trying to register SIP accounts on the >> asterisk bound to my eth1 interface which has a public IP, directly >> connected to the router. I''m using shorewall 2.2.3 on a Debian Sarge (I >> said it was very old!). Yes...I''ve almost ready a pretty new PBX with >> Debian Lenny and Shorewall 4.0.15 but all I''d like to know is if the >> current "attacks" on my sip ports are due to the old kernel/shorewall or >> my configuration. >> Here the (old) cfg: >> >> Policy (everything dropped): >> fw all ACCEPT >> net all DROP info >> >> Rules (only udp traffic from my sip provider): >> ACCEPT net:[my authorized sip provider IP] fw udp 1024:65535 >> >> Interfaces: >> net eth1 detect tcpflags >> >> I''m really curious because despite this configuration I''m receiving SIP >> traffic from other unwanted IP. > Hard to say without specifics. Please show us: > > - The output of ''iptables -L -n -v'' > - The output of ''cat /proc/net/ip_conntrack'' > > Please collect this output when you are seeing unwanted traffic. > > Thanks, > -Tom > > > ------------------------------------------------------------------------------ > Forrester recently released a report on the Return on Investment (ROI) of > Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even > within 7 months. Over 3 million businesses have gone Google with Google Apps: > an online email calendar, and document program that''s accessible from your > browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew > > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users-- Distinti saluti -- Daniele Davolio Information Technology Department tel: +39 0522 268059 fax: +39 0522 331673 e-mail: d.davolio@mastertraining.it web: www.mastertraining.it Master Training S.r.l. Sede Legale: via Timolini, 18 - Correggio (RE) - Italy Sede Operativa: via Sani, 15 - Reggio Emilia - Italy Sede Commerciale: via Sani, 9 - Reggio Emilia - Italy ===============================================================Le informazioni contenute in questa e-mail sono da considerarsi confidenziali e esclusivamente per uso personale dei destinatari sopra indicati. Questo messaggio può includere dati personali o sensibili. Qualora questo messaggio fosse da Voi ricevuto per errore vogliate cortesemente darcene notizia a mezzo e-mail e distruggere il messaggio ricevuto erroneamente. Quanto precede ai fini del rispetto del Decreto Legislativo 196/2003 sulla tutela dei dati personali e sensibili. This e-mail and any file transmitted with it is intended only for the person or entity to which is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure.Copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail by mistake, please notify us immediately by telephone or fax. ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl