Dynamic NAT rule on second interface breaks first interface NAT

Answered Question
May 20th, 2010

I have a Cisco ASA 5510 and i'm trying to add a dynamic NAT rule on a sub-interface so that internet traffic will work.  When i add the rule it is breaking VoIP inbound calls on a different sub-interface.  The VoIP is setup using Asterisk and Sipgate and is working via dynamic nat as there is no inbound rules for it.

Below is more detail on the setup

the 'inside' interface is where the Asterisk server is located.

interface Ethernet0/0

nameif outside

security-level 0

ip address *.*.*.161 255.255.255.255

!

interface Ethernet0/1

no nameif

no security-level

no ip address

!

interface Ethernet0/1.1

vlan 1

nameif inside

security-level 100

ip address 192.168.1.254 255.255.255.0

!

interface Ethernet0/1.2

vlan 10

nameif inside2

security-level 100

ip address 172.0.0.254 255.255.0.0

With the following NAT rules setup for the inside interface:

global (outside) 1 interface

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 1 0.0.0.0 0.0.0.0

and this works except no internet access on the inside2 interface, i need to add the following rule:

nat (inside2) 1 0.0.0.0 0.0.0.0 tcp 0 0 udp 0

but when i do this i get the following errors

4 May 20 2010 19:41:45 106023 *.*.*.226 5061 *.*.*.161 40576 Deny udp src outside:*.*.*.226/5061 dst inside2:*.*.*.161/40576 by access-group "outside_access_in" [0x0, 0x0]

The device that it should get to is on the inside interface, not inside2. So how is this happening??

When i remove the nat rule on inside2 the inbound calls work fine and we are back to the start.

I have this problem too.
0 votes
Correct Answer by Panos Kampanakis about 6 years 6 months ago

By adding

nat (inside2) 1 0.0.0.0 0.0.0.0 tcp 0 0 udp 0

the asa knows that it needs to translate the inside2 hosts.

But the ASA inspection should be opening pinholes for your sip traffic.

It looks like the inspection is opening a pinhole for the wrong interface.

Can you check what the routing table says for the *.*.*.161? The ASA needs to know if is behind the inside to open the pinhole properly.

I hope it helps.

PK

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
Correct Answer
Panos Kampanakis Thu, 05/20/2010 - 15:46

By adding

nat (inside2) 1 0.0.0.0 0.0.0.0 tcp 0 0 udp 0

the asa knows that it needs to translate the inside2 hosts.

But the ASA inspection should be opening pinholes for your sip traffic.

It looks like the inspection is opening a pinhole for the wrong interface.

Can you check what the routing table says for the *.*.*.161? The ASA needs to know if is behind the inside to open the pinhole properly.

I hope it helps.

PK

BrulinesCisco Thu, 05/20/2010 - 16:10

the routing table is as follows:

Gateway of last resort is *.*.*.174 to network 0.0.0.0


C    172.0.0.0 255.255.0.0 is directly connected, inside2

C    *.*.*.160 255.255.255.240 is directly connected, outside

S*   0.0.0.0 0.0.0.0 [1/0] via *.*.*.174, outside

C    192.168.0.0 255.255.255.0 is directly connected, inside

there is the following todo with SIP and inspection policies:

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

class-map global-class

match access-list global_mpc

class-map inspection_default

match default-inspection-traffic

!

!

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum 512

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect rsh

  inspect rtsp

  inspect sqlnet

  inspect skinny 

  inspect sunrpc

  inspect xdmcp

  inspect sip 

  inspect netbios

  inspect tftp

  inspect icmp

  inspect pptp

class global-class

  csc fail-open

!

Cheers

Panos Kampanakis Fri, 05/21/2010 - 13:34

I would suggest "sh xlate detb | i *.*.*.161" and "sh conn detail | i *.*.*.226" while the issue is happening. And also a "debug sip".

Those will show what connections and xlates are set for these ip addresses nd what pinholes are opened dynamically.

also a test to try would be to make your nats (inside) and (inside2) more explicit so they only contain the subnets for the internal hosts behind these interfaces only. Because sometimes overlapping nats could relate to pinholes not opened properly with inspections.

I hope it helps a little
.

PK

BrulinesCisco Fri, 05/21/2010 - 15:28

Hi PK,

After reading your first post i looked more into the SIP inspections and i modified the inspection so that it is specific to the inside interface, using similar commands to below:

hostname(config)# policy-map global_policy

hostname(config-pmap)# class-map inspection_default

hostname(config-pmap)# no inspect sip

hostname(config-pmap)#exit

hostname(config)# policy-map sip_policy

hostname(config-pmap)# class-map inspection_default

hostname(config-pmap)# inspect sip

hostname(config-pmap)#exit

hostname(config)#service-policy sip_policy interface [interface]

the above was copied from https://supportforums.cisco.com/docs/DOC-3866/version/1;jsessionid=0886E587D5D5E9BE05A4CAC899B85564.node0

i had to change class-map to just class if i remember correctly.

Thanks for your help.

Dan

Actions

This Discussion

Related Content