topic Shared Interfaces in a user context in Network Security

Shared Interfaces in a user context

turbo_engine26 — Tue, 12 Mar 2019 02:11:47 GMT

Hello Cisco-ers,

I created 2 user contexts recently to two of my company's departments. I allocated a shared outside interface and separate unique inside interfaces to them both. Both contexts are working perfect after i issued the "mac-address auto" command in the sys. space. Before this command, both contexts didn't work at all. Now i need someone to explain to me, why the contexts didn't use the NAT entries as a method for identifying which context should the outside interface's classifier place the traffic.

Thanks

Shared Interfaces in a user context

Jouni Forss — Sat, 13 Jul 2013 12:21:09 GMT

Hi,

I am not completely sure what you situation is but I have never run into problems even when NOT using "mac-address auto"

What is the software level you are running?

What are the NAT configurations used without "mac-address auto"?

Could you share the Context configurations, wihtout any real public IP addresses ofcourse

- Jouni

Re: Shared Interfaces in a user context

turbo_engine26 — Sat, 13 Jul 2013 13:00:59 GMT

Thx for the reply.

The situation here is the appliance shares an interface across multiple contexts. Because of this, the same MAC address is used. As already known, there are 2 methods the appliance use to solve the issue of identifying to which context it should place a user's traffic on. First method, using NAT entries and Second method, using unique MAC addresses.

Now, the first method didn't work and i have no idea why (see the config.). NAT entries are also unique just as MAC addresses i wonder why the appliance didn't use this method and forced me to use the second method.

Check the below config.

System Space:

ciscoasa# sh run

: Saved

ASA Version 8.4(2)

hostname ciscoasa

domain-name test.com

enable password 8Ry2YjIyt7RRXU24 encrypted

no mac-address auto

interface GigabitEthernet0

interface GigabitEthernet1

interface GigabitEthernet2

interface GigabitEthernet3

shutdown

interface GigabitEthernet4

shutdown

interface GigabitEthernet5

shutdown

class default

limit-resource All 0

limit-resource ASDM 5

limit-resource SSH 5

limit-resource Telnet 5

ftp mode passive

pager lines 24

no failover

no asdm history enable

arp timeout 14400

console timeout 0

admin-context admin

context admin

allocate-interface GigabitEthernet0

allocate-interface GigabitEthernet1

allocate-interface GigabitEthernet2

config-url disk0:/admin.cfg

context CustA

allocate-interface GigabitEthernet0 CustA_Inside

allocate-interface GigabitEthernet1 CustA_Outside

config-url tftp://192.168.4.100/CustA.cfg

context CustB

allocate-interface GigabitEthernet1 CustB_Outside

allocate-interface GigabitEthernet2 CustB_Inside

config-url tftp://192.168.3.100/CustB.cfg

prompt hostname context

no call-home reporting anonymous

call-home

profile CiscoTAC-1

no active

destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService

destination address email callhome@cisco.com

destination transport-method http

subscribe-to-alert-group diagnostic

subscribe-to-alert-group environment

subscribe-to-alert-group inventory periodic monthly

subscribe-to-alert-group configuration periodic monthly

subscribe-to-alert-group telemetry periodic daily

crashinfo save disable

Cryptochecksum:bb370df4ae90ab9b782d9d6eea1c91a0

: end

ciscoasa#

-------------------------------------------------------------------------------------------

CustA Context:

ciscoasa/CustA# sh run

: Saved

ASA Version 8.4(2)

hostname CustA

enable password 8Ry2YjIyt7RRXU24 encrypted

passwd 2KFQnbNIdI.2KYOU encrypted

names

interface CustA_Inside

nameif Inside

security-level 100

ip address 192.168.4.3 255.255.255.0

interface CustA_Outside

nameif Outside

security-level 0

ip address 192.168.1.2 255.255.255.0

object-group network Internal

network-object 192.168.4.0 255.255.255.0

object-group network External

network-object 192.168.1.25 255.255.255.255

pager lines 24

mtu Inside 1500

mtu Outside 1500

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

nat (Inside,Outside) source dynamic Internal External

route Outside 0.0.0.0 0.0.0.0 192.168.1.254 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02

timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00

timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00

timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute

timeout tcp-proxy-reassembly 0:01:00

timeout floating-conn 0:00:00

user-identity default-domain LOCAL

no snmp-server location

no snmp-server contact

telnet timeout 5

ssh timeout 5

no threat-detection statistics tcp-intercept

class-map inspection_default

match default-inspection-traffic

policy-map type inspect dns preset_dns_map

parameters

message-length maximum client auto

message-length maximum 512

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect ip-options

inspect netbios

inspect rsh

inspect rtsp

inspect skinny

inspect esmtp

inspect sqlnet

inspect sunrpc

inspect tftp

inspect sip

inspect xdmcp

service-policy global_policy global

Cryptochecksum:a54fb97947d70811a9437dae93bfeae4

: end

ciscoasa/CustA#

Thanks

Re: Shared Interfaces in a user context

turbo_engine26 — Sat, 13 Jul 2013 15:31:00 GMT

Any ideas?

Shared Interfaces in a user context

Jouni Forss — Sat, 13 Jul 2013 15:48:31 GMT

Hi,

I am not sure,

You are using the same software which we have on one of our ASAs for example.

It has around 100 Security Contexts which all share an interface and the connection work as usual. This interface is actually used for Logging and Monitoring purposes. It doesnt have any kind of Dynamic Translation but might have Static translations and not even them always.

Are you seeing some message on the ASA specifically when the connections fail that would indicate that the incoming packet wasnt classified?

I am not sure but mayb even the ASAs own "packet-tracer" might tell if this is actually the problem. Remember seeing such output once here on the forums. Though for that you coould try to configure a single Static NAT for example and use "packet-tracer" to simulate an incoming connection to that IP address.

packet-tracer input Outside tcp 1.1.1.1 12345

Maybe you could try the Dynamic PAT configuration using the actual interface IP address and see if that makes any different to what you are seeing.

nat (Inside,Outside) after-auto source dynamic any interface

The documents dont really state specific information about the NAT way of classifying the right context for the incoming packet. This would indicate that there should simply be a unique NAT (of any type) IP address on some context to which traffic is sent and the ASA should be able to determine that context on the basis of its NAT configurations.

- Jouni

Re: Shared Interfaces in a user context

turbo_engine26 — Sat, 13 Jul 2013 19:08:13 GMT

Thx again for the reply.

Unfortunately, none of the solutions given worked for me. I have no clue what is going on. As you said, the appliance should be able to identify the context based on a unique NAT entry owned by that context. I used static NAT, static PAT, dynamic NAT, Interface overload, you name it. Nothing is working.

However, i noticed many dropped packets in the inside interface when i issued the "show interface CustAInside" command. This is normal if the appliance has no clue to which context to place those packets on. But i still don't know what is the cause of the problem.

Re: Shared Interfaces in a user context

turbo_engine26 — Sat, 13 Jul 2013 19:25:58 GMT

There is something else.

I am using the VPN Plus license. I have a maximum of 2 contexts. I don't think this is the problem because i am using exactly 2 contexts only and the admin context is not counted among this number.

Shared Interfaces in a user context

Jouni Forss — Sat, 13 Jul 2013 19:30:05 GMT

Hi,

Did you take any "packet-tracer" output when trying Static NAT or Static PAT on the Contexts?

I do seem to recall that "packet-tracer" should state in the output if there was a problem with classifying the correct Security Context (even though we are doing this under a certain context).

- Jouni

Re: Shared Interfaces in a user context

turbo_engine26 — Sat, 13 Jul 2013 19:55:05 GMT

For unknown reason, i can't paste the tracer output here. It tells me "this message can not be displayed due to its content. Please use the contact us link with any questions."