Inter-VLAN Security Not Working and Egress Interface Issues

[jasondharper]

Hello!

I have a factory default ASA 5505 with minimal configuration (version 9.1(3)).  I have designated Ethernet0/0 as the OUTSIDE interface and Ethernet0/1 is a trunk for my two internal VLANs:

interface Ethernet0/0

description ISP

switchport access vlan 150

interface Ethernet0/1

description INTERNAL

switchport trunk allowed vlan 1, 10, 20

switchport trunk native vlan 1

switchport mode trunk

...

interface Vlan1

nameif INSIDE

security-level 100

ip address 192.168.1.1 255.255.255.0

interface Vlan10

nameif INTERNAL1

security-level 100

ip address 192.168.10.1 255.255.255.0

interface Vlan20

nameif INTERNAL2

security-level 100

ip address 192.168.20.1 255.255.255.0

interface Vlan150

nameif OUTSIDE

security-level 0

ip address 123.123.123.123 255.255.255.248

ISSUE #1:

When I enter the commands same-security-traffic permit inter-interfface and same-security-traffic permit intra-interface, I'm able to ping and access servers from VLAN10 to VLAN20 and vice versa - no problem.  However, I want to be able to control what hosts in VLAN10 can access services in VLAN20 so I create an access list:   access-list VLAN20_access_in extended permit ip host 192.168.10.100 192.168.20.0 255.255.255.0 / access-group VLAN20_access_in in interface INTERNAL2.

While this ACL does stop ping from working, I'm still able to access services in VLAN20 from hosts other than 192.168.10.100 in VLAN10.  The ACL doesn't seem to be having any impact on controlling traffic into that VLAN.  I need to be able to restrict what traffic/hosts are permitted to enter VLAN20.

ISSUE #2:

I want to be able to manage the ASA using its INTERNAL2/VLAN20 IP address FROM the INTERNAL1/VLAN10 subnet.  I've created the appropriate rules for allowing management access.  However, when I try to access the 192.168.20.1 address from the 192.168.10.X subnet, I get the following syslog message:  Failed to locate egress interface for TCP from INTERNAL1:192.168.10.100/50467 to 192.168.20.1/443

Also, if issue this command from the CLI:  show route INTERNAL1 192.168.20.1, it doesn't show any routes and instead just shows me the gateway of last resort (my outside network).  This is strange because a show route does show the networks directly connected.

I feel like I'm missing something obvious but just can't put my finger on it.  I sincerely appreciate any help!!

Jason

[Jouni Forss · Accepted solution]

Hi,

With regards to the ISSUE 1 it sounds to me like you want to control connections initiated from Vlan10 to Vlan20. Yet it seems you create an ACL for Vlan20 rather than Vlan10?

You would typically configure an inbound interface for Vlan10 to control which connections can be formed through that interface towards any other network. If you have an inbound ACL configured on interface Vlan20 and host on Vlan10 is without an interfacel ACL and initiates the connection its built and passed through the ASA and the Vlan20 interface ACL will have absolutely nothing to do with the connection (return traffic for it) getting through from Vlan20 to Vlan10.

So you should control the traffic with an inbound interface ACL on the interface closest to the source network.

The reason why the ICMP traffic was perhaps stopped is that you might not have ICMP Inspection enabled which means that ACL rules would be required on both interfaces (as the ASA without Inspection ICMP doesnt keep track of the return messages for the ICMP Echo messages)

With regards to the ISSUE 2 there is a limitation that is causing your problems. You wont be able to connect to an ASA interface from anywhere else than from a network that is located behind that interface. So networks behind Vlan10 can connect to interface Vlan10 IP address and networks behind Vlan20 can connect to the interface Vlan20 IP address.

The only exception to this is when a connection is incoming from a VPN Connection to the ASA. Then with an additional command you would be able to connect to another interface (different from where the connection is coming from. But as I said this is specifically for management connections initiated through VPN.

So you will have to manage the ASA through the interface IP address behind which you are at the moment.

Hope this helps

- Jouni

[jasondharper]

Hi Jouni,

That helps a great deal - thank you!  I tried putting the ACL on the source interface and that seemed to do the trick as far as access to the other VLAN.

I would just have a few questions as to how this will impact other configurations...

1.  Will the same work for an interface going from a lower security level to a higher security level?  For example, if INT1 were security level 10 and INT2 were security level 20, would placing an inbound access list on INT1 to access hosts in INT2 still work?

2.  If I have a VLAN that is for server management only and want to disallow all access from other VLANs except VLAN10 (INT1), do I just need to put a deny ACL on the inbound interfaces for all other VLANs except VLAN10?

Also, on the management connection issue, that makes sense - glad to know it is a product limitation and not something I was doing wrong.  But, to that point, I do plan to manage the ASA from an incoming VPN connection.  You mentioned there's something I need to do?

Thank you again!!
Jason

[Jouni Forss]

Hi,

I would generally recommend that you use "access-list" inbound on every interface. The reason for this is that as soon as you attach an "access-list" to one of your interfaces with the "access-group" command this essentially makes the "security-level" value nonessential. (Only exceptions are interfaces with same "security-level" which still require "same-security-traffic permit inter-interface" enabled even if "access-group" for the interface is configured)

Considering the above I think its much clearer to start with configuring ACL to each interface from the get go so it stays simple and clear. Only relying on "security-level" value on the interfaces doesnt really give any flexibility and you are bound to need interface ACLs if you need to both allow and block traffic from one interface to another.

So if there are certain interface from which you want to limit traffic to another then I would suggest simply starting the ACL with a "deny" statement towards the network that should not be reachable from behind this interface (where the ACL is applied) and then allowing all other traffic in the next "permit" statement. Naturally adding "remark" lines to the ACL will keep it easier to read depending how large the ACL grows.

So a very simple ACL could be

access-list ACL remark Deny connections to DMZ network

access-list ACL deny ip any

access-list ACL remark Allow all other traffic

access-list ACL permit ip any

access-group ACL in interface

Naturally if you needed to allow some traffic to the blocked destination network you could simply add those "permit" statements at the top of the ACL which would still block other connectivity to the destination network.

If you want to configure a VPN Client connection and want to manage the ASA while connecting to some of its internal interface then you can add the command

management-access

This together with the proper NAT0 configuration would enable you to access the ASA by connecting to the specified interfaces IP address.

To my understanding this command can be configured only for a single interface.

Hope this helps

- Jouni

[jasondharper]

Thank you Jouni - that makes perfect sense!

I'm not sure if it's related, but I'm having an issue with NAT on one of the inside interfaces to the outside.  At the moment, I have the following:

object network OUTBOUND-INTERNAL1

  nat (INTERNAL1, OUTSIDE) dynamic 123.123.123.123

object network OUTBOUND-INTERNAL2

  nat (INTERNAL2, OUTSIDE) dynamic 123.123.123.123

This works fine for internet access - I can surf the web outbound from both subnets.  However, when I apply a static NAT to my webserver, it loses internet access:

object network WEBSERVER1

  host 192.168.20.2

object network WEBSERVER1

  nat (INTERNAL2,OUTSIDE) static 123.123.123.124

Then I have the appropriate ACL on the OUTSIDE interface to allow www in.  But when I apply the NAT above, I can't connect to the webserver from the outside and the webserver loses outbound internet access.  I can't think of what I'm doing wrong.

A HUGE thank you again!
Jason

[Jouni Forss]

Hi,

Since you have both your Dynamic PAT and Static NAT configured as Section 2 Auto NAT (basically NAT configured under "object network") this means the ASA should automatically order them properly. In other words the host with the Static NAT uses its own public IP address and rest of the internal hosts use the Dynamic PAT.

The above configuration in its format is fine but it doesnt tell everything naturally.

For example I dont know if the public IP address used is really from the same subnet that is configured on the "OUTSIDE" interface. If its from that same network I would assume that it should work unless you have issued the command "sysopt noproxyarp OUTSIDE" which would disable the ASA from answering ARP request made for the IP address 123.123.123.124 and any other public IP address other than the one configured on the "OUTSIDE" interface directly.

If you have a separate link network between the ISP and the router/gateway in front of the ASA and then a separate public subnet for NAT purposes then there is always a chance that when using new software you would need the "arp permit-nonconnected" so that the ASA would reply to ARP requests for IP address that do not belong to its directly connected networks.

You could naturally confirm that the configuration is correct after the NAT change with the "packet-tracer" command.

For example

packet-tracer input INTERNAL2 tcp 192.168.20.2 12345 8.8.8.8 80

This should tell what you happen if the host that was just configured with Static NAT was attempting to connect to the external network to the destination address 8.8.8.8 with destination port TCP/80

You could naturally simulate the the same in other direction to make sure those rules are fine

packet-tracer input OUTSIDE tcp 8.8.8.8 12345 80

You can share the output of the above commands if there is some problem with them going through the test.

If nothing of the above tells us the problem we will probably start to test connectivity to the host from the external network and see if the traffic is even forwarded to your ASA from the ISP.

Hope this helps

Please do remember to mark replies as the correct answer if they have answered your question.

Feel free to ask more though

- Jouni

[jasondharper]

Hi Jouni,

I can't tell you how much I appreciate the help.  This is odd - but everything appears to be fine with the packet tracer (output from both tests pasted below). 

My OUTSIDE interface addresss is x.x.x.x (the whole block is  173.165.x.x 255.255.255.248).  The default route points to  173.165.x.x which is the ISP router.  I am using 173.165.x.x for  outbound dynamic NAT and this is working correctly -  whatismyipaddress.com indicates 173.165.x.x. 

When a monitor logging, I don't see any attempts to  hit the IP I have NAT'ed my webserver to (173.165.x.x ->  192.168.1.12).  I know my IP block is good because the ASA is just  replacing an IOS router that I had working with this same NAT setup.   I'm a bit puzzled!

firewall-1# packet-tracer input INSIDE tcp 192.168.1.12 12345 8.8.8.8 80

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   0.0.0.0         0.0.0.0         OUTSIDE

Phase: 3

Type: NAT

Subtype:

Result: ALLOW

Config:

object network FFATLWEB001

nat (INSIDE,OUTSIDE) static 173.165.x.x

Additional Information:

Static translate 192.168.1.12/12345 to 173.165.x.x/12345

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: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (any,OUTSIDE) after-auto source dynamic OUTBOUND-INTERNET OUTSIDE-173.165.x.x

Additional Information:

Phase: 7

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 30512, packet dispatched to next module

Result:

input-interface: INSIDE

input-status: up

input-line-status: up

output-interface: OUTSIDE

output-status: up

output-line-status: up

Action: allow

firewall-1# packet-tracer input OUTSIDE tcp 8.8.8.8 12345 173.165.x.x 80

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network FFATLWEB001

nat (INSIDE,OUTSIDE) static 173.165.x.x

Additional Information:

NAT divert to egress interface INSIDE

Untranslate 173.165.x.x/80 to 192.168.1.12/80

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group OUTSIDE_access_in in interface OUTSIDE

access-list OUTSIDE_access_in extended permit ip any object FFATLWEB001

Additional Information:

Phase: 3

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

object network FFATLWEB001

nat (INSIDE,OUTSIDE) static 173.165.x.x

Additional Information:

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: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 30644, 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

[Jouni Forss]

Hi,

So configurations matched by the test seem to be correct and no clear problem with the ASA configurations.

I would next issue this command and share the output

show run all sysopt

If there is no problem with this then I think we need to confirm that traffic destined to the Static NAT public IP address is really coming to the ASA at all.

Though generally if the we dont see any traffic from any source address to a specific public IP address used in NAT on the ASA then it means that there is some ARP or perhaps routing related problems between the ASA and the ISP.

If you are able to use some other Internet connection (even a mobile phone) and try to access the server externally with some service you should be able to confirm if the ASA sees this traffic at all.

You could for example configure the following capture on the ASA

access-list CAPTURE permit ip any host

access-list CAPTURE permit ip host any

capture CAPTURE type raw-data access-list CAPTURE interface OUTSIDE buffer 10000000 circular-buffer

This with we could confirm if anything is coming to the ASA at all to the public IP address of the server ()

You can then test connections once or twice and then issue this command to check if anything is captured

show capture

If there is some captured traffic then you can use this command to show that in the CLI

show capture CAPTURE

You can also copy the actual capture Data to a file on some PC and view it with Wireshark

copy /pcap capture:CAPTURE tftp://x.x.x.x/CAPTURE.pcap

You can remove the capture with the command

no capture CAPTURE

This will remove the capture and the captured data. You will have to remove the created ACL separately.

I would suggest removing any actual public IP address from the posts and replacing them with some fake IP addresses just that that information doesnt stay here publicly.

- Jouni

[jasondharper]

Thank you Jouni!

Here is the output of show run all sysopt:

sysopt connection tcpmss 1380

sysopt connection tcpmss minimum 0

sysopt connection permit-vpn

sysopt connection reclassify-vpn

no sysopt connection preserve-vpn-flows

no sysopt radius ignore-secret

no sysopt noproxyarp INSIDE

no sysopt noproxyarp 445WBC

no sysopt noproxyarp OUTSIDE

I also tried to run the capture commands but got the following error when I issued the command:

ERROR: Capture doesn't support access-list containing mixed policies

Also, if it helps at all, when I browse to the IP of my website from the outside (using my phone), I get a 502 Bad Gateway Error.  However, if I browse to the internal IP from inside the network, the website comes right up.  And the same issue as before with internet access is still there - if I remove the NAT, the webserver can access the internet with no problem using the outbound dynamic NAT IP.  Once I apply the static NAT to the webserver, it can no longer access the internet.

Jason

PS - Thank you for the tip on the public IP's!

[jasondharper]

Hi Jouni,

Strange - I rebooted my ISP router and the ASA and now everything appears to be working correctly.  I will mark the original answer as correct.  Thank you SO much for the help!  I'm sure I'll have plenty more questions!  :-)

Jason

[Jouni Forss]

Hi,

Great to hear its working

I guess it might have been an ARP issue. Might be that if you were using the old device at some point and switched to ASA that the ARP for the additional public IP addresses used in Static NAT did not update on the ISP Router. In Cisco devices atleast I think the default ARP timeout is 4h.

Not sure if it was that though.

- Jouni