cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1111
Views
5
Helpful
7
Replies

Cisco packet tracer

cisco8887
Level 2
Level 2

Hi All,

I am doing a packet trace from remote vpn( herein referenced as 1.1.1.1) subnet to internal subnet ( referenced as 2.2.2.2)

Ping to that subnet from remote vpn (1.1.1.1) is possible to 2.2.2.2 however packet-tarcer below says packet is rejected.

Why does ASA believe it will drop the packet when it never will ?

This is done on the ASA acting as local ASA for 2.2.2.2

packet-tracer input outside icmp 1.1.1.1 8 0 2.2.2.2 d

result

Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   2.2.2.2       255.255.255.0   inside

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static x x destination static y y no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface inside
Untranslate 2.2.2.2/0 to 2.2.2.2/0

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x73870468, priority=11, domain=permit, deny=true
        hits=757295, user_data=0x5, cs_id=0x0, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
        input_ifc=outside, output_ifc=any

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

7 Replies 7

Diego Lopez
Level 1
Level 1

Hello,

You should have an access-list applied to the outside interface of the ASA that's what is blocking it.

Real traffic is permitted because is VPN traffic and the sysopt connection permit this kind of traffic by default even if is not specified in this access list applied to the interface, but the packet tracer cannot simulate VPN traffic when you run a packet tracer is like "clear text" traffic and that is why is showing DROP.

If you need to check all the phases of the packet tracer just permit this traffic in the access list applied to the outside interface and that should do it.

Thanks, please rate!

thanks for this.

I disagree in a sense that if I was to do the reverse so from 2.2.2.2 to 1.1.1.1 on the same ASA, it would show the steps and when it is been encrypted on the VPN tunnel.

packet tracer does send a packet and can be seen on packet captures.

Traffic between those subnets are allowed without an issue and is working but just packet tracer failing.

I don't think any any would help as that means encrypt all outgoing traffic to the internet or anywhere.

Traffic from an interface with a higher security level to a lower security level is permitted that is why you see all the phases going when you run the packet tracer from inside to outside, traffic from outside to inside is from lower security level to higher security level to permit this traffic you need an access list because the ASA is a security device and you are not going to permit everything from the external world to your internal network.

You don't need an any any statement I did mean that, what you need to permit is this traffic on the access list something like this:

Let's assume that the access applied to the interface is OUTSIDE so the statement should look like this

access-list OUTSIDE extended permit ip host 1.1.1.1 host 2.2.2.2 

thanks and this would be outside in ?

The thing is the ASA knows it should allow that specific subnet and for that no acl is applied.

This means even though outside in is deny all unless inspected and generated from inside, it will accept packets from peer after tunnel is up with no acl on the outside in .

the asa accepts packets on udp 500 for ikev1/2 negotiation without a permit statement on permit in on outisde.

Hello,

Yes the access rule should be from outside to inside

Real traffic is permitted because it gets to the ASA encrypted over a secure VPN tunnel and thanks to the command "sysopt connection permit-vpn" the traffic doesn't require any rule it bypass the acl, if you remove that command you will need to configure rules in the inbound acl applied to the outside interface even for real traffic.

When you run a packet tracer the traffic generated is not encrypted, the ASA sees the packet tracer as clear text traffic not encrypted, even if the traffic is supposed to come encrypted over a VPN tunnel the packet tracer cannot simulate that, that's why you need the rule to run this kind of test.

You can find more information about sysopt connection here:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/vpnsysop.html#wp1042105

many thanks that is now clear

re sysopt connection ...

when that is disabled, i guess one only needs to allow access for the external public ip not all internal ranges, correct ?

You need to allow all the internal networks... the ASA will decrypt the traffic then check the acls and will look for the private ips.

Please rate if you find this helpful. 

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: