09-20-2010 04:41 PM - edited 03-11-2019 11:42 AM
Hi Everyone,
I have configured mac-address auto on the system context because two of the contexts share the outside interface. I have configured NAT on the outside interface as a one-to-one nat to translate to a server ip.
I have configured the access-lists and nat rules and everything else. Now when someone tries to RDP to the NAT address, its able to recieve SYN packets but its not able to push it out to the server.
Is there anything wrong with my mac-address auto command. Do i need to do anything else? The
Router -----> Switch -----> Firewall ------> Switch ------> other network devices
Above highlighted switch are the same. The switch sends it to the outside interface of the firewall and firewall sends it to back to the switch out the DMZ interface.
Below is my config
SYSTEM CONTEXT
================
mac-address auto
interface GigabitEthernet0/2.1000
description --- inside---
vlan 1000
interface GigabitEthernet0/1.2000
description --- dmz---
vlan 2000
interface GigabitEthernet0/0/100
description ---outside---
vlan 100
context CustomerA
member gold
allocate-interface GigabitEthernet0/1.2000 dmz
allocate-interface GigabitEthernet0/2.1000 inside
allocate-interface GigabitEthernet0/0.100 outside //shared interface
config-url disk0:/CustomerA.cfg
CUSTOMER A CONTEXT
===================
interface dmz
nameif dmz
security-level 70
ip address 192.168.12.254 255.255.255.0 standby 192.168.12.253
interface inside
nameif inside
security-level 100
ip address 192.168.13.254 255.255.255.0 standby 192.168.13.253
interface outsidesharedinternet
nameif outside
security-level 0
ip address 10.10.50.104 255.255.255.0 standby 10.10.50.105
static (dmz,outside) 4.2.2.2 192.168.12.10
nat (inside) 1 0 0
global (outside) 1 4.2.2.3
access-list outside extended permit tcp any host 4.2.2.2 eq 3389
access-list outside extended permit icmp any any
access-list dmz extended permit tcp any any eq http
access-list dmz extended permit tcp any any eq https
access-list dmz extended permit tcp any any eq ftp
access-list dmz extended permit tcp any any eq 22
access-list dmz extended permit udp any any eq 53
access-list dmz extended permit icmp any any
access-list inside extended permit tcp any any eq http
access-list inside extended permit tcp any any eq https
access-list inside extended permit tcp any any eq ftp
access-list inside extended permit tcp any any eq 22
access-list inside extended permit udp any any eq 53
access-list inside extended permit icmp any any
access-group outside in interface outside
access-group inside in interface inside
access-group dmz in interface dmz
ip route 0.0.0.0 0.0.0.0 10.10.50.1
Thanks
Sid
09-20-2010 05:02 PM
Sid,
What version of ASA software are you running? Please provide any syslogs that you receive at the time of the issue - preferably at the 'debugging' level. Also, configure a packet capture for the relevant traffic. Here are a couple of tools that will assist us in finding out the reason that the packet is not making it through the ASA.
1.) Packet Tracer
For the flow that is exhibiting the issue, run the following command:
packet-tracer input outside tcp 1.1.1.1 5555
This will provide the step-by-step of the packet through the Finite State Machine of the ASA. Looking at this output, you will want to focus on the step that has a result of DROP - this often provides a hint as to why the ASA is not allowing the packet through the ASA.
2.) Packet capture (with/without the 'trace') command
On ASA 8.0(x)+, you can do a packet capture that will integrate the Packet Tracer output as above. The packet capture command on 8.0(x)+ will look like the following:
capture
Did you perform the packet capture to confirm that the SYN packet did indeed arrive on the ASA? Did an egress packet capture confirm that the SYN packet did leave towards the server?
3.) Routes Translations Permission:
For the flow, confirm that the Route, Translation, and Permissions exist:
Route - make sure that there is a valid route pointing out the correct interface to reach the server. If this route exists, make sure that there is an ARP entry for the next hop router or, in this case, the server.
Translation - It seems as though you have the translation for the server.
Permissions - Make sure that you are allowing access to the server via an access-list/access-group pair. If you are using ASA 8.3, make sure that this access-list entry is using the REAL IP address (ie the 192.168.12.10 address as provided in your example).
Any of the information that you can provide above (ie the packet tracer, packet capture, and syslogs) will greatly assist in our ability to diagnose this issue.
Best Regards,
Kevin
09-20-2010 05:07 PM
Thanks Kevin for the reply,
I will perform all the troubleshooting procedures that you described and give you the results.
I did perform the capture command and it was recieving SYN packets to the NAT address but not going any further. My doubt lies whether the mac-address auto is functioning properly.
I should update the result in t he next 1-2 hours.
Thanks
Sid
09-20-2010 05:08 PM
BTW i am using 8.0(4) IOS
09-20-2010 07:06 PM
I am unable to ping any of the 192.168.12.0 addresses including the SVI on the switch as well as the server ip. I can ping everything else.
Phase: 1
Type: VIRTUAL-FW-CLASSIFY
Subtype:
Result: ALLOW
Config:
Additional Information:
Destination 4.2.2.2 Mask 255.255.255.255 Context CustomerA Interface outside
Phase: 2
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaec5e898, priority=12, domain=capture, deny=false
hits=3, user_data=0xaf19f730, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaecaf9e8, priority=1, domain=permit, deny=false
hits=1091, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
Phase: 4
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow
Phase: 5
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (dmz,outside) 4.2.2.2 192.168.12.10 netmask 255.255.255.255
match ip dmz host 192.168.12.10 outside any
static translation to 4.2.2.2
translate_hits = 0, untranslate_hits = 522
Additional Information:
NAT divert to egress interface dmz
Untranslate 4.2.2.2/0 to 192.168.12.10/0 using netmask 255.255.255.255
Phase: 6
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside in interface outside
access-list outside extended permit tcp any host 4.2.2.2 eq 3389
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaed52428, priority=12, domain=permit, deny=false
hits=8, user_data=0xaf341ba8, cs_id=0x0, flags=0x0, protocol=6
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=4.2.2.2, mask=255.255.255.255, port=3389, dscp=0x0
Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaf036480, priority=0, domain=permit-ip-option, deny=true
hits=59, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 8
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaebab688, priority=20, domain=lu, deny=false
hits=8, user_data=0x0, cs_id=0x0, flags=0x0, protocol=6
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 9
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xaeef57b8, priority=12, domain=capture, deny=false
hits=1, user_data=0xaf19f730, cs_id=0xaf015618, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=4.2.2.2, mask=255.255.255.255, port=0, dscp=0x0
Phase: 10
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0xaf03e7c8, priority=12, domain=capture, deny=false
hits=0, user_data=0xaedcfc40, cs_id=0xaec5dc20, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 11
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (dmz,outside) 4.2.2.2 192.168.12.10 netmask 255.255.255.255
match ip dmz host 192.168.12.10 outside any
static translation to 4.2.2.2
translate_hits = 0, untranslate_hits = 522
Additional Information:
Forward Flow based lookup yields rule:
out id=0xaeb03358, priority=5, domain=nat-reverse, deny=false
hits=22, user_data=0xaeac30b0, cs_id=0x0, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=192.168.12.10, mask=255.255.255.255, port=0, dscp=0x0
Phase: 12
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xaf45aa68, priority=12, domain=capture, deny=false
hits=0, user_data=0xaedcfc40, cs_id=0xaec5dc20, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 13
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (dmz,outside) 4.2.2.2 192.168.12.10 netmask 255.255.255.255
match ip dmz host 192.168.12.10 outside any
static translation to 4.2.2.2
translate_hits = 0, untranslate_hits = 522
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xaeb03520, priority=5, domain=host, deny=false
hits=44, user_data=0xaeac30b0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=192.168.12.10, mask=255.255.255.255, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 14
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xaee4ef00, priority=0, domain=permit-ip-option, deny=true
hits=22, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
Phase: 15
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 1702915, packet dispatched to next module
Module information for forward flow ...
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_adjacency
snp_fp_fragment
snp_fp_tracer_drop
snp_ifc_stat
Module information for reverse flow ...
snp_fp_inspect_ip_options
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_fp_tracer_drop
snp_ifc_stat
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: _dmz
output-status: up
output-line-status: up
Action: allow
4 packets captured
1: 11:21:15.601500 802.1Q vlan#50 P0 1.1.1.1.5555 > 4.2.2.2.3389: S 1876575870:1876575870(0) win 8192
2: 11:24:09.445548 802.1Q vlan#50 P0 6.6.6.6.28289 > 4.2.2.2.3389: S 3452255151:3452255151(0) win 64512
3: 11:24:12.456595 802.1Q vlan#50 P0 6.6.6.6.28289 > 4.2.2.2.3389: S 3452255151:3452255151(0) win 64512
4: 11:24:18.491643 802.1Q vlan#50 P0 6.6.6.6.28289 > 4.2.2.2.3389: S 3452255151:3452255151(0) win 64512
4packets shown
09-20-2010 08:20 PM
Pls. check the following:
1. check the debug level syslogs in admin context
2. sh cap
check the source mac and destination mac and make sure it is the same mac that the "sh int" shows.
-KS
09-20-2010 10:15 PM
Hi Kusankar,
There was a routing issue at the router end. The issue has been resolved
thansks for the help again
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: