05-01-2013 02:26 PM - edited 03-11-2019 06:37 PM
Hi
I am trying to get two external addresses to PAT to different ports on the same address in the dmz.
Object NAT is configured as follows:
object network Obj-192.168.1.20-1
nat (dmz,outside) static Obj-External-1 service tcp https https
object network Onj-192.168.1.20-2
nat (dmz,outside) static Obj-External-2 service tcp 2000 https
Obj-192.168.1.20-1 and Obj-192.168.1.20-2 contain the same host address.
The idea being that traffic destined for Obj-External-1 on port 443 will be forwarded to Obj-192.168.1.20-1 on port 443. Traffic for Obj-External-2 on port 443 will be forwarded to Obj-192.168.20-2 on port 2000.
Traffic for the first object, Obj-192.168.1.20-1, works but traffic for the second does not.
Can anyone help?
Thanks
Paul
Solved! Go to Solution.
05-01-2013 02:53 PM
Hi,
The test seems to go through.
As you can see it also hits the "inspect skinny" configuration. I am kinda wondering if using the "inspect skinny" configuration drops these or has anything to do with this not working? Though I cant see any drops by that inspection on my ASA atleast while testing.
If there a change to either remove the "inspect skinny" OR change the listening port to something else from the port TCP/2000?
This setup should work and just to be sure I just tested this on my own ASA with no problems.
Have you monitored what happens to the connections when they are initiated to this public IP address? (Looking at ASA logs through the ASDM or Syslog server) Can you monitor the logs and see if the TCP connection perhaps gets teardown with SYN Timeout or perhaps TCP Reset
You can also test the availability of the port TCP/2000 from the ASA directly with the following command
ping tcp 192.168.1.20 2000
- Jouni
05-01-2013 02:30 PM
Hi,
What does the "packet-tracer" test say about connections coming to the second exteternal IP address on the mapped port TCP/443?
Take the output of the command
packet-tracer input outside tcp 1.2.3.4 12345
And share it here
- Jouni
05-01-2013 02:43 PM
Thanks Jouni
Output below:
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network Obj-192.168.20-2
nat (dmz,outside) static Obj-External-2 service tcp 2000 https
Additional Information:
NAT divert to egress interface dmz
Untranslate 194.168.208.72/443 to 192.168.1.20/2000
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit tcp any object Obj-192.168.1.20-1 eq 2000
Additional Information:
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: INSPECT
Subtype: inspect-skinny
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect skinny
service-policy global_policy global
Additional Information:
Phase: 7
Type: IDS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 9
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network Obj-192.168.1.20-2
nat (dmz,outside) static Obj-External-2 service tcp 2000 https
Additional Information:
Phase: 10
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 7479639, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: dmz
output-status: up
output-line-status: up
Action: allow
05-01-2013 02:53 PM
Hi,
The test seems to go through.
As you can see it also hits the "inspect skinny" configuration. I am kinda wondering if using the "inspect skinny" configuration drops these or has anything to do with this not working? Though I cant see any drops by that inspection on my ASA atleast while testing.
If there a change to either remove the "inspect skinny" OR change the listening port to something else from the port TCP/2000?
This setup should work and just to be sure I just tested this on my own ASA with no problems.
Have you monitored what happens to the connections when they are initiated to this public IP address? (Looking at ASA logs through the ASDM or Syslog server) Can you monitor the logs and see if the TCP connection perhaps gets teardown with SYN Timeout or perhaps TCP Reset
You can also test the availability of the port TCP/2000 from the ASA directly with the following command
ping tcp 192.168.1.20 2000
- Jouni
05-01-2013 03:28 PM
Hi Jouni
pings to the dms host on tcp port 2000 succeed from the ASA.
I've had a look at the monitoring and can see the following entries 30 seconds after a connection is tried.
Teardown TCP connection 7480653 for outside:217.37.109.246/56147 to dmz:192.168.1.20/2000 duration 0:00:30 bytes 0 TCP FINs
Theres some identical log entries but with "bytes 0 TCP Reset-O" at the end.
I changed the port to 3420 and now it works! I guess it was that "inspect-skinny".
Many thanks for your help
Paul
05-01-2013 03:31 PM
Hi,
The above log message seems to state that the TCP connection was formed but no data was transmitted. It also seems that the TCP connection was teardown normally (TCP FINs). If there is a TCP Reset for the same connection I am not sure what that is about.
Please mark the question as answered
- Jouni
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