SIP trunk

[cchaney]

Yea, I should have known that

Yes, does look like a tracert is pushing it out the MBG WAN interface and not via the ASA.

[martyn]

ok cool, try adding that IP address with a subnet mask of 255.255.255.255 to the local LAN's list, either through the shell or via the web interface.

[cchaney]

Added that route, 216.82.224.202 going out 10.1.2.1 (ASA gateway address) and it added the route to the eth0 interface (LAN .. which is configured as 10.1.2.10 for MAS and 10.1.2.2 for MCD .. eth1 is the WAN, going directly to the ISP, bypassing the ASA). 

Doing a tracert still puts it out the WAN interface (looks like its using the default gw route to go out still) -- goes directly through ISP and not through ASA.


When I try to add the route to the eth1 interface, it fails due to 'Network is unreachable':
[root@mascgy ~]# route add -net 216.82.224.202 netmask 255.255.255.255 gw 10.1.2.1 dev eth1
SIOCADDRT: Network is unreachable

[root@mascgy ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
216.82.224.202  10.1.2.1        255.255.255.255 UGH   0      0        0 eth0
10.1.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
68.179.0.0      0.0.0.0         255.255.224.0   U     0      0        0 eth1
10.1.0.0        10.1.2.1        255.255.0.0     UG    0      0        0 eth0
0.0.0.0         68.179.x.xx     0.0.0.0         UG    0      0        0 eth1


[root@mascgy ~]# ip route
216.82.224.202 via 10.1.2.1 dev eth0
10.1.2.0/24 dev eth0  proto kernel  scope link  src 10.1.2.10
68.179.0.0/19 dev eth1  proto kernel  scope link  src 68.179.x.xx
10.1.0.0/16 via 10.1.2.1 dev eth0
default via 68.179.x.xx dev eth1



Would I need to be changing the default gw on the MAS to be pointing to the ASA (10.1.2.1) instead of the WAN gw?

[martyn]

You can do it this way via the route command, but the supported way is to add it via local networks. Try it through that and see if it makes a difference to it accepting it.

[cchaney]

I added the route via the Local Networks on the web page, which added it to eth0 -- I was just trying to manually add it to eth1 using the route command

[martyn]

There isn't a routing table for each interface, there is one routing table for the system, so it didn't add it for eth0 as such, but for the whole system.

I assume that the 10.1.2.1 address is the interface on the ASA for that vlan, or is it another router?

Can you paste an output from the trace route?

[cchaney]

When you look at the 'route -n' and 'ip route' commands issued, you can see the route says 'use iface eth0' -- so that is where I was getting the 'adding it to eth0' LAN interface

And yes, 10.1.2.1 is the interface of the voice VLAN on the ASA.


[root@mascgy ~]# tracert 216.82.224.202
traceroute to 216.82.224.202 (216.82.224.202), 30 hops max, 40 byte packets
 1  static-68-179-x-xx.ptr.terago.net (68.179.x.xx)  1.663 ms  1.853 ms  2.118 ms
 2  10.64.9.29 (10.64.9.29)  3.790 ms  3.797 ms  3.872 ms
 3  static-67-226-180-150.ptr.terago.net (67.226.180.150)  16.661 ms  16.668 ms  16.662 ms
 4  static-67-226-180-141.ptr.terago.net (67.226.180.141)  16.517 ms  16.522 ms  16.615 ms
 5  static-67-226-180-102.ptr.terago.net (67.226.180.102)  16.282 ms  16.288 ms  16.407 ms
 6  static-67-226-180-54.ptr.terago.net (67.226.180.54)  19.911 ms  19.732 ms  19.718 ms
 7  te3-2.207.ccr01.sea02.atlas.cogentco.com (38.104.124.129)  224.434 ms  153.129 ms  153.072 ms
 8  te2-8.ccr01.sea01.atlas.cogentco.com (154.54.85.177)  127.776 ms  127.776 ms  127.827 ms
 9  te0-0-0-7.ccr21.slc01.atlas.cogentco.com (154.54.29.221)  42.027 ms  42.031 ms  42.022 ms
10  te9-1.ccr01.den01.atlas.cogentco.com (154.54.87.17)  251.644 ms te2-1.ccr02.den01.atlas.cogentco.com (154.54.87.21)  96.912 ms te3-3.ccr02.den01.atlas.cogentco.com (154.54.3.13)  96.975 ms
11  te0-3-0-7.ccr21.mci01.atlas.cogentco.com (154.54.87.86)  63.934 ms te0-3-0-7.ccr22.mci01.atlas.cogentco.com (154.54.87.94)  63.675 ms  63.607 ms
12  te0-7-0-33.ccr22.ord01.atlas.cogentco.com (154.54.30.102)  76.496 ms te0-4-0-3.ccr21.ord01.atlas.cogentco.com (154.54.6.157)  75.842 ms te0-7-0-33.ccr22.ord01.atlas.cogentco.com (154.54.30.102)  75.497 ms
13  te0-0-0-15.ccr22.jfk02.atlas.cogentco.com (154.54.43.109)  95.192 ms te0-1-0-4.ccr22.jfk02.atlas.cogentco.com (154.54.43.101)  95.082 ms te0-7-0-15.ccr21.jfk02.atlas.cogentco.com (154.54.43.97)  95.093 ms
14  te0-6-0-0.ccr21.jfk04.atlas.cogentco.com (154.54.47.22)  95.258 ms te0-6-0-2.ccr21.jfk04.atlas.cogentco.com (154.54.47.26)  94.896 ms te0-1-0-0.ccr21.jfk04.atlas.cogentco.com (154.54.47.18)  94.980 ms
15  38.104.72.254 (38.104.72.254)  95.059 ms  94.848 ms  95.209 ms
16  67.231.9.222 (67.231.9.222)  94.655 ms  94.653 ms  94.616 ms
17  67.231.9.212 (67.231.9.212)  95.367 ms  95.219 ms  95.205 ms
18  67.231.9.202 (67.231.9.202)  95.867 ms  95.514 ms  95.482 ms
19  sp-udp01.iad.bandwidth.com (216.82.224.202)  95.087 ms  95.191 ms  95.279 ms
[root@mascgy ~]#

[cchaney]

Would you mind posting the config guide for Bandwidth?  From the SIP compatibility sheet, looks like 08-4940-00030 is the config guide and it does say teleworker compatible.

I've seen a few other guides out there for other providers but just want to review our setup (especially anything dealing with the MBG).

[cchaney]

Not sure how but for a brief moment earlier, when doing a tracert to the Bandwidth SIP Proxy, it looked to be going out the right path -- tested a TW call and had two way audio (TW from one of the corporate offices, which have a VPN tunnel between them, but still hooks up via the MBG public IP).

Went back to the shell a moment or two later, did a tracert, this time back out eth1 (WAN) interface.  No more two way audio.

I also called Bandwidth and had them also add the public address for the MBG (instead of just the PABX), in case that would help.

[martyn]

Hmm interesting. Might pay to do another tcpdump from the MBG box to see if anything has changed now with the responses from Bandwidth.

Will find the interop doc for you shortly.

[cchaney]

Thanks -- will need to do some tcpdumps on the MBG itself -- most of my captures have been from my switch and port mirroring the inside/outside interface of the ASA

Any good suggestions on tcpdumps to filter out what we are looking for?  And I'm guessing I should be dumping eth1 (WAN) and not eth0 (LAN) since I'm already seeing the eth0/LAN traffic from my port mirroring capture...


And just to clarify, when I tested the call from an internal TW phone (as mentioned earlier, has VPN between the sites but connected to MBG WAN address) and go two way audio, it was because I called a number that was in one of my other divisions.. I still only get one way audio for other external calls (and also from my external TW phone at home to the same number tested above, the other division).


I am planning on rebooting the MAS/MBG later today -- sometimes when adding static routes in linux you have to restart the networking.. not sure if that is part of the web GUI when adding new routes (and referring to the Bandwidth 255.255.255.255 route pointing to the ASA).

[martyn]

Ah ok yep that makes sense that internal calls work fine, but calls to bandwidth are the issue.

Reboot can't hurt, but shouldn't be needed!  Let us know how you go!

[cchaney]

Sorry should have been more clear -- too much going on =\

The internal call was from my office TW device to an external AT&T number, via the Bandwidth Trunk.  The AT&T number is being forwarded to a DID where the PABX is installed (same one with SIP trunk configuration).  That DID then rings the headset for the remote worker (also part of the VPN corporate network). 

Going through the interop guide now -- thanks a bunch!

[martyn]

Hmm ok, an interesting loop! 
 
I'd suggest keeping it simple whilst trying to troubleshoot and just call your mobile as a test, as creating a loop could have added issues and lead you off on a different path rather than focusing on a normal call scenario.

[cchaney]

Agreed -- I jumped the gun and didn't realize I was even calling that number.. and then all of a sudden got two way audio.. at first was like BINGO, but then realized why it worked