SIP Issue w/ NAT Cisco 2600

naderz: se0/0 and se0/1 and connect to my T1 cards the fas 0/1 is connected to a layer 2 switch (Catalyst 2950) this switch is just a layer two switch. The Catalyst 2950 is connected to my CUBE.

I mentioned 67.xx.xx.197 because the ISP has given me an ip block from 67.xx.xx.193 to 67.xx.xx.198 to work with... 193 being the gateway address and 198 being the last usable IP. 197 being the address i gave to the SIP provider for the peer to peer trunk.

As for your route-map question and your NAT inside question your guess is as good as mine... this configuration was done before I came to the company and I cannot get a hold of the technician that originally configured it to see why he did it this way. I have been deconstructing it to figure out the config myself.

Is this setup operational right now for any traffic? The configuration is very curious!

This setup is operational right now. Any system put on the inside interface has access to the internet. At .194 I have an ASA 5505 running that is allowing internet access for several systems... my main concern right now is the CUBE...

Why is this so curious??

Check your ASA and confirm that ports 10000 - 20000 are allowed.

Looks like you are NATting on the router. Consider moving your NAT to the firewall instead

Check out this link
http://www.voip-info.org/wiki/view/NAT+and+VOIP

The config is from the 2600, not the ASA5505.

If the ASA does not allow the traffic, it wouldn't matter if no ACL is even used on the 2600 as it won't get there at all.

A config on the ASA might give more insight

naderz: I am not in the office this evening but I can tell you for certain that the Catalyst 2950 switch is set to work as a layer 2 switch, simply switchport access set on all ports and that is all... no vlans or anything else set on that switch. Their is no NAT occurring on the 2950, I am sure of this. The CUBE has 2 active interfaces... one has an internal IP with a 172 address the other is using a public IP of 67.xx.xx.197. Phones that are used on the 172 network are running on another switch but my concern is the traffic between the CUBE's private address and the public address in question.

I will define the route-map to utilize the 172.3 subnet. I will also set Eth 0/1 for ip nat inside, and will work on a static nat statement for the cube to the public address.

I set eth 0/1 to open all ip / tcp / and udp traffic to allow for easier passing of the sip and rtp traffic during this troubleshooting phase.

Perhaps you can shed some light on my own configuration as to why I go from a 67.xx.xx.xx network on Eth0/1 to a 216.xxx.xxx.xxx network on my multilink? As I have mentioned I am trying to paint the picture of the setup that the other technician had in mind just as much as any of the readers and authors of this post.

Akinsd: The ASA is being used by other systems downstream of the Catalyst switch for all intents and purposes it is not even seen by the CUBE which is the object of interest.

CUBE --> Catalyst 2950 --> 2600 Series router ---> Internet

OK. We are getting somewhere. Is there by any chance a diagram that we can review? Before making any changes discussed above we need to review the whole picture. The other switches and the placement of the ASA plays into this. Also, the CUBE's external facing interface should be on this 2950 pointing out not the internal (172 network). Please confirm that is the case. In that case you would not need the static NAT.

Please post a more complete picture including the other switches and the ASA's placement so that we can proceed.

I will try to get a diagram uploaded today.

Its a rough drawing but should show you the layout. I do not have Visio at home to get you a proper drawing...

1) Need to look into an L3 etherchannel once I get this system to work

2) Yes the 2950 has 1 VLAN and is acting as a L2 switch

3) The ASA is NATing traffic from the 172 network to the 67 network correctly (as you mentioned not applicable to CUBE traffic)

4) The CUBE looks to be correctly configured using the address scheme you mention, the phones look correct as well.

1. The Eth 0/1 would need to be the "ip nat inside".
2. You need to define the route-map INTERNET-TRAFFIC and specify the 172.3. as the source.
3. You will need a static NAT statement for the CUBE address (172.3x.x.4) to the 67.xx.xx.197 public address.

Are these recommendations still applicable seeing what you have seen?

I can ping 67.x.x.197 (outside interface on CUBE) from 216.x.x.117 (Multilink interface)... I cannot ping the inside interface of the CUBE 172.x.x.4 from anywhere within the router.

From what I was told by the SIP provider when we last spoke the issue was involving a NAT on our side. We could send the initial invite from the CUBE but no response could make it back to the CUBE.

I know NAT and SIP do not play nice together but I have a nagging feeling that something is being missed on the router and I just do not know what.

OK. So you do have connectivity between the two. Not pinging the 172. address is OK. That is expected.

Yes, NAT could be an issue. But, in your case you are not NATing CUBE's address in the router. Your regular 172. traffic is being NATed on the ASA. The router's interfaces E0/1 and the Multilink 1 are both "ip nat outside". So, the CUBE's traffic is not being NATed in the router.

In fact, the CUBE's external address is a public IP address and no NATing is necessary.

You need to review the CUBE's configuration again with either Cisco or the SIP provider. Remind them that the router is NOT NATing the CUBE's IP address. The CUBE does allow "address hiding" and NAT traversal that could be the issue.

Check your route statements. If you can't ping an address within your network. You may not have appropriate routes back and forth - this is assuming icmp packets or other tcp are not blocked by any acl.

I've removed the NAT statements from the inside and outside interfaces... I'll be testing more later today.

As a test I corrected the config and fixed the NAT overload statement. When I did that all outgoing traffic worked correctly but I could not access anything with a 67.x.x.19x address. After seeing that issue I removed the NAT overload statement..

Check your route statements. If you can't ping an address within your network. You may not have appropriate routes back and forth - this is assuming icmp packets or other tcp are not blocked by any acl.

Not sure what you mean by this which routes do you have in mind?

We will have to review the CUBE configuration again as well.

I am betting on the CUBE not being configured correctly.

My colleague which is also much more proficient with the CUBE is traveling overseas. I am trying to get his time to look at this issue via a VPN tunnel I have configured. Hopefully he will shed some light on the issue for me and will allow me to speak more clearly about the configuration on the CUBE.

For now I am going to attempt some more work on the router, configuring the NAT overload statement causes headaches for me for VPNs (L2L and RA), inbound FTP traffic, and SIP. I would like to configure it this way but I need to take some time to develop all the necessary access-lists and test when I have time due to the production nature of the environment.

I will continue to update this thread regarding the network as updates occur. Thank you for the help so far.

Very good. I still think that NAT on the router is not involved her. Please confirm the NAT statements on the ASA. I am willing to bet that the ASA is where you are NATing all your traffic and not on the router. This means the CUBE is not NATed and should not be since its interface is on a public IP address. The CUBE handles all 172. IP phone address to 67. address translation internally.

Yes you are correct the NAT is taking place on the ASA for the 67 to the 172 and the CUBE is not part of that equation considering one interface is directly connected to the 67 IP block...

The NAT I am referring to is the 216 to 67. It looks like my ISP has given me a single IP address to use within the 216 network I'm guess for point to point on their router. The 67 IP range is where I have 5 usable addresses. It would be my understanding that the router should include a statement NATing all 67 addresses to the Multilink interface with the 216 address. The fact that it works without that statement actually confuses me and I'm trying to find some literature that explains why my router is even working correctly. My only guess is due to my route statement that tells all packets to go out via the 216. An updated config is included... I cleaned up a few things (removed route-map and NAT statements on Eth0/1 and Multilink) but it is similar to the original post.

version 12.3
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname RouterXO
!
boot-start-marker
boot-end-marker
!
enable secret 5 xxxxxxx
!
memory-size iomem 10
no aaa new-model
ip subnet-zero
ip cef
!
ip domain name xxxx.local
ip name-server 65.xxx.yyy.196
ip name-server 65.xxx.yyy.196
!
ip audit po max-events 100
!
username xxxxx password 0 xxxxxx
!
class-map match-all inspection_default
!
policy-map global_policy
  class inspection_default
!
crypto isakmp policy 1
 encr 3des
 hash md5
 authentication pre-share
 group 2
!
crypto ipsec transform-set TRANS-ESP esp-3des esp-md5-hmac
crypto ipsec transform-set TRANS-ESP2 esp-3des esp-md5-hmac
!
interface Multilink1
 description multilink PPP connection
 ip address 216.xxx.yyy.118 255.255.255.252
 ip access-group 100 in
 ip access-group 100 out
 no ip proxy-arp
 no ip mroute-cache
 no cdp enable
 ppp multilink
 ppp multilink group 1
!
interface Ethernet0/0
 no ip address
 ip access-group 100 in
 ip access-group 100 out
 no ip mroute-cache
 shutdown
 full-duplex
 no keepalive
 no cdp enable
!
interface Serial0/0
 description first multilink connection
 no ip address
 no ip proxy-arp
 encapsulation ppp
 no ip mroute-cache
 load-interval 30
 no keepalive
 no fair-queue
 no cdp enable
 ppp multilink
 ppp multilink group 1
!
interface Ethernet0/1
 description public interface to bonded T1
 ip address 67.xxx.yyy.193 255.255.255.248
 ip access-group 100 in
 ip access-group 100 out
 no ip mroute-cache
 full-duplex
 no cdp enable
!
interface Serial0/1
 description second multilink connection
 no ip address
 no ip proxy-arp
 encapsulation ppp
 no ip mroute-cache
 load-interval 30
 no keepalive
 no fair-queue
 no cdp enable
 ppp multilink
 ppp multilink group 1
!
no ip http server
no ip http secure-server
ip classless
ip route 0.0.0.0 0.0.0.0 216.xxx.yyy.117
!
access-list 100 permit ip any any
access-list 100 permit tcp any any
access-list 100 permit udp any any
access-list 100 permit icmp any any
no cdp run
!
line con 0
line 33 64
line aux 0
line vty 0 4
 privilege level 15
 password xxxxxxx
 login local
 transport preferred ssh
 transport input ssh
!
end

Select allOpen in new window

The 216.x and the 67.x addresses are both from the same ISP; correct?

I am assuming they are because otherwise nothing would work. The way it works is your ISP will route all traffic for your allocated subnet of 67.x.x.192 /29 to 216.xxx.yyy.118. Your router will then route to its connected interface (E0/1). That's how your existing traffic works. Your ASA is NATing 172. to 67. and the router then routes in and out accordingly. No NATing between 67. and 216. is necessary.

Your CUBE being on the 67.x network, on the external side, does have L3 connectivity: you can ping the 216. address from the CUBE; correct? What is braking down is the CUBE establishing and making the SIP connection. That's what they need to look at: ISP/Cisco.

naderz: thanks for the brief clarification. Once my co-worker has a chance to look at the CUBE I'll be in a better place to ask more intelligent questions regarding the issue.