05-20-2010 01:09 PM - edited 03-11-2019 10:49 AM
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.
Solved! Go to Solution.
05-20-2010 03:46 PM
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
05-20-2010 03:46 PM
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
05-20-2010 04:10 PM
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
05-21-2010 01:34 PM
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
05-21-2010 03:28 PM
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
05-21-2010 04:30 PM
Nice!
It had to be the inspection!
Rgs,
PK
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: