I have spent the last few days trying to get my VoIP box exposed to the internet using a static public IP and port forwarding. However, most of the posts I have read thus far only deal with forwarding one or two ports, usually a single IP on the outside, and mostly just traffic from outside to inside. In my scenario, I need to statically NAT traffic from the VoIP box inside at 192.168.9.9 to a public IP on the outside on the same subnet as the ASA outside interface (66.x.x.0 / 24) where .2 is the ASA, .3 is the VoIP server. I have created my static NAT, object-group for services and ACLs. I can connect to my outbound VoIP proxy (ITSP) and make a call, but I get no audio. The Allworx uses udp ports 15000-15511 for RTP, and this is exactly what I'm forwarding as a range. My config is posted below. Do I need a static NAT in both directions? Should I use a nat (inside) and global (outside) for outbound and static NAT for the return? Is port forwarding a range even possible? I have tried many different variations of my config to no avail. One other burning question is this:
Viewing the log during the setup the ASA indicates that my RTP traffic is denied by the inbound ACL on the inside interface. Is this still required if I'm using a static NAT and allowing that traffic to the outside interface? I thought that by using static NAT you're creating the bit pipe or hole through the firewall, and all that was necessary was an ACL permitting traffic to the pipe entry, and that it would then reach the inside device without the need for an ACL on the inside interface. What is more, the ASA wants me to permit traffic inbound to the inside interface when the source is inside and the destination is outside. Why on earth would I need an inbound ACL on the inside interface for traffic that needs to leave the inside interface?
: Saved : ASA Version 8.2(1) ! hostname asa5505 domain-name vpnsystems.vpn enable password 5Guh/zkcc.rD2nN1 encrypted passwd 2KFQnbNIdI.2KYOU encrypted names name 192.168.9.9 Allworx_Inside description Allworx Inside name 66.x.x.3 Allworx_Outside description Allworx Outside name 66.x.x.2 ASA5505_Outside description ASA5505 Outside
Sorry about the ACL inside_access_in. I removed it from the config b/c I didn't think I needed it. As for sip inspection, Allworx support told me I had to remove it in order for their product to work. The Allworx uses sip to register to the ITSP and that works. Call setup is fine. It's the RTP audio that doesn't work. I also didn't understand the need for the inside_access_in ACL governing traffic from and inside host to an outside host, that should be implicitly allowed. Look again closely at the log entry I posted. The ASA is blocking udp traffic coming into the inside interface, but states that the source is an inside host destined for an outside host. That is totally backwards and makes no sense to me. If the ASA is complaining about inbound traffic to the inside interface, I would expect the source to be outside, destination inside.
2. opens pin holes to allow flow on a diff. source port
Now, there was an acl applied on the inside interface and you do not have sip inspection enabled. There was no acl allowing the flow and there was no inspection to automatically allow the traffic from inside to outside.
With no acl applied on the inside interface now, try the flow again and see if it works.
I don't see anything wrong in the syslog. The ACL is blocking the voice traffic going from inside to outside - due the fact acl wasn't allowing because inspection wasn't there to automatically allow the flow when the acl wasn't specifically allowing.
The rule if you remove inspection then you need allow permission via access-list.
Ok, so the reason why the ACL is necessary is because it is the RETURN traffic in a flow?
I thought there was no need to permit with an ACL traffic flowing from a high to low zone? Is that only for traffic initiated by the inside interface?
The issue isn't with SIP (udp 5060), it's with the RTP traffic (udp 15000-15511). I need to NAT the traffic on the way out from 192.168.9.9 to 66.x.x.3 and on the way back in (66.x.x.3 to 192.168.9.9). Will the static command take care of this bi-directional flow? Or do I need a nat (inside) / global (outside) pairing for traffic leaving the firewall, and the static for return traffic? Should the port-object range work for this? Or will this not work without being able to inspect the RTP traffic?
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...