Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 585
  • Last Modified:

Cisco ASA550 Port Forwarding not working

I have configured a new Cisco 5510 security appliance.  I am able to browse the internet, but none of my internal services are accessible from the outside. Using the CLI I setup the static NAT (inside,outside) entries with the service ports, and used the access-list outside_access_in command to configure the access rules.  I have attached the complete running-config.  
config.TXT
0
s_pulsifer
Asked:
s_pulsifer
  • 12
  • 10
1 Solution
 
debuggerauCommented:
you seem to be missing the access list for the incoming requests, try this for example for the smtp server..
access-list inside_access_in extended permit ip host 64.173.193.242 any
0
 
raptorjb007Commented:
You need to apply the "ouside_access_in" ACL to the outside interface. Use the following command.

access-group outside_access_in in interface outside
0
 
s_pulsiferAuthor Commented:
Thx. Will try both this evening after hours and update as to the results.
0
Prepare for an Exciting Career in Cybersecurity

Help prevent cyber-threats and provide solutions to safeguard our global digital economy. Earn your MS in Cybersecurity. WGU’s MSCSIA degree program curriculum features two internationally recognized certifications from the EC-Council at no additional time or cost.

 
s_pulsiferAuthor Commented:
With the access-group outside_access_in in interface outised, I am able to RDP into .243 and .244 but none of the other port forwards are working.  Http, Https, telnet, ssh, smtp.  Any ideas?  
0
 
raptorjb007Commented:
Well, the configuration is correct to open and forward those ports, just like 3389 the other ones should work. Are the internal hosts listening on the forwarded ports? Can you telnet to the opened ports (telnet x.x.x.x port_num) from the internet?

As long as an access-list allowed the traffic in and a static command maps it to an internal host the traffic should be forwarded. You can check that the mapping's are active using the "show xlate" command, and you can check to see if the access-lists see any activity using the "show access-list" command, you should see hits on the various access-lists.

Also, typically when using the IP of the global (outside) interface in a static command you would use the word interface instead of the IP. This is just semantics though, should work in its current form.

static (inside,outside) tcp interface www 10.1.1.47 www netmask 255.255.255.255
instead of
static (inside,outside) tcp 64.173.193.242 www 10.1.1.47 www netmask 255.255.255.255
0
 
s_pulsiferAuthor Commented:
I am unable to telnet to any of the open ports from the outside.  With the original firewall in place, I can telnet to the ports, so I know that they are listening on the inside.  As a test, I changed one of the static NAT statements and the corresponding access-list for port 3389 on .242 to port 3389 on .245.  Once this change was made, I was able to access it from the outside.  The show xlate shows the correct translations.  It seems the problem exists with the NAT and access statements which use the .242 address with different port numbers.
0
 
raptorjb007Commented:
Have you change your static mapping that use the ip of your outside interface as listed in my previous post?
0
 
s_pulsiferAuthor Commented:
I did try that with the same results - was unable to access through the firewall.
0
 
raptorjb007Commented:
So specifically, only Port mappings using the external IP of .242 are not working, correct?

Ensure all of the static statement referencing .242 are changed to:
static (inside,outside) tcp interface port x.x.x.x port netmask 255.255.255.255

Then run the "clear xlate" command.

When complete, post your new config and a copy of the output received from the "show xlate" command. We will see what we can discover from that information.
0
 
s_pulsiferAuthor Commented:
Will do - all of the changes have been made and will be testing tonight after hours.
0
 
s_pulsiferAuthor Commented:
Changes worked with the exception of one port/service.  I have an sftp server in the dmz, but the port forward for ssh is not working.  The show xlate looks correct, but I am not sure of the acl.  I tried adding a second access-group but it over-wrote the first access group which I need for the other port forwards.  Attached is the info you requested.
Cisco.TXT
0
 
raptorjb007Commented:
The new config file is a bit scambled. However based on your old one the only thing I can see is your nat index for the global and nat statements do not match for the DMZ interface, thus NAT is not properly applied to the DMZ subnet.

Change:
global (dmz) 50 interface
nat (inside) 10 0.0.0.0 0.0.0.0

To:
global (dmz) 10 interface
nat (inside) 10 0.0.0.0 0.0.0.0
0
 
s_pulsiferAuthor Commented:
no go on the above - I am still unable to access the dmz.  I changed the security level to match the outside interface in an attempt to get it working, but that did not help either.  A cleaner config with xlate is attached.
Cisco.txt
0
 
raptorjb007Commented:
I would suggest that all your interfaces have different security levels. Specifically, interfaces with the same security level cannot communicate with each other. Perhaps set dmz to 50.

=====================

Also, I think I made a typo in my previous comment regarding the nat statements.
Change:
global (outside) 10 interface
global (dmz) 10 interface
nat (inside) 0 access-list RENO
nat (inside) 10 0.0.0.0 0.0.0.0

to:
global (outside) 10 interface
no global (dmz) 10 interface
nat (inside) 0 access-list RENO
nat (inside) 10 0.0.0.0 0.0.0.0
nat (dmz) 10 0.0.0.0 0.0.0.0

This will apply Nat to the dmz interface using the global address set with the outside interface.

=======================

You should also add a line to you "outside_access_in" ACL to allow ssh traffic in if the destingation is 64.173.193.243. You may also want to get rid of the dmz ACL as it may interfere with traffic.

access-list outside_access_in extended permit tcp any host 64.173.193.243 eq ssh
no access-list outside_access_dmz extended permit tcp any host 64.173.193.243 eq ssh
no access-group outside_access_dmz in interface dmz

=======================

Let me know if that works.
0
 
s_pulsiferAuthor Commented:
Will try the above and let you know.
0
 
raptorjb007Commented:
Any luck?
0
 
s_pulsiferAuthor Commented:
Sorry - out of the office.  Will try it tonight and let you know.
0
 
s_pulsiferAuthor Commented:
Made the above changes and still no luck accessing the DMZ from outside.  Any other suggestions?
0
 
raptorjb007Commented:
be sure to type "clear xlate" to clear the translation table.
0
 
raptorjb007Commented:
I was able to establish a ssh session with 64.173.193.243.
0
 
s_pulsiferAuthor Commented:
You would have been able to connect via SSH because I rolled back to the original firewall.  I need to get all services up and running on the Cisco before retiring the old firewall, which is why I can only test after hours.
0
 
raptorjb007Commented:
Can you report you most recent config, the result of the "show xlate" command, and the result of the "show route" commands.

Also can you use the packet tracer command and post the results. Replace x.x.x.x with a valid external IP address, any internet address should work, preferably the IP you are using to test access to ssh with. This will show me where the traffic is being dropped.

 packet-tracer input outside tcp x.x.x.x ssh 64.173.193.243 ssh
0
 
s_pulsiferAuthor Commented:
That did the trick - Windows firewall was causing the extra problem.  Thx for your help.
0

Featured Post

New Tabletop Appliances Blow Competitors Away!

WatchGuard’s new T15, T35 and T55 tabletop UTMs provide the highest-performing security inspection in their class, allowing users at small offices, home offices and distributed enterprises to experience blazing-fast Internet speeds without sacrificing enterprise-grade security.

  • 12
  • 10
Tackle projects and never again get stuck behind a technical roadblock.
Join Now