ASA port forwarding for remote VoIP phone

[cknowlton]

I’m looking for assistance with a rule and NAT policy Attached are the ports the phone company needs forwarded. I have the static IP of their system they are testing from and a user’s home static IP. Do you have an example of how the rules should be setup? I applied the inbound rule and NAT but do not see traffic hitting the rule.

Thanks!

[nspasov]

Can you run packet-tracer command and post the output here?

[cknowlton]

I'm running packet tracer from the user's home public IP to the public IP of the ASA, I have a rule allowing this, really strange it falls under implicit deny. 

[cknowlton]

Result of the command: "packet-tracer input outside UDP 107.129.224.207 69 147.0.240.46 69"

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 147.0.240.46 using egress ifc identity

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

[cknowlton]

Here is my rule 

access-list outside_access_in line 2 extended permit udp host 107.129.224.207 eq tftp host 147.0.240.46 eq tftp (hitcnt=0) 0xdc897c27
access-list outside_access_in line 2 extended permit udp host 107.129.224.207 eq tftp host 10.10.170.53 eq tftp (hitcnt=0) 0x73a890c8

[Rob Ingram]

@cknowlton it's unlikely the source port will be "tftp", remove that, just define "tftp" as the destination port. Also use the real destination IP address (untranslated) not the public IP address.

[nspasov]

To add more detail to what Rob already outlined:

1. Your flow is being blocked by your ACL. You should adjust your ACL and remove "TFTP" as source port since the source port is going to be some random port that is picked by the client. On the other hand, TFPT for the destination port is correct since that is the port that the TFTP server is listening on

2. Do you have public IPs assigned to your devices or do you have NAT configured in place?

Thank you for rating helpful posts!

[cknowlton]

I have a NAT in place. 

When I do the packet trace it shows the NAT lookup works. 

8 (outside) to (outside) source static DavissaWAN DavissaWAN destination static interface Mitel-VoIP-Server service Mitel69 Mitel69 no-proxy-arp
translate_hits = 0, untranslate_hits = 0 

I'll revise the rule now thanks!!!

[cknowlton]

I attached my service object for TFTP I have tied to the ACL, it should be destination port 69, nothing in source ? 

[nspasov]

Can you draw up a quick diagram/sketch that shows where each device is, public/private IPs, interface names (Inside, outside, etc.), where NAT is configured, where ACL is applied and in what direction. I think this will help paint a better picture here. 

[cknowlton]

I attached a quick sketch, excuse my amateur drawling !  

[nspasov]

Thank you, this helps! One more question: Do you have a single public IP for our ASA or do you have a block that your ISP issued you? If yes, does the Mitel PBX have a public IP dedicated for it? If no, do you have any free public IPs that you can assign to it?

[cknowlton]

Currently no 255.255.255.252 is the subnet mask though so I have an additional address. 

Something to note though, they phone company has  a NAT and inbound rule already for management of the phone system ( different port, same IP ) 

attached are screen shots 

It's setup a network object NAT though, a little different than I'm used to. 

[cknowlton]

Any additional thoughts on this? Thanks for all your help! I've done NAT and inbound rules on Fortinet, SonicWall, etc. but this is the first I've done it on an ASA. 

Thanks! 

[nspasov]

Sorry, got tied up with regular work duties. You will essentially need to mimic the configuration (NAT + ACL) rules that were created for the management port for the rest of the ports required. Since you do not have any free public IPs you need to do static NATs for each port that needs to be exposed externally and then edit the ACL to allow the connection. Does that make sense?