Solved: Dynamic NAT rule on second interface breaks first interface NAT

BrulinesCisco · ‎05-20-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.

Panos Kampanakis · ‎05-20-2010

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

View solution in original post

Panos Kampanakis · ‎05-20-2010

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 · ‎05-20-2010

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 · ‎05-21-2010

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 · ‎05-21-2010

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

Panos Kampanakis · ‎05-21-2010

Nice!

It had to be the inspection!

Rgs,

PK