ā10-09-2013 10:59 AM - edited ā03-11-2019 07:49 PM
am i missing anything ? can't seem to get it working
object network obj-192.168.1.5
nat (inside,outside) static 70.60.200.200 service tcp 8000 8000
access-group OUTSIDETOINSIDE in interface outside
access-list OUTSIDETOINSIDE extended permit tcp any host 192.168.1.5 eq 8000
ASA 5512 (8.6)
sh nat:
Auto NAT Policies (Section 2)
2 (inside) to (outside) source static obj-192.168.1.5 70.60.100.200 service tcp 8000 8000
translate_hits = 1, untranslate_hits = 5
show local-host:
no entries for this nat statement
Thanks ???
Solved! Go to Solution.
ā10-09-2013 11:42 AM
Hi,
I would suggest that you test the connection from the external network and check the "show access-list OUTSIDETOINSIDE" output for the rule you have to allow the traffic and confirm that its getting increase in the hitcount.
If it is then you should confirm through the ASDM monitor/logging what happens to the connections. Do they end in "SYN Timeout" or what do they show.
- Jouni
ā10-09-2013 11:04 AM
Hi,
Issue the following command
packet-tracer input outside tcp 1.1.1.1 12345 70.60.200.200 8000
and post the output here.
It would seem that traffic has hit the NAT configurations. I guess it might even be a problem on the actual internal host.
Why are you using Static PAT by the way? Or do you only have a few public IP addresses and cant afford to assign this public IP address to just this host 192.168.1.5?
- Jouni
ā10-09-2013 11:10 AM
Thanks JouniForss, yes we have a few public IP addresses.
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 obj-192.168.1.5
nat (inside,outside) static 70.60.200.200 service tcp 8000 8000
Additional Information:
NAT divert to egress interface inside
Untranslate 70.60.200.200/8000 to 192.168.1.5/8000
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDETOINSIDE in interface outside
access-list OUTSIDETOINSIDE extended permit tcp any host 192.168.1.5 eq 8000
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network obj-192.168.1.5
nat (inside,outside) static 70.60.200.200 service tcp 8000 8000
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 15169948, 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
ā10-09-2013 11:14 AM
Hi,
The "packet-tracer" test seems to go through just fine.
I would next try perhaps TCP Ping from the ASA
ping tcp 192.168.1.5 8000
This should sen TCP SYN to the internal host and you should see if it replies on that port
Naturally you have also use the "netstat" command on the actual host (If windows host) command prompt to see if its listening on the mentioned port TCP/8000.
- Jouni
ā10-09-2013 11:20 AM
Pings are also sucessful. /8000
It isn't a windows host, it's a video appliance, and the 192.168.1.5:8000 url can be viewed from a web broswer from
an internal host on the same subnet and other internal subnets.
ā10-09-2013 11:42 AM
Hi,
I would suggest that you test the connection from the external network and check the "show access-list OUTSIDETOINSIDE" output for the rule you have to allow the traffic and confirm that its getting increase in the hitcount.
If it is then you should confirm through the ASDM monitor/logging what happens to the connections. Do they end in "SYN Timeout" or what do they show.
- Jouni
ā10-09-2013 11:58 AM
Deny TCP (no connection) from 192.168.1.5/8000 to 34.240.16.79/16002 flags SYN ACK on interface inside
you are right !
ā10-09-2013 12:02 PM
Hi,
If I am not wrong that would seem like the TCP SYN has reached the device through some other external connection and the device now sends the TCP SYN ACK (part 2 of the 3 way handshake of TCP connection) to the ASA and ASA blocks it since it has not seen the original SYN.
So is there asymmetric routing happening here?
- Jouni
ā10-09-2013 12:23 PM
This maybe true,. has the 192.168.1.0/24 subnet is vlan to and subinterface on the asa.
and then routes to back to cisco 3560 svi.
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