Is my venodr pulling my leg?

Michael
Michael used Ask the Experts™
on
HI,

Although I have worked on Cisco routers for many years I have little experience on Cisco ASA. Recently I have started managing a site that uses ASA between two offices. The foreign office is managed by another Vendor. I sometimes feel like the foreign offices vendor is feeding me BS as things sometimes seem to fix themselves overnight with out change on his part "apparently"

Example. the following packet tracer was performed

packet-tracer input inside udp 172.27.1.9 domain 10.1.1.112 domain
 
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside-tm) source static NO-NAT-LOCAL NO-NAT-LOCAL destination static NO-NAT-REMOTE NO-NAT-REMOTE
Additional Information:
NAT divert to egress interface outside-tm
Untranslate 10.1.1.112/53 to 10.1.1.112/53
 
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group global global
access-list global extended permit ip any any
Additional Information:
 
Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside-tm) source static NO-NAT-LOCAL NO-NAT-LOCAL destination static NO-NAT-REMOTE NO-NAT-REMOTE
Additional Information:
Static translate 172.27.1.9/53 to 172.27.1.9/53
 
Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 
Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
service-policy global_policy global
Additional Information:
 
Phase: 7
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
 
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside-tm
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
 
KL-ASA#

The Next morning I performed the exact same command and got a different outcome.

KL-ASA# packet-tracer input inside udp 172.27.1.9 domain 10.1.1.112 domain
 
Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside-tm) source static NO-NAT-LOCAL NO-NAT-LOCAL destination static NO-NAT-REMOTE NO-NAT-REMOTE
Additional Information:
NAT divert to egress interface outside-tm
Untranslate 10.1.1.112/53 to 10.1.1.112/53
 
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group global global
access-list global extended permit ip any any
Additional Information:
 
Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside-tm) source static NO-NAT-LOCAL NO-NAT-LOCAL destination static NO-NAT-REMOTE NO-NAT-REMOTE
Additional Information:
Static translate 172.27.1.9/53 to 172.27.1.9/53
 
Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 
Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
  inspect dns preset_dns_map
service-policy global_policy global
Additional Information:
 
Phase: 7
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
 
Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside-tm) source static NO-NAT-LOCAL NO-NAT-LOCAL destination static NO-NAT-REMOTE NO-NAT-REMOTE
Additional Information:
 
Phase: 9
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
 
Phase: 10
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 
Phase: 11
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 
Phase: 12
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 15432305, packet dispatched to next module
 
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside-tm
output-status: up
output-line-status: up
Action: allow


When I performed the first instance of the packet trace command, I had just updated relevant ACL's to allow traffic from the 172.27.1.0 network to traverse the vpn. my only logical explanation assuming the foreign vendor is telling the truth is that the cisco ASA takes time for the ACL changes to take effect. Is that a logical assumption?

Regards
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
i do not believe so.

established sessions may stay active after your forbid the corresponding traffic. not the reverse.

what is fairly possible ( afaik which is not much regarding ASAs ) is some ACLs may not apply to VPN interfaces until the tunnel is restarted which may have happened overnight. IPSEC VPN's are typically restarted every few hours. i'm unsure how ASA applies such rules.
Pete LongTechnical Consultant

Commented:
Hi Michael,

While packet tracer can be a little 'peculiar' with VPN traffic, its usually good with site to site VPNS, I'd expect this 'odd-ness' if you were using EZVpn on your firewall to connect to the other office?

To be sure, In your situation Id simply debug the traffic, for phase 1, a simple WAIT_MSG status will tell you which end the problem is on! so 'show crypto isakmp' will tell you (you need to know the difference between an initiator and a responder, but Ive described it all in detail here

If phase 1 establishes, and phase 2 does not that's even easier to pinpoint which end it as fault.

Regards

</P>

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial