Hello Mike,

    Here's my show run log but if I simply add a 2 after my log statement it will log?

logging enable
logging timestamp
logging trap informational
logging asdm informational
logging from-address ***************************
logging recipient-address ********************* level errors
logging facility 18
logging host Internal ************************
logging debug-trace
logging permit-hostdown
no logging message 106015
no logging message 313001
no logging message 725001
no logging message 725002
no logging message 313008
no logging message 725007
no logging message 106023
no logging message 710003
no logging message 111008
no logging message 302015
no logging message 302014
no logging message 302013
no logging message 111001
no logging message 111004
no logging message 111007
no logging message 302018
no logging message 302017
no logging message 302016
no logging message 302021
no logging message 302020

Thanks, Jeff

Hi Jeff,

Based on the config you posted, you should see syslog message #106100 on your syslog server and in ASDM (though not via email). Can you confirm whether the ASA is generating this log message? This is probably the easiest way to do it:

logging buffered 6

show log | i 106100

If you see the messages there, you'll know that messages aren't making it to your syslog server. If you don't see any output, we would have to figure out why the ASA is neglecting to generate the messages as it should.

-Mike

Quote: "we would have to figure out why the ASA is neglecting to generate the messages as it should."

Looks like this is the case mike.

chy5510# show log | i 106100
chy5510# show log

chy5510# show log
Syslog logging: enabled
    Facility: 18
    Timestamp logging: enabled
    Standby logging: disabled
    Debug-trace logging: enabled
    Console logging: disabled
    Monitor logging: disabled
    Buffer logging: level informational, 36 messages logged
    Trap logging: level informational, facility 18, 279 messages logged
        Logging to Internal *****************
    Permit-hostdown logging: enabled
    History logging: disabled
    Device ID: disabled
    Mail logging: disabled
    ASDM logging: level informational, 279 messages logged

Hi Jeff,

What does 'show access-list Internal_access_out' and 'show access-list Internal_access_in' say? Do you see the hit counts on the ACL increasing when you generate your test traffic?

-Mike

chy5510# show access-list Internal_access_out
access-list Internal_access_out; 1 elements; name hash: 0x9e8020ff
access-list Internal_access_out line 1 extended permit ip any any log informational interval 300 (hitcnt=0) 0x7fdd7e55

chy5510# show access-list Internal_access_in
access-list Internal_access_in; 1 elements; name hash: 0x920ddc01
access-list Internal_access_in line 1 extended permit ip any any log informational interval 300 (hitcnt=0) 0x4863aa83

Looks like those ACLs are not matching the traffic you are testing with. Did you confirm with 'show run access-group' that the ACLs are still applied to the interface? If so then try using the packet-tracer to see what's going on:

ASA# packet-tracer input internal udp 1234 4.2.2.2 53

(or replace with whatever protocols/IPs/ports you are using to test)

My guess is that the traffic will be taking some interface other than 'internal'.

-Mike

It's not hitting my ACL. It's getting caught by some hiddin ACL.

This got logged in the syslog.

Deny IP spoof from (Host-192.168.1.44) to 192.168.2.250 on interface Internal

And here is the output of your command.

chy5510# packet-tracer input internal udp 192.168.1.44 1071 192.168.2.250 53

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   Network-192.168.2.0 255.255.255.0       Internal

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

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

Hi,

     I am going to go out on a limb and say that 192.168.1.44 and 192.168.2.250 are both off the inside interface according to the routing table. If thats the case, then the packet tracer line you tested would be like 'hairpinning' the traffic on the internal interface, no? If your intent is to hairpin traffic, then that is a whole other configuration we need to be talking about. If the goal of the acl lines is just to log when someone goes through the firewall try a packet tracer line like:

packet-tracer input internal udp 192.168.1.44 12345 4.2.2.2 53

The reason why that packet tracer test you did failed was becuase you lack the command 'same-security permit intra-interface' in your config. You do not need that command unless your expect to hairpin traffic on the firewall. (don't add it unless you intend to).

- Magnus

Who owns these addresses and where do these hosts live with respect to the firewall?

Deny IP spoof from (Host-192.168.1.44) to 192.168.2.250 on interface Internal

You would get these deny ip spoof messages

1. if a host that lives behind the inside interface tries to send packet destined to the ASA's other interface address besides the inside interface address.

2. if the syslog that the ASA sends to the syslog server reaches a layer 3 device and it in turn does not have a route to the syslog server and sends the packet back to the ASA - meaning the ASA sees a packets sent to it from its own address. Makes sense?

These are the two that I have seen. There could be others as well.

-KS

QUOTE: "I am going to go out on a limb and say that 192.168.1.44 and 192.168.2.250 are both off the inside interface according to the routing table. If thats the case, then the packet tracer line you tested would be like 'hairpinning' the traffic on the internal interface, no?"

JEFF: You are correct in that these are both internal addresses. 192.168.1.44 in the physical address of the internal interface and 192.168.2.250 is an internal DNS server that I can ping from the asa. Now for the hairpinning topic; I've never heard this term before, is it also called something else?

QUOTE: "If the goal of the acl lines is just to log when someone goes through the firewall try a packet tracer line like:

packet-tracer input internal udp 192.168.1.44 12345 4.2.2.2 53"

JEFF: At the moment I'm trying to prove I can see each and every packet to/from/traversing this device. When running your command I get "Failed to locate egress interface for UDP from Internal:192.168.1.44/12345 to 4.2.2.2/53". Makes sense to me as I don't have and internal 4.2.2.0 network. Now if I run this command destined for an actual machine I get the above.

QUOTE: "The reason why that packet tracer test you did failed was becuase you lack the command 'same-security permit intra-interface' in your config. You do not need that command unless your expect to hairpin traffic on the firewall. (don't add it unless you intend to)."

JEFF: This command is the same a checking the check box to "Enable traffic between two or more interfaces with the same security level"? If so I have this un-checked. Why would I need this checked if I'm not doing anything intra-interface?

Thinking on this hairpin thing I believe you mean u-turn but not sure.

Thanks

Hi Jeff,

To clear up some of the confusion, hairpinning and u-turning are indeed the same thing. However, the 'same-security permit intra-interface' command is not the same as the "Enable traffic between two or more interfaces with the same security level" checkbox that you mentioned (that would be the 'same-security permit inter-interface' command). The 'intra' version allows you to u-turn traffic, while the 'inter' version allows traffic to pass in a sitation where both the ingress and egress interfaces have the same security level value.

As Magnus mentioned, if traffic reaching your firewall needs to be u-turned (for example, it arrives on the "inside" interface and is supposed to leave on the "inside" interface), you'll need the 'same-security permit intra-interface' command for it to work.

Once you are able to get the packet-tracer to allow the packet, the hitcounts on the ACL should start increasing and you should see log messages generated for each hit.

Hope that helps.

-Mike