STATIC NAT PROBLEM

[veltech]

Hi All,

We are having a problem with a static NAT statement and or ACL not allowing traffic to the port configured to the inside host on the LAN.

NETWORK SETUP

We have a 3CX IP PBX behind a Pix firewall and need remote hosts to be able to connect to the 3CX over the 3CX tunnel protocol that uses port 5090. 3CX internal IP Address is 172.16.0.254 and the port it is listening on for the tunnel traffic is 5090. We have configured static NAT to the 3CX which is listening on port 5090 and created the ACL and applied this to the Outside interface. 3CX tunnel protocol uses a mixture of TCP and UDP so we have these both configured. Here are the various lines of configuration.

access-list Outside_In extended permit tcp any host 172.16.0.254 eq 5090

access-list Outside_In extended permit udp any host 172.16.0.254 eq 5090

static (Inside,Outside) tcp interface 5090 172.16.0.254 5090 netmask 255.255.255.255

static (Inside,Outside) udp interface 5090 172.16.0.254 5090 netmask 255.255.255.255

access-group Outside_In in interface Outside

ISSUE

We have configured static NAT to the 3CX which is listening on port 5090 and created an ACL to permit inbound traffic to the 3CX. Inbound traffic is not traversing the firewall and therefore not reaching the 3CX on the inside LAN.

TROUBLE SHOOTING SO FAR

We have tried a number of different ACL and NAT configurations, but the above configs are not permitting the traffic through the firewall. We have done a number of captures on the firewall and we can see the traffic from remote hosts getting to the Outside interface, but not traversing to the Inside interface and therefore not reaching the 3CX on the inside LAN. The xlate shows the static NAT entry correctly.

Any suggestions anyone??

Regards,

[Jouni Forss]

Hi,

I dont know what different configurations you have tried but the above ACL atleast for the "outside" interface is wrong.

In the older software with the above NAT configuration format you use the NAT IP address as the destination for your ACL statements, not the Real IP of the host.

The Real IP of the host is used in softwares 8.3 and after.

I can't see anything wrong with the Static PAT / Port Forward configuration above.

Have you tried the "packet-tracer" command to troubleshoot your configuration?

Format would be

packet-tracer input Outside

You could post the output of the above command (with the info you have inserted to the command)

If the above command output doesnt list anything that would indicate a problem with firewal configuration I would try to use ASDM (if possible) to watch the logs in real time and see if there is any other connections attempted to the device. This just incase if there is actually additional ports required.

- Jouni

[veltech]

Hi Jouni,

Thanks for your reply.

Just to clarify that the Pix is running 8.0 (4) which I believe accepts the ACLs in the format we have written. Also, all other ACLs for SIP as an example point towards the single address 172.16.0.254 as the destination. Would you be kind enough to expand on why you think the ACLs are wrong, maybe post a suggested syntax for us to try. To assist here are some of the variations we tried during trouble shooting.

access-list Outside_In extended permit tcp interface Outside eq 5090 interface Inside eq 5090

access-list Outside_In extended permit udp interface Outside eq 5090 interface Inside eq 5090

access-list Outside_In extended permit tcp any 172.16.0.0 255.255.255.0 eq 5090

access-list Outside_In extended permit udp any 172.16.0.0 255.255.255.0 eq 5090

access-list Outside_In extended permit udp any interface Inside eq 5090

access-list Outside_In extended permit tcp any interface Inside eq 5090

We will get a packet tracer session in the Lab done tomorrow.

Regards,

[Jouni Forss · Accepted solution]

Hi,

If you are doing a Static NAT or Static PAT towards the Internet on your ASA or PIX, this is how the different firewall software versions behave

• Software 8.2 and earlier: When you configure a Static NAT / Static PAT and want to allow traffic from the Internet to the NATed host, you use the NAT IP address as the destination IP address in the ACL attached to the "outside" interface you are using.
• Software 8.3 and later: NAT and ACLs changed in the 8.3 software and in those software levels you are required to use the actual real IP address of the host in the ACLs you configure. Using the NAT IP address in the newer software levels wont work anymore.

As you mentioned your software level to be 8.0 we can see that you need to use the NAT IP address as the destination address of the "outside" interface ACL.

I guess you could try for example

access-list Outside_In permit tcp any interface Outside eq 5090

access-list Outside_In permit udp any interface Outside eq 5090

You can also use the "packet-tracer" command like I mentioned above to simulate what the firewall would do to the traffic.

The command tested could be for example

packet-tracer input Outside tcp 1.2.3.4 1234 5090

The only situation where I could see the need to use the real IP address in the ACL statement of the "outside" interface would be if you had a L2L VPN / Site-to-Site VPN configured between your firewall and the remote end. But as I cant see your configuration I dont know if thats the case. Though since you have configured Static PAT to use the public IP address of your firewalls "outside" interface it would lead me to believe that you are trying to open/share this service from the LAN device to the Internet.

Guess you could next try the above mention ACL lines I listed and test the traffic again. Also the "packet-tracer" command should tell you if theres any problems with your firewall configurations.

- Jouni

[veltech]

Hi Jouni,

We entered the ACLs you suggest and it now works fine thank you. I have selected correct answer on this thread.

Interestingly though we do have static NAT and ACLs working well together for other traffic coming into the SIP server on 172.16.0.254 in which we have used the destination address within the ACL. I think the difference is to do with the dynamic nature of the outside hosts trying to connect, whereas the other ACLs we have are all using fixed addresses as the source. I will lab this up tomorrow using packet tracer to see what is happening and will also review the books on this one.

Thanks again.