cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10017
Views
64
Helpful
37
Replies

Ask the Expert: Troubleshooting Adaptive Security Appliances (ASA), Private Internet Exchange (PIX) and Firewall Service Modules (FWSM)

ciscomoderator
Community Manager
Community Manager

Kureli SankarWith Kureli Sankar

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask any questions about adaptive security appliances (ASAs), Private Internet Exchange (PIX), and firewall services modules (FWSMs) with Cisco Expert Kureli Sankar. This is a continuation of the live Webcast. 

Kureli Sankar is an engineer supporting Cisco's firewall team in Research Triangle Park, North Carolina. Her team supports the Cisco ASA, FWSM, Cisco Security Manager, the Content Security and Control module, and the zone-based firewall module in Cisco IOS Software. Prior to joining Cisco, Sankar worked for the John Morrell Co., where she was the network administrator in charge of the company's enterprise network covering 27 locations in the United States. She also was an adjunct professor at the University of Cincinnati, teaching undergraduate-level networking courses. Sankar holds a degree in electrical and electronic engineering from Regional Engineering College, Trichirappalli, India, and holds CCSP and CCIE Security (#35505) certification.

Remember to use the rating system to let Kureli know if you have received an adequate response. 

Kureli might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Security sub-community discussion forum shortly after the event.  This event lasts through January 25, 2013. Visit this forum often to view responses to your questions and the questions of other community members.

Webcast related links:

37 Replies 37

mj11
Level 3
Level 3

Hi Kureli

Subject: FWSM 3.2(20) SIP traffic being dropped by FW. Inspection SIP enabled.

Source: 192.168.5.101 Destination:192.168.254.26

Cap SIP1= Receiving interface Cap SIP2=Exiting interface

We are experiencing a problem passing SIP packets through our FWSM on a new service but have SIP already working successfully. We can see the packets arriving at the firewall but not leaving and have not been unable to determine why this is, we have captured on the ASP but did not see anything. We have tried both UDP and TCP. Interestingly, if we telnet using port 5060, the packets pass fine, however when actual SIP packets are sent, they do not arrive. Below is a packet capture from the FWSM on both interfaces.

FW01# sh cap SIP1 detail

26 packets seen, 26 packets captured

   1: 15:03:48.2232889848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#810 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id6762)

   2: 15:03:48.2232889848 0008.7cbb.2040 0000.0c07.ac62 0x8100 78: 802.1Q vlan#810 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6762)

   3: 15:03:49.2232890848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#810 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6767)

   4: 15:03:49.2232890848 0008.7cbb.2040 0000.0c07.ac62 0x8100 78: 802.1Q vlan#810 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6767)

   5: 15:03:50.2232891848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#810 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6771)

   6: 15:03:50.2232891848 0008.7cbb.2040 0000.0c07.ac62 0x8100 78: 802.1Q vlan#810 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6771)

   7: 15:03:51.2232892858 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#810 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6775)

   8: 15:03:51.2232892858 0008.7cbb.2040 0000.0c07.ac62 0x8100 78: 802.1Q vlan#810 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6775)

   9: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 70: 802.1Q vlan#810 P0 192.168.5.101.50505 > 192.168.254.26.5060: S

2621387575:2621387575(0) win 8192 (DF) (ttl 127, id 6935)

  10: 15:04:57.2232958948 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: S [tcp sum ok]

3750378220:3750378220(0) ack 2621387576 win 4128 (ttl 252, id 26637)

  11: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#810 P0 192.168.5.101.50505 > 192.168.254.26.5060: . [tcp sum ok]

2621387576:2621387576(0) ack 3750378221 win 65392 (DF) (ttl 127, id 6936)

  12: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 353: 802.1Q vlan#810 P3 192.168.5.101.50505 > 192.168.254.26.5060: P

2621388112:2621388407(295) ack 3750378221 win 65392 (DF) [tos 0x60]  (ttl 127, id 6938)

  13: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 594: 802.1Q vlan#810 P3 192.168.5.101.50505 > 192.168.254.26.5060: .

2621387576:2621388112(536) ack 3750378221 win 65392 (DF) [tos 0x60]  (ttl 127, id 6937)

  14: 15:04:57.2232958958 0008.7cbb.2040 00aa.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: P [tcp sum ok]

3750378221:3750378221(0) ack 2621387576 win 4128 (DF) (ttl 255, id 8467)

  15: 15:04:57.2232958958 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: . [tcp sum ok]

3750378221:3750378221(0) ack 2621388112 win 8192 (DF) (ttl 255, id 8468)

  16: 15:04:57.2232958958 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: . [tcp sum ok]

3750378221:3750378221(0) ack 2621388407 win 8192 (DF) (ttl 255, id 8469)

  17: 15:04:57.2232958958 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50505: R [tcp sum ok]

3750378221:3750378221(0) win 8192 (DF) (ttl 255, id 8470)

  18: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 70: 802.1Q vlan#810 P0 192.168.5.101.50508 > 192.168.254.26.5060: S

3408136717:3408136717(0) win 8192 (DF) (ttl 127, id 6990)

  19: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: S [tcp sum ok]

455106242:455106242(0) ack 3408136718 win 4128 (ttl 252, id 39032)

  20: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#810 P0 192.168.5.101.50508 > 192.168.254.26.5060: . [tcp sum ok]

3408136718:3408136718(0) ack 455106243 win 65392 (DF) (ttl 127, id 6991)

  21: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 352: 802.1Q vlan#810 P3 192.168.5.101.50508 > 192.168.254.26.5060: P

3408137254:3408137548(294) ack 455106243 win 65392 (DF) [tos 0x60]  (ttl 127, id 6993)

  22: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 594: 802.1Q vlan#810 P3 192.168.5.101.50508 > 192.168.254.26.5060: .

3408136718:3408137254(536) ack 455106243 win 65392 (DF) [tos 0x60]  (ttl 127, id 6992)

  23: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: P [tcp sum ok]

455106243:455106243(0) ack 3408136718 win 4128 (DF) (ttl 255, id 23984)

  24: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: . [tcp sum ok]

455106243:455106243(0) ack 3408137254 win 8192 (DF) (ttl 255, id 23985)

  25: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: . [tcp sum ok]

455106243:455106243(0) ack 3408137548 win 8192 (DF) (ttl 255, id 23986)

  26: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.ac62 0x8100 64: 802.1Q vlan#810 P0 192.168.254.26.5060 > 192.168.5.101.50508: R [tcp sum ok]

455106243:455106243(0) win 8192 (DF) (ttl 255, id 23987)

26 packets shown

FW01# sh cap SIP2 detail

16 packets seen, 16 packets captured

   1: 15:03:48.2232889848 0008.7cbb.2040 0000.0c07.acff 0x8100 78: 802.1Q vlan#800 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6762)

   2: 15:03:48.2232889848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#800 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6762)

   3: 15:03:49.2232890848 0008.7cbb.2040 0000.0c07.acff 0x8100 78: 802.1Q vlan#800 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6767)

   4: 15:03:49.2232890848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#800 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6767)

   5: 15:03:50.2232891848 0008.7cbb.2040 0000.0c07.acff 0x8100 78: 802.1Q vlan#800 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6771)

   6: 15:03:50.2232891848 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#800 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6771)

   7: 15:03:51.2232892858 0008.7cbb.2040 0000.0c07.acff 0x8100 78: 802.1Q vlan#800 P0 192.168.5.101 > 192.168.254.26: icmp: echo request (ttl 127, id 6775)

   8: 15:03:51.2232892858 00d0.0143.b400 0008.7cbb.2040 0x8100 78: 802.1Q vlan#800 P0 192.168.254.26 > 192.168.5.101: icmp: echo reply (ttl 252, id 6775)

   9: 15:04:57.2232958948 0008.7cbb.2040 0000.0c07.acff 0x8100 70: 802.1Q vlan#800 P0 192.168.5.101.50505 > 192.168.254.26.5060: S

153485530:153485530(0) win 8192 (DF) (ttl 127, id 6935)

  10: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#800 P0 192.168.254.26.5060 > 192.168.5.101.50505: S [tcp sum ok]

3750378220:3750378220(0) ack 153485531 win 4128 (ttl 252, id 26637)

  11: 15:04:57.2232958948 0008.7cbb.2040 0000.0c07.acff 0x8100 64: 802.1Q vlan#800 P0 192.168.5.101.50505 > 192.168.254.26.5060: . [tcp sum ok]

153485531:153485531(0) ack 3750378221 win 65392 (DF) (ttl 255, id 8466)

  12: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.acff 0x8100 70: 802.1Q vlan#800 P0 192.168.5.101.50508 > 192.168.254.26.5060: S

3150694522:3150694522(0) win 8192 (DF) (ttl 127, id 6990)

  13: 15:05:10.2232972138 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#800 P0 192.168.254.26.5060 > 192.168.5.101.50508: S [tcp sum ok]

455106242:455106242(0) ack 3150694523 win 4128 (ttl 252, id 39032)

  14: 15:05:10.2232972138 0008.7cbb.2040 0000.0c07.acff 0x8100 64: 802.1Q vlan#800 P0 192.168.5.101.50508 > 192.168.254.26.5060: . [tcp sum ok]

3150694523:3150694523(0) ack 455106243 win 65392 (DF) (ttl 255, id 23983)

  15: 15:05:57.2233018958 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#800 P0 192.168.254.26.5060 > 192.168.5.101.50505: . [tcp sum ok]

3750378220:3750378220(0) ack 153485531 win 4128 (ttl 252, id 26638)

  16: 15:06:10.2233032148 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#800 P0 192.168.254.26.5060 > 192.168.5.101.50508: . [tcp sum ok]

455106242:455106242(0) ack 3150694523 win 4128 (ttl 252, id 39033)

16 packets shown

Regrads MJ

MJ,

This does look like SIP inspection problem. I am not aware of any sip related defects in the code that you are running. The SYN and SYN ACK packets are the same inside to outside but, the ACK packet isn't the same.

  11: 15:04:57.2232958948 00d0.0143.b400 0008.7cbb.2040 0x8100 64: 802.1Q vlan#810 P0 192.168.5.101.50505 > 192.168.254.26.5060: . [tcp sum ok] 2621387576:2621387576(0) ack 3750378221 win 65392 (DF) (ttl 127, id 6936)

  11: 15:04:57.2232958948 0008.7cbb.2040 0000.0c07.acff 0x8100 64: 802.1Q vlan#800 P0 192.168.5.101.50505 > 192.168.254.26.5060: . [tcp sum ok] 153485531:153485531(0) ack 3750378221 win 65392 (DF) (ttl 255, id 8466)

The packet ID doesn't match inside to outside for the ACK packet. It would be better to see the captures in the form of a .pcap files instead of text based output.

I'd suggest opening a TAC case and working with an engineer. Let me know the case no. once you open it.

-Kureli           

Hi Kureli

Thanks for the response, we have disabled SIP for this flow via a class-map and now this working.

Many thanks MJ

nick.ehlers
Level 1
Level 1

Kureli,

Thanks for doing this Q&A!

My question is, on a ASA 5510 running 8.2.x code. How do I properly implement Group Based authentication for anyconnect Remote VPN. It will be used in this context. Users from X organization will browse to the public IP address of the ASA from home bringing up the Remote VPN Login page. The user logs in with their Active Directory credentials and based on what group they are in they will be given certain access based on that group, obviously refering to certain ACLs applied to each group.

The customer has windows 2008 R2 so the ASA is pulling from LDAP, they have no radius server. I've made an attempt at the config myself and am hoping you can check my work to see if this will work or not?

Here is the config:

!

access-list ADMIN-VPN-SPLIT extended permit ip 192.168.254.0 255.255.255.0 10.0.0.0 255.255.0.0

access-list ADMIN-VPN-SPLIT extended permit ip 10.0.0.0 255.255.0.0 192.168.254.0 255.255.255.0

!

ip local pool VPN-POOL 192.168.254.1-192.168.254.254

!

ldap attribute-map CISCOMAP

  map-name  memberOf Group-Policy

  map-value memberOf "CN=VPN.Admin.User,OU=VPN,OU=Security Groups,OU=TEST,DC=TEST,DC=local" ADMIN

  map-value memberOf "CN=VPN.Default.Users,OU=VPN,OU=Security Groups,OU=TEST,DC=TEST,DC=local" "Standard Users"

dynamic-access-policy-record DfltAccessPolicy

aaa-server LDAP protocol ldap

aaa-server LDAP (inside) host 10.0.2.1

ldap-base-dn DC=TEST,DC=local

ldap-group-base-dn DC=TEST,DC=local

ldap-scope subtree

ldap-naming-attribute sAMAccountName

ldap-login-password Test123!

ldap-login-dn CN=LDAP,OU=Users,OU=_Applications,OU=TEST,DC=TEST,DC=local

ldap-over-ssl enable

server-type microsoft

ldap-attribute-map CISCOMAP

webvpn

enable outside

character-encoding windows-1252

anyconnect-essentials

svc image disk0:/anyconnect-wince-ARMv4I-2.3.0254-k9.pkg 4 regex "Windows CE"

svc image disk0:/anyconnect-win-2.3.0254-k9.pkg 5 regex "Windows NT"

svc image disk0:/anyconnect-macosx-i386-2.3.0254-k9.pkg 6 regex "Intel Mac OS X"

svc enable

tunnel-group-list enable

group-policy NoAccess internal

group-policy NoAccess attributes

banner value You have no access

wins-server none

dns-server value 10.0.2.1 10.0.2.2

vpn-simultaneous-logins 0

vpn-tunnel-protocol IPSec l2tp-ipsec svc webvpn

default-domain value TEST.local

address-pools none

group-policy DfltGrpPolicy attributes

vpn-filter value 150

group-policy ADMIN internal

group-policy ADMIN attributes

  wins-server none

dns-server value 10.0.2.1 10.0.2.2

vpn-simultaneous-logins 3

vpn-tunnel-protocol IPSec l2tp-ipsec svc webvpn

ipsec-udp enable

ipsec-udp-port 10000

split-tunnel-policy tunnelspecified

split-tunnel-network-list value ADMIN-VPN-SPLIT

default-domain value TEST.local

address-pools value VPN-POOL

webvpn

  svc keep-installer installed

  svc dpd-interval gateway 60

  svc ask enable default webvpn

  hidden-shares visible

  activex-relay enable

  file-entry enable

  file-browsing enable

  url-entry enable

group-policy "Standard Users" internal

group-policy "Standard Users" attributes

banner value You have full access to the TEST network.

wins-server none

dns-server value 10.0.2.1 10.0.2.2

vpn-simultaneous-logins 0

vpn-tunnel-protocol IPSec l2tp-ipsec svc webvpn

split-tunnel-policy tunnelspecified

split-tunnel-network-list value ADMIN-VPN-SPLIT

default-domain value TEST.local

group-policy LDAP-ALLOWACCESS internal

group-policy LDAP-ALLOWACCESS attributes

banner value You have logged in with the LDAP-ALLOWACCESS group Policy

dns-server value 10.0.2.1 10.0.2.2

vpn-tunnel-protocol IPSec l2tp-ipsec svc webvpn

ipsec-udp enable

ipsec-udp-port 10000

split-tunnel-policy tunnelspecified

split-tunnel-network-list value ADMIN-VPN-SPLIT

default-domain value isi.local

address-pools value VPN-POOL

webvpn

  svc keep-installer installed

  svc dpd-interval gateway 60

  svc ask enable default webvpn

  hidden-shares visible

  activex-relay enable

  file-entry enable

  file-browsing enable

  url-entry enable

group-policy LDAP-NOACCESS internal

group-policy LDAP-NOACCESS attributes

vpn-simultaneous-logins 0

vpn-tunnel-protocol IPSec svc

webvpn

  svc ask none default svc

tunnel-group ADMIN-VPN general-attributes

address-pool VPN-POOL

authentication-server-group LDAP

default-group-policy ADMIN

authorization-required

tunnel-group ADMIN-VPN webvpn-attributes

nbns-server 10.0.2.1 timeout 2 retry 2

group-alias ADMIN-VPN disable

group-alias Admin enable

group-alias DEFAULT disable

group-alias Default disable

group-alias Defaults disable

group-alias User disable

tunnel-group "Standard Users" general-attributes

address-pool VPN-POOL

authentication-server-group LDAP

default-group-policy "Standard Users"

tunnel-group "Standard Users" webvpn-attributes

group-alias Users enable

Thanks!

oh and also - how can I verify that if they dont authenticate to any particular group that they will be denied access?

Message was edited by: Nick Ehlers

Nick,

Let me review your config and get back to you.

-Kureli

Thanks Kureli I look forward to hearing from you.

Nick,

I reviewed the config with our VPN engineer (he was one of my question managers for the webcast event) today.  It looks good. 

I hope you found our CCO doc on this:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00808d1a7c.shtml

If for some reason it doesn't work as expected, pls. open a TAC case and work with one of our engineers in the VPN team.

-Kureli

sestonenppd
Level 1
Level 1

Is it recommended/possible to attach a 5510 running code version 8.2(5) in transparent mode to a Nexus 2248?  We have 2  contexts but are only connecting one (2 ports) now and the other at a later date.  We had an older 5510 connected to these same ports running code version 7.0(7) with no problems.  However, when we connect up the new 5510, one port or the other sends a BPDU causing the port to errdisable.  Is this a configuration, version, or compatibility problem?

In the older code we denied BPU by default. In the newer code, we allow by default and we need to bock it with an ether type acl if needed.

Pls. read here:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsl55476

Pls. try the workaround listed.

-Kureli

Received this error when I clicked the link:

Dear valued Cisco Bug Toolkit customer, the bug ID CSCsi55476 you searched contains proprietary information that cannot be disclosed at this time; therefore, we are unable to display the bug details. Please note it is our policy to make all externally-facing bugs available in Bug Toolkit to best assist our customers. As a result, the system administrators have been automatically alerted to the problem.

While we are working to resolve this issue, we invite you to reach out to the experts on the Bug Toolkit Support Community. You may find answers there to your Bug Toolkit questions, or post your feedback on our forum as well. Thank you.

Note: Some product enhancement requests and documentation bugs may not be available in Bug Toolkit.

Interesting. Not sure why you are unable to view. I am enclosing the RN for this defect.

CSCsl55476    DOC: Transparent firewall failover event causes STP topology change

Symptom:

Failover interface or data interface monitoring can fail due to a switchport entering the blocking state unexpectedly.

Conditions:

Multi-context transparent firewalls in failover pair.

It has not been verified if this affects single-context firewalls.

Workaround:

Configure ethertype ACLs to deny BPDUs from being passed through the transparent firewalls.

access-list 1 ethertype deny bpdu

access-group 1 in interface inside

access-group 1 in interface outside

Also turning off spanning-tree or turning off BPDUs via portfast on the switch ports will give the same affect.

Further Problem Description:

When running transparent firewalls in failover a loop free spanning-tree environment is guaranteed by the fact that the standby firewall will not pass traffic. During failover it is possible for BPDUs to be leaked through the standby firewall causing a spanning-tree topology change and switch ports to enter a blocking state. When the switch ports enter a blocking state this could lead to data interface or failover interface monitoring to fail between the two firewalls. If the firewalls were to enter an active/active failover state it is possible for a spanning-tree loop to occur.

-Kureli

Thank you. We will give that a try and report back.

Message was edited by: Scott Stoner Corrected punctuation

That solved the problem.  Thank you very much.

Excellent. Very glad to hear.

-Kureli

taufique.shaikh
Level 1
Level 1

Good Day,

ASA Phone proxy troubleshooting

I have configure 2 ASA 5510 with IPSEC Tunnel and when I start my CIPC from laptop to connect CUCM in USA Office it connects successfully and am able to make and recieve call and hear voice clearly...!

Now when I configured Cisco ASA 5510 USA office where CUCM is connected with Phone proxy having static NAT for CUCM am able to start and register my CICP in laptop from home but unable to retrieve CTL configure in ASA or Trustlist and also am not able to hear voice when making or recieving call..?

My configuration is very similar to below forum and have taken reference of below forum only..!

1. https://supportforums.cisco.com/docs/DOC-8165

2. http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/unified_comm_phoneproxy.html#wp1270838

Addition to this I configure IPSEC Remote Access VPN for USA Office connected from home successfully and then I start CIPC in laptop same problem am able to register but no voice in or out but strange what happen with me was when I removed sccp and sip from class map (inspect) i was able to make call to few of the extensions of Office and then after when I connect again there was no voice..!

Your comments and suggestions are highyl appreciated..!

Thank you.

Getting Started

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: