A colleague was doing a firewall migration yesterday and I offered to sit in, in case he had any problems, one of the tasks was a VPN tunnel getting migrated, this is usually painless, (if you have control of both ends!) But in this case we didn’t, and it’s usually the case, when there’s VPN problems, the people at the {ahem} ‘less experienced,’ end of the tunnel tend to blame the other end.
I asked if we could get on the client’s servers to set up a constant ping, (to force the tunnel up as soon as the far side had changed peer ip addresses). But we couldn’t, I was asked ‘Can we not bring the tunnel up from the ASA?’
Solution
Note: To save people emailing me to ask, the above is virtualised using EVE-NG in VMware ESX.
Well, yes you can do this, BUT there are some caveats,
The inside IP of the ASA needs to be part of the ACL that declares ‘interesting traffic’ i.e. the one matched in the crypto map.
The inside IP o the ASA needs to also be in the nat exemption for the VPN traffic.
‘Management-access inside‘ needs to be enabled in the config, (so traffic can be sourced from it).
Then, (assuming 192.168.1.10 is an IP address at the far-end of the VPN tunnel), use the following syntax;
[box]
ping inside192.168.1.10
[/box]
Note: This assumes your inside interface is called ‘inside‘, yours may be called LAN, or Inside, or something else.
Well my IP is on a different range to the inside interface, or I can’t enable management-access inside, and/or my IPs are not in the nat exemption! Jeez there’s always one! Well in your case you can simulate VPN traffic to bring the tunnel up, with packet-tracer, like so;
Note: This assumes 172.16.1.1 is at YOUR site and 192.168.1.10 is at the OTHER site, and you interesting traffic ACL permits TCP port 80, (most of them permit all ports but you may be in a more secure environment so check).
Related Articles, References, Credits, or External Links
Packet tracer is a great tool, I wrote about it in the ‘Prove It’s Not the Firewall‘ article a while ago. A couple of months ago I was having a discussion with a colleague about packet tracing a remote VPN client to check connectivity, he said at the time, “It will behave differently if the IP you use is already connected”. I never really thought about it until today, when I was troubleshooting a clients AnyConnect they they had ‘hair pinned‘ to another site.
So after I had finished I tested the theory on the bench to discover he was correct.
Solution
Results When The IP is NOT IN USE
I prefer to work at commend line, so if I packet-trace the above connection (using normal http port 80 for example) This is what I get;
[box]
Petes-ASA# packet-tracer input outside tcp 192.168.199.2 www 192.168.100.10 w$
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.100.0 255.255.255.0 inside
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static OBJ-ANYCONNECT-SUBNET OBJ-ANYCONNECT-SUBNET no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface inside
Untranslate 192.168.100.10/80 to 192.168.100.10/80
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inbound in interface outside
access-list inbound extended permit tcp any object Internal_HTTP_Server eq www
Additional Information:
Phase: 4
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection decrement-ttl
service-policy global_policy global
Additional Information:
Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static OBJ-ANYCONNECT-SUBNET OBJ-ANYCONNECT-SUBNET no-proxy-arp route-lookup
Additional Information:
Static translate 192.168.199.2/80 to 192.168.199.2/80
Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static OBJ-ANYCONNECT-SUBNET OBJ-ANYCONNECT-SUBNET no-proxy-arp route-lookup
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 5786108, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
Petes-ASA#
[/box]
If you really must use the ASDM here’s what it looks like in there;
Results When The IP is IN USE
So, if I connect my remote client, and it gets an IP, (for simplicities sake the same IP we used above), like so;
Then run the exact same test, here’s the result;
[box]
Petes-ASA# packet-tracer input outside tcp 192.168.199.2 www 192.168.100.10 www
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.100.0 255.255.255.0 inside
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static OBJ-ANYCONNECT-SUBNET OBJ-ANYCONNECT-SUBNET no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface inside
Untranslate 192.168.100.10/80 to 192.168.100.10/80
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inbound in interface outside
access-list inbound extended permit tcp any object Internal_HTTP_Server eq www
Additional Information:
Phase: 4
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection decrement-ttl
service-policy global_policy global
Additional Information:
Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static any any destination static OBJ-ANYCONNECT-SUBNET OBJ-ANYCONNECT-SUBNET no-proxy-arp route-lookup
Additional Information:
Static translate 192.168.199.2/80 to 192.168.199.2/80
Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: CP-PUNT
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: WEBVPN-SVC
Subtype: in
Result: DROP
Config:
Additional Information:
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: dropDrop-reason: (acl-drop) Flow is denied by configured rule
Petes-ASA#
[/box]
Again, the same thing in the ASDM;
So the moral of the story is, if you are testing, make sure the IP you are using for the remote client is NOT in use.
How do I know which AnyConnect IPs are in use? Simple run the ‘show vpn-sessiondb anyconnect‘ command like so;
Sometimes when troubleshooting VPN traffic, you may choose to use the ‘packet-tracer’ command to simulate interesting traffic. I did this today and got;
[box]
Phase: {number}
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
Result:
Drop-reason: (acl-drop) Flow is denied by configured rule
[/box]
I replicated the error on the test bench.
Solution
Below is the full packet trace;
[box]
Petes-ASA(config)# packet-tracer input inside tcp 192.168.254.1 www 10.254.254.10 www
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static Obj-SiteA Obj-SiteA destination static Obj-SiteB Obj-SiteB no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 10.254.254.10/80 to 10.254.254.10/80
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outbound in interface inside
access-list outbound extended permit ip any any
Additional Information:
Phase: 4
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection decrement-ttl
service-policy global_policy global
Additional Information:
Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static Obj-SiteA Obj-SiteA destination static Obj-SiteB Obj-SiteB no-proxy-arp route-lookup
Additional Information:
Static translate 192.168.254.1/80 to 192.168.254.1/80
Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
[/box]
This is an annoying error, that is difficult to solve. The reason you are seeing this error is because the ACL that defines the ‘interesting traffic’ for the VPN, does not a MIRROR IMAGE ACL on the OTHER VPN endpoint. As soon as this was rectified the packet-trace ran successfully.
For the first time in about ten years I had to deal with EIGRP last week, so I thought I would run it up in a lab. Normally I would use GNS3 but for this procedure I’ll use Cisco Packet Tracer.</p<
In fact I’ll include the files so you can download and use the lab yourself, (if you have a copy of Packet Tracer). And I’ll also include the configs for all the routers.
In the lab I’ve got three sites connected via serial connections, and one of those sites has the Internet connection.
As you can see I’ve used VLSM to split up the 192.168.0.0/24 subnet to create the six networks I need, (three on the sites, and three for the links).
Solution
1. I will start at the beginning with Router R1 in site 1. As you can see I’m going to give the FastEthernet 0/0 interface to the inside network (192.168.0.1/28). I will use Serial 3/0 to connect to Site 2 (192.168.64.2/30), and Serial 2/0 to connect to Site 1 (192.168.68.1/30). I will mirror these three settings around the network (going clockwise) and I will configure all the Serial 2/0 interfaces to set the clock speed for the serial links.
number of 1, then I am adding all the networks that I want this router to advertise (don’t forget to add the subnet that connects each router to its neighbour). When enabled EIGRP will send routing updates onto each of these networks. As you can see from the diagram, this would mean that the router would send routing information onto the LAN. While this wont cause any problems, it does generate traffic that does not need to be on the LAN, so I’ve disabled that by using a passive-interface* command.
*Note: If you have a lot of interfaces you want to be passive, you can ‘swap the logic’ by using passive-interface default and then setting all the interfaces you want to advertise networks out of, as no passive-interface.
I’ve also disabled auto-summary of networks, I’ve seen other pages and blogs that incorrectly say this makes the EIGRP routing protocol classless. EIGRP is classless out of the box! At a basic level network-summary is the process of advertising one route for many networks. This works best for contiguous networks (i.e. 192.168.1.x, 192.168.2.x, etc). But if you let EIGRP auto-summarise for you, then this happens,
Above you can see it has added three more routes to networks that (at the moment) don’t exist, which is fine, but then you can NOT use those subnets in the future. If you did and this router saw that traffic it would send it to Null0 (i.e. drop the traffic). With auto-summary disabled, the routers routing table is a lot cleaner (see below).
The last thing you will notice is that the subnet masks are a little strange, you need to use wildcard masks, these are easy to work out, just subtract each octet of the subnet mask from 255 like so;
[box]
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router eigrp 1
R1(config-router)#passive-interface FastEthernet0/0
R1(config-router)#network 192.168.0.0 0.0.0.15
R1(config-router)#network 192.168.64.0 0.0.0.3
R1(config-router)#network 192.168.68.0 0.0.0.3
R1(config-router)#no auto-summary
R1(config-router)#end
R1#
[/box]
5. Repeat the process for routers R2 an R3.
[box]
Router 2
R2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router eigrp 1
R2(config-router)#passive-interface FastEthernet0/0
R2(config-router)#network 192.168.16.0 0.0.0.15
R2(config-router)#network 192.168.64.0 0.0.0.3
R2(config-router)#network 192.168.72.0 0.0.0.3
R2(config-router)#no auto-summary
R2(config-router)#end
R2#
Router 3
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#router eigrp 1
R3(config-router)#passive-interface FastEthernet0/0
R3(config-router)#network 192.168.32.0 0.0.0.15
R3(config-router)#network 192.168.72.0 0.0.0.3
R3(config-router)#network 192.168.68.0 0.0.0.3
R3(config-router)#no auto-summary
R3(config-router)#end
R3#
[/box]
6. EIGRP Adding a Route to the Internet
To add in the networks ‘route out’, I need to bring up and configure another interface on router R3 (FastEthernet4/0). Then I will configure that as the default route (GOLR) for that router, and add that new network into the advertised routes.
To get all the other routers to use the static route I’ve just configured on this router, I use the redistribute static command (while in config-router mode).
[box]
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#interface FastEthernet4/0
R3(config-if)#ip address 123.123.123.1 255.255.255.252
R3(config-if)#no shutdown
R3(config-if)#ip route 0.0.0.0 0.0.0.0 123.123.123.2
R3(config)#router eigrp 1
R3(config-router)#network 123.123.123.120 0.0.0.3
R3(config-router)#redistribute static
R3(config-router)#end
R3#
[/box]
7. Then I will add the ISP (Internet Router). I will also add this to the EIGRPAS group (though I could just use static routing.)
Note: In the lab I don’t have a link to the Internet so I’ll simply use the Loopback interface on the Internet router and give that the 4.2.2.2 IP address.
As a final ‘belt and braces’ approach, I will add a summary route back to the LAN. If you are unsure how to calculate a summary route, simply write your subnets out in binary, and the mask will be the the length from the first to the last bit, that all the subnets have in common, like so;
Summarisation for these networks will be 192.168.0.0/17 (255.255.128.0)
I love packet-tracer, I use it a lot, especially when I’ve been told that the firewall I’ve installed is stopping a particular port. I had set up a simple port forward the other day, and when I went to check it with packet-tracer this happened.
This happens because the packet-tracer command is expecting to see the address that exists on the outside interface. So it’s the opposite way round to the way you would write an ACL. (Unless you are an old school Cisco tech, then it’s the same way we used to write ACL’s (before version 8.3)).
So, as I’m port forwarding the port that I’m tracing (tcp port 443 or https if you prefer) from the outside interface (100.100.100.100), that’s the IP address I should be using.
Note: If you are testing a static translation, then you would use the public IP for testing inbound traffic.
Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 5844584, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow
[/box]
Do the same from the ADSM
As you can see below, the same thing happens if you use the graphical Packet Tracer in the ASDM
Related Articles, References, Credits, or External Links
Considering we use ICMP to test connectivity, the fact that it is not a stateful protocol can be a major pain! Last week one of my colleagues rang me up and said, “Can you jump on this firewall, I’ve got no comms, and I cant ping external IP addresses. I can ping the internet from the firewall and I can ping internal IP addresses form the firewall”.
Solution
1. Before we start, lets get the basics out of the way, does the client you are pinging from have a firewall turned on? Can you ping the inside interface of the firewall?
2. Pinging will never work unless you have ICMP inspection turned on on the firewall. See the following article.
3. At this point we troubleshoot as we would for any other traffic through the firewall. To do this we use packet-tracer, the syntax is slightly different for ICMP, than it is for TCP and UDP though. We need to specify an ICMP Type and an ICMP code, to make sure the traffic leaves the firewall we trace ICMP type 8 (echo), with ICMP code 0 (none). And ICMP type 0 (Echo-reply), with ICMP code 0 (none), for traffic inbound.
Test Outbound Ping
Petes-ASA# packet-tracer input inside icmp 192.168.1.1 8 0 4.2.2.2
Testing Inbound Ping(where 123.123.123.123 is the public IP you are mapped to)
Petes-ASA# packet-tracer input outside icmp 4.2.2.2 0 0 123.123.123.123
4. Make sure the client you are on is getting NATTED or PATTED through the firewall. Below we will assume my internal IP address is 192.168.1.1.
Note: If you have names enabled and 192.168.1.1 has a name, you will get no results! issue a no names command from configure terminal mode to check.
[box]
Petes-ASA# show xlate | incl 192.168.1.1
If this machine was being NATTED to another public IP address it would look like..
NAT from inside:192.168.1.1 to outside:123.123.123.124
If this machine was being PATTED to a public IP address it would look like..
ICMP PAT from inside:192.168.1.1/1 to outside:123.123.123.123/1 flags ri idle 0:00:07 timeout 0:00:30
[/box]
If it fails at this stage then check you network translation configuration on the firewall.
5. If all appears normal so far you can capture the traffic as it passes though the firewall, below I’m successfully capturing the ICMP traffic though the firewall.
Yeah, it’s funny because it’s true! The article title might not sound like the most professional approach, but when the ‘Well it’s not working now’ finger gets pointed at the ‘firewall guy/girl’, they need to ascertain two things;
1. Is the problem actually the firewall, if not then help the frustrated party track down the actual problem.
2. If your problem IS the firewall, fix it!
I’m just coming out of a major network greenfield site build, all the individual technologies that have been getting planned and designed are now starting to come online and require comms though the firewall solution that I’ve been working on. So my days are pretty much filled with conversations like this;
Consultant/Engineer: Pete I need some ports opening on the firewall.
Me: OK let me know the IP addresses, host-names, ports, protocols etc, and I’ll open them for you. I then open the requested ports/protocols. Consultant/Engineer: You know those ports you opened? They don’t work.
At this point one of the following has occurred;
1. I’ve made an error, (it happens I’m human), I might have entered the wrong information, or not applied an ACL, or put the rule on the wrong firewall. Always assume you have done something wrong, until you are 100% sure that’s not the case.
2. The person who asked for traffic to be allowed, asked for the wrong thing, either they didn’t RTFM, or someone has given them the wrong IP addresses, or because they are human too, they’ve made a mistake.
3. The traffics not even getting to the firewall, because either it’s getting blocked before it gets to you, or there is a routing problem stopping the traffic hitting the firewall. (Remember routing works by Unicorns and Magic, so routing people are not to be trusted!)
4. The traffic needs some kind of special inspection to work through the firewall i.e. ICMP, FTP, or PPTP etc.
5. Some annoying bug in the ASA code is stopping you, which either requires a lot of Internet and forum searching or a call to TAC to confirm.
If I’ve forgotten another reason – feel free to contact me. (Link at the bottom of the page).
Solution
Step 1: Make sure you are not blocking the Traffic
Packet tracer is your friend! Use it to simulate traffic going though the firewall, and the firewall will tell you what it will do with that traffic. I prefer to use command line, but you can also run packet tracer graphically in the ASDM.
Xml: (Optional) Displays the trace capture in XML format.
Example
Below I’m checking that an internal host (10.254.254.5) can get access to a public web server (123.123.123.123) via http (TCP port 80). Note: As mentioned above I just picked a random source port (1024).
OK, so if packet-tracer shows the firewall is not blocking the traffic. Then either there’s other ports we don’t know about that may need opening, or the traffic is not getting to the firewall. Normally at this point I’d test to see if the traffic is getting to the firewall. To do that I would do a packet capture.
To demonstrate, below someone has requested that we open https from Server A on our LAN, to an Internet server Server B.
Above the traffic is not getting to the firewall as there’s a problem between Server A and the Firewall, either something is blocking the traffic downstream, or Server A cannot route traffic to the firewall.
Below we can see traffic hitting the firewall, in fact 10.0.0.1 sends out three packets on TCP port 443 (https). What we CANNOT SEE is any traffic coming back, in this case Server B is not replying to us, either its down or it cannot route traffic back to us.
Now the port(s) we want to allow, we can see are actually working, so if theres still a problem, theres probably another port / protocol that’s being blocked. To find out we need to enable logging and see if any packets are being denied.
Try the connection again, then view the log, (here I’m filtering it on 10.0.0.1, as the log can be quite sizable);
[box]Petes-ASA(config)# show logg | incl 10.0.0.1
%ASA-7-609001: Built local-host inside:10.0.0.1
%ASA-6-302013: Built outbound TCP connection 15 for outside:123.123.123.123/443 (123.123.123.123/443) to inside:10.0.0.1/1070 (10.0.0.1/1070) %ASA-4-106023: Deny tcp src inside:10.0.0.1/1073 dst outside:123.123.123.123/21 by access-group “outbound” [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.0.0.1/1073 dst outside:123.123.123.123/21 by access-group “outbound” [0x0, 0x0]
%ASA-4-106023: Deny tcp src inside:10.0.0.1/1073 dst outside:123.123.123.123/21 by access-group “outbound” [0x0, 0x0]
%ASA-6-302014: Teardown TCP connection 15 for outside:123.123.123.123/443 to inside:10.0.0.1/1070 duration 0:00:30 bytes 1420 TCP FINs
%ASA-7-609002: Teardown local-host inside:10.0.0.1 duration 0:00:30
Petes-ASA(config)# [/box]
As we can see traffic is being denied and it’s on TCP port 21 (That’s FTP if your interested). So let’s open that port, and try again;
[box]Petes-ASA(config)# show logg | incl 10.0.0.1
%ASA-5-111008: User ‘enable_15’ executed the ‘access-list outbound extended permit tcp host 10.0.0.1 host 123.123.123.123 eq 21’ command.
%ASA-5-111010: User ‘enable_15’, running ‘CLI’ from IP 0.0.0.0, executed ‘access-list outbound extended permit tcp host 10.0.0.1 host 123.123.123.123 eq 21’
%ASA-7-609001: Built local-host inside:10.0.0.1
%ASA-6-302013: Built outbound TCP connection 16 for outside:123.123.123.123/443 (123.123.123.123/443) to inside:10.0.0.1/1077 (10.0.0.1/1077)
%ASA-6-302013: Built outbound TCP connection 17 for outside:123.123.123.123/21 (123.123.123.123/21) to inside:10.0.0.1/1080 (10.0.0.1/1080)
%ASA-6-302014: Teardown TCP connection 16 for outside:123.123.123.123/443 to inside:10.0.0.1/1077 duration 0:00:30 bytes 1420 TCP FINs
Petes-ASA(config)# [/box]
And we are working!
If we have got this far and you are still not working, then check the traffic you are trying to send does not need any special inspection enabling. Or the port number you are using may have been reserved for a particular type of traffic (like this).
Failing that, upgrade the ASA, then open a TAC call.
Related Articles, References, Credits, or External Links
Well from CLI it worked fine, so I’m guessing it’s a fault in the ASDM. An Internet/forum search threw up a load of people having similar problems with ASDM 7.3.1 so I checked, and sure enough thats what was installed. I upgraded to 7.3(1)101 and the problem disappeared
Related Articles, References, Credits, or External Links
Packet-tracer is a brilliant troubleshooting tool, but sometimes interpreting the output proves to be more difficult that actually fixing the problem.
If your output fails at the access-list section this is the sort of thing you will see;
[box]
Petes-ASA# packet-tracer input inside tcp 10.2.2.10 80 123.123.123.123 80----Output removed for the sake of brevity---
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Additional Information:
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
[/box]
Solution
1. Re-run the packet-tracer and append the keyword ‘detailed’ on the end.
2. At this point if you are being specifically blocked by a ‘deny’ rule it should tell you like so;
[box]
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group outbound in interface inside <--
access-list outbound extended deny ip any any <--
Additional Information:
Forward Flow based lookup yields rule:
in id=0xbb9ba040, priority=13, domain=permit, deny=true
hits=0, user_data=0xb94669e0, cs_id=0x0, use_real_addr, 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=inside, output_ifc=any
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
[/box]
3. Or you may see output like the following, this indicates you are being denied by the ‘implicit rule’.
[box]
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule<--
Additional Information:
Forward Flow based lookup yields rule:
in id=0xbc057320, priority=11, domain=permit, deny=true
hits=8, 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=inside, output_ifc=any
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
[/box]
If you didn’t already know,as soon as you allow one piece of traffic though an interface with an ACL, everything else is blocked, it’s called the ‘implicit deny rule’. At the end of every ACL there is a deny, so if you traffic does not match any of the rules it gets dropped. So find the ACL name and add the traffic you want to it.
[box]
Petes-ASA# show run access-group
access-group outbound in interface inside
Petes-ASA# configure terminal
Petes-ASA(config)# access-list outbound permit tcp host 10.2.2.20 host 123.123.123.123 eq 80
[/box]
It Still Does Not Work!
There is another reason, that the traffic can be blocked by the ‘Implicit Rule’ if both interfaces have the same security level like so;
[box]
Petes-ASA# show run interface
!
interface GigabitEthernet0
nameif outside
security-level 0
ip address 192.168.253.254 255.255.255.0
!
interface GigabitEthernet1
nameif inside
security-level 100
ip address 10.1.1.1 255.255.0.0
!
interface GigabitEthernet2
nameif Partner
security-level 100
ip address 123.123.123.1 255.255.255.0
!
[/box]
To fix that you need to allow traffic between interfaces with the same security level;
