cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6774
Views
100
Helpful
39
Replies

ASA 5510 inbound traffic question

MJones5150
Level 1
Level 1

I am working on a Cisco ASA 5510 for a customer. I need to allow inbound traffic on port 443 from a specific vendor IP address to a specific server on the customers internal network. I opened the ASDM 6.0 software, went to the firewall section and created the highlighted rule in the screenshot. Still, the vendor is telling me they can not connect to the customer server. I have defined both of those objects with the IP address necessary. Can someone help me find otu what I have done wrong please?

FirewallRule.JPG

-Mike

39 Replies 39

That looks better!  Also make sure you have an access list rule on the outside interface permitting traffic from the internet to the public IP of the server

access-list https_access extended permit tcp any host 108.162.209.37 eq https

access-group http_access in interface outside

but if doing this in the ASDM just right click in the outside interface area and add an ACL.  Source any destination 108.162.209.37 and destination port 443

--
Please remember to select a correct answer and rate helpful posts

I ran into a problem. I was informed by the ISP I need to use a different IP address, 75.150.96.33 (RDP-Outside is how that IP is defined in Network Objects). I created the rule in the first screen shot. When I click apply, I get the error in the second ascreen shot. Nw what have I done wrong?


Ah looks like the IP address 75.150.96.33 is assigned to the outside  interface. If this is the case you can not use the IP address but need to  select "Use interface IP address" radio button.

--
Please remember to select a correct answer and rate helpful posts

Thank you Marius. I got that cleared up in the first screen shot. The second one is my access rules. If i do a packet trace from the vendor IP to my internal IP, I get an error referring to the deny rule #4 on the outside rule. I can't seem to get this all lined up correctly.

You should be doing a packet tracer from an external IP to your outside interface IP which is translated to the server in question.

--
Please remember to select a correct answer and rate helpful posts

Also on your outside interface you have a rule permit ip any any, which should most definately not be there.  You are now allowing all traffic from the internet into your network.

--
Please remember to select a correct answer and rate helpful posts

I removed that rule.

I did a Packet Trace from the IP of my computer to the interface IP of this Cisco, it gave me an error. Again referring to the rule in the outgoing interface blocking all traffic.....

It is matching a VPN? that is odd.  what is the under the Un-NAT field in the packet tracer? and when you click on the show rule in access rules table it points  to the implicit deny on the inside interface?  What are the security  levels of your inside and outside interface?  if you add a permit IP any  any on the inside interface do you get access?  If you add a permit rule to the inside interface going outbound, do you get access?

--
Please remember to select a correct answer and rate helpful posts

Yes, this same IP is also for VPN users on port 3389.

Checking from the NAT table section of the ASDM.....

On interface "inside" *(outgoing rule), I checked the NAT from my interface IP (75.150.96.33) to the vendor IP (

143.112.129.121), it worked.

I then checked the interface "outside" (incoming rule) and went from my interface IP to the vendor. I got an error that referred to outside rule three. This is the UN-NAT message you asked about....


I am wondering that since you have defined outgoing rules on the inside interface you may have to define the permit here also...though I would think that shoud not be required.  but it is worth a try.  If you add an entry to the Inside (outgoing) rule from any to the private address of the server (192.168.2.220) and a destination port of 443.  any change in the flow?

--
Please remember to select a correct answer and rate helpful posts

Hi Mike,

Could you please post your running configuration? .. If you are not sure how to do that, let me know.

Regards,

AM

Hello AM,

I opened the command line from the ASDM, and typed show-running-config. The attached file is the result. Let me know please what I have done incorrectly.

I keep getting hung up having my traffic blocked by an implicit rule that I can not disable or edit. But maybe the access rules and NAT are not correct. The vendor requirement is simple, route 443 traffic from our IP address to your internal server. Sounds easy, but it is a struggle for me.

-Mike

The following ACL is configured incorrectly:

access-list outside extended permit tcp host 143.112.129.121 eq https host RDP-Outside eq https

It should read like this:

access-list outside extended permit tcp host 143.112.129.121 host RDP-Outside eq https

--
Please remember to select a correct answer and rate helpful posts

Hi,

First of all, i am very sorry for late reply as my computer has crashed with no prior notice.

You need some serious modifications in your configuration.

I will use the CLI commands because i do not have access to ASDM right now. To remove an existing command, just hover over it with your mouse and then right click to paste it in the main config prompt.

1) Because your requirement is to use address 108.162.209.37 as the outside translation for internal address 192.168.2.220. So, you need to remove this one:

static (inside,outside) tcp interface https 192.168.2.220 https netmask 255.255.255.255

And add this one: (Just copy it and paste it in the config mode prompt)

static (inside,outside) tcp 108.162.209.37 https 192.168.2.220 https netmask 255.255.255.255

2) Next, you need to add an outside ACL in the inbound direction to allow HTTPS access from the specified vendor's address to the NATTED ip address of the web server. So, you have to add this one in your outside ACL:

access-list Outside permit tcp host vendor-address host 108.162.209.37 eq https

3) Test it:

packet-trace input outside tcp vendor-address https 108.162.209.37 https

4) i want to ask, what does this access list entry accomplish?

access-list inside_access_out extended permit tcp host RDP-Outside host 143.112.129.121 eq https

You DO NOT need to define an outbound access list because ALL traffic from higher security interface (Inside) to a lower security interface (Outside) is allowed by default. If you want to add more control over outbound traffic, you need to add all the required services properly that are needed for inside users and hosts. Remember, there is an implicit deny at the end of each access list, which means traffic will be dropped if it is not matched by the permit statements.

For example, your access list tells the ASA to allow https traffic from host RDP-Outside to host 143.112.129.121 and nothing else. If this ACL is applied correctly on the inside interface in the right direction, nobody will get access to the internet.

Also, the ACL is applied in the wrong direction. You should use the keyword "in" not "out" because traffic from inside hosts is hitting (IN) the inside interface.

Anyways, this not our concern now. Just stick with the first three steps to solve the main issue "server publishing" then we focus on fixing your outbound traffic control.

Regards,

AM

I will attempt to try these suggestions, thank you.

The new problem I am facing is all of the remote users reported to me that their RDP sessions to 75.150.96.33 have stopped working. So I wonder if one of the new rules I created has stopped that from being functional. It worked before I started experimenting to figure out the HTTPS traffic. They are supposed to use RDP to 75.150.96.33, then it connects them to the 192.168.2.220 server so they can work remotely.

-Mike

Getting Started

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: