MGCP flow problem - ASA

hutoro · ‎06-01-2007

The following is the setup and the problem we have:

* MGCP call agent -- ASA 5510 -- vpn tunnel -- linksys -- MGCP gateway

* VPN tunnel setup is in aggresive mode (initiated as needed from linksys).

* When MGCP call agent is up but the vpn tunnel is still down, MGCP traffic (udp/2427) tried to reach gateway and failed --> this is as expected.

* Next, linksys brings up the vpn tunnel

* Any other IP traffic can go through the tunnel, but not MGCP traffic from call agent to gateway.

* Checked from packet tracer: it passed phase 1 & 2 (checking the flow), it found existing flow and used that flow. Then it stuck there, looks like it didn't know where to go next (no ACL or route checking).

We noticed that the annoying following workaround will make the MGCP goes through.

* shutdown MGCP call agent

* disconnect vpn tunnel from linksys

* system reload the ASA5510

* after ASA5510 is up, linksys initiate the vpn tunnel

* after vpn is up, bring up MGCP call agent

* MGCP traffic goes through the tunnel

It seems like ASA MGCP flow table is not updated if there is status change in VPN tunnel. Any idea how to fix this ?

Report Inappropriate Content · ‎06-07-2007

By default, the configuration includes a policy that matches all default application inspection traffic and applies inspection to the traffic on all interfaces (a global policy). Default application inspection traffic includes traffic to the default ports for each protocol. You can only apply one global policy. Therefore, if you want to alter the global policy, for example, to apply inspection to non-standard ports or to add inspections that are not enabled by default, you need to either edit the default policy or disable it and apply a new one. For a list of all default ports, refer to the Default Inspection Policy.

Issue the policy-map global_policy command.

ASA5510(config)#policy-map global_policy

Issue the class inspection_default command.

ASA5510(config-pmap)#class inspection_default

Issue the inspect mgcp command.

ASA5510(config-pmap-c)#inspect mgcp

Refer this link:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008081042c.shtml#configs2

hutoro · ‎06-07-2007

Thanks for the reply.

However that wasn't mgcp ispection issue, it was more on dynamic vpn configuration issue. The setup is dynamic vpn initiated from remote sites (aggresive mode).

Worked with Cisco TAC and got the workaround. Following is the summary, hope it's useful.

1. Previous dynamic vpn config was:

crypto dynamic-map outside_dyn_map 20 set transform-set VPNHigh

When the tunnel was down and the call agent (central) was sending traffic to the call gateway (remote), the ASA created a connection to send the traffic out in the clear as it didn't match any crypto access-list due to the tunnel being dynamic.

2. The call agent (cetral) continued to attempt to send traffic to the call gateway (remote), which kept the conn up, even when the tunnel came up.

3. When the tunnel came up, the ASA continued to use the existing conn and sent the traffic out in the clear.

4. This is very similar to bug: CSCse36327 - GRE Packets are no longer encrypted and are sent out in the clear

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCse36327

Even though that mentions GRE, it's the same issue.

5. After the tunnel was up and "clear local-host " was issued, the conn was torn down and a new conn was built to go over the tunnel.

6. To avoid this situation, a crypto acl for this dynamic tunnel was created:

access-list dyn-mgcp line 1 extended permit ip

crypto dynamic-map outside_dyn_map 20 match address dyn-mgcp

crypto dynamic-map outside_dyn_map 20 set transform-set VPNHigh

crypto dynamic-map outside_dyn_map 40 set transform-set VPNHigh

Now, when the call agent (central) sends traffic to the call gateway (remote) when the tunnel is down, the ASA drops the packets and doesn't build a conn until the tunnel is brought up.

7. This was tested by bringing down the tunnel and watching incoming packets from the call agent (central) to the call gateway (remote) and verified they weren't being sent out in the clear. The tunnel up was brought up and traffic started being passed between the call agent and the call gateway.