cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1178
Views
0
Helpful
10
Replies

All firewall rules on external are duplicating on old-external and cannot set up public servers on 8.4.1?

mvanruit
Level 1
Level 1

                   We had previous changed the external port to interface 0/3 from 0/2 and labeled 0/2 Old-external

Any work within GUI on access lists now duplicates to both and if you disable on one you disable on both.

Also no setup of public servers gets working access to internal servers.

Can anyone help

1 Accepted Solution

Accepted Solutions

Hi,

It still seems to me that the above mentioned ACL is blocking these connections.

There is first an ACL check at the Phase 3 which to my understanding might now be the Global ACL.

Then we see the ACL check again at Phase 6 and I think this is the above mentioned ACL that is attached to the "Internal" interface in the "out" direction. So it would basically check connections that are formed towards the networks behind "Internal".

The reason why it is hitting some Implicit Deny rule is because the above ACL only has a single configured "deny" rule which this traffic doesnt match. Therefore it matches the Implicit Deny in the end of that ACL.

- Jouni

View solution in original post

10 Replies 10

Jouni Forss
VIP Alumni
VIP Alumni

Hi,

It seems to me (as you have stated already) that you have 2 external interfaces. The old one and the new one.

What I also noticed is that you have a single ACL and you have attached it to both of these interfaces.

Here are the commands which tell that the same ACL has been attached to 2 different interfaces

access-group External_access_in in interface old_External

access-group External_access_in in interface External

So basically if you make any changes to the ACL it applies to both of these interfaces.

If you want to keep them totally separate, you can for example copy/paste the current ACL configuration to Notepad for example or some other text editor. Then you can change the ACL name to something else and use this to make a separate ACL for the other external interface.

If there are some problems with the connections getting through, I would suggest using the "packet-tracer" command on the CLI to test that traffic and sharing the output with us here on CSC.

For example

packet-tracer input External tcp

This should tell us if there is some problems with the ASA configuration that might block the connections.

- Jouni

Result of the command: "packet-tracer input External tcp 4.4.4.1 443 205.215.240.104 443"

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

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network SophosServer
nat (Internal,External) static 205.215.240.104
Additional Information:
NAT divert to egress interface Internal
Untranslate 205.215.240.104/443 to 192.168.17.235/443

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

Result:
input-interface: External
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,

Seems to me that the above "packet-tracer" is matching to a destination IP address that is used in a Static NAT configuration.

I can't find this configuration in the one you originally attached to the post above.

You are most likely lacking an ACL rule so you should probably add the following rule (if you changed any ACL name then use that instead in the example below)

access-list External_access_in permit tcp any object SophosServer eq 443

Naturally allow any other services you might need or limit the source addresses allowed instead of the "any" if needed.

Then try again.

- Jouni

That did not solve the problem and there is a global acl that permits any on outside interface to SophosServer on both http and https

It appears that there is some global implicit rule which is blocking at last step. 

Hi,

I am not quite sure what the purpose of this ACL is but I think its causing it

access-list Internal_access_out extended deny ip any host 97.168.17.100

access-group Internal_access_out out interface Internal

- Jouni

Took it out did not help.  It apprears the the implicit rules for Ipv4 to allow outbound access to any less secure are missing from all interfaces but exist as ipv6 rules for all interfaces. There is a global implicit any to any deny rule

Hi,

I am not really sure how your configuration is at the moment.

You said earlier that you have some global ACL attached.

This is not shown in the configuration you attached.

The most common reasons that I have seen that "packet-tracer" would deny traffic like that are

  • The "security-level" of the interfaces related to this traffic deny this traffic
  • The "security-level" of the interfaces related to this traffic are equal and the "same-security-traffic" is missing
  • The traffic hits some interface ACLs Implicit Deny rule
  • Probably some other things I have forgotten

Can you attach the latest configuration to the post so can look through it.

- Jouni

Hi,

It still seems to me that the above mentioned ACL is blocking these connections.

There is first an ACL check at the Phase 3 which to my understanding might now be the Global ACL.

Then we see the ACL check again at Phase 6 and I think this is the above mentioned ACL that is attached to the "Internal" interface in the "out" direction. So it would basically check connections that are formed towards the networks behind "Internal".

The reason why it is hitting some Implicit Deny rule is because the above ACL only has a single configured "deny" rule which this traffic doesnt match. Therefore it matches the Implicit Deny in the end of that ACL.

- Jouni

Review Cisco Networking for a $25 gift card