07-13-2013 05:16 AM - edited 03-11-2019 07:11 PM
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
07-13-2013 05:21 AM
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
07-13-2013 06:00 AM
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
07-13-2013 08:31 AM
Any ideas?
07-13-2013 08:48 AM
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
07-13-2013 12:08 PM
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.
07-13-2013 12:25 PM
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.
07-13-2013 12:30 PM
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
07-13-2013 12:55 PM
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."
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide