cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
552
Views
0
Helpful
3
Replies

ASA 5525-X ASDM question with NAT/PAT

dgoodson1
Level 1
Level 1

Hi All,

We have an ASA 5525-X (v9.1(7) with ASDM 7.1(3)) and what I'm trying to achieve is relatively simple (at least it should be) but struggling and trying to work out whether the ASA is missing some config or something else in our security stack is causing problems by process or elimination.

I have a 3rd party cloud solution (on 123.123.123.123) which needs to send logs inbound through our ASA to a log collector on our LAN.  The log collector is NAT'd on our ASA and the port on the outside interface (tcp 7000) translates to a different port internally (tcp 514).  I've set the NAT and an ACL up as follows with ASDM:

(Note all addresses are examples!)

  1. Created network object - inside address of 192.168.1.100, selected NAT "automatic address translation rules" and used a static of 193.186.1.100, clicked the "Advanced" tab and ensured the Source Interface is the "inside", and Destination is the "outside".  For the service I've set protocol to "tcp", Real port to "514" and Mapped port to "7000"
  2. I've then created an ACL on the outside interface with the following:
        • Source: 123.123.123.123
        • Destination: NAT'd object 192.168.1.100 / 193.186.1.100
        • Service: tcp/7000 and tcp/514

The hit counter is going up on the rule when I use the test connection from the cloud provider, however 3 way H-S doesn't seem to fully complete.  Logs on the inside log collector are showing the SYN & SYN-ACK work, but the ACK seems to have SEW flags.

Any help would be greatly appreciated.

Cheers

3 Replies 3

Marvin Rhoads
Hall of Fame
Hall of Fame

The syslog service is usually udp/514 - not tcp. Has that default been changed on your servers?

Hi Marvin,

Aware of that thanks.  The vendor of the internal server has asked that we send logs to the device over tcp/514 and not the traditional udp/514 as they are accepting over both.

Cheers,

Dan

OK. Given that, how you've described your ACL and NAT sound OK.

For further troubleshooting I'd double check the implementation logic using packet-tracer.

If all looks good there I'd then proceed to do a capture of the interesting traffic and have a look at the decode in Wireshark.

Note - see the following for a good explanation of the states we normally expect to see regarding connection flags:

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113602-ptn-113602.html

Review Cisco Networking for a $25 gift card