08-23-2013 05:48 AM - edited 03-11-2019 07:30 PM
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?
-Mike
08-23-2013 12:02 PM
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
08-23-2013 12:29 PM
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?
08-23-2013 12:37 PM
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.
08-23-2013 12:52 PM
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.
08-23-2013 12:56 PM
You should be doing a packet tracer from an external IP to your outside interface IP which is translated to the server in question.
08-23-2013 12:58 PM
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.
08-23-2013 01:11 PM
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.....
08-23-2013 01:19 PM
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?
08-23-2013 01:36 PM
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....
08-23-2013 10:55 PM
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?
08-24-2013 03:21 PM
Hi Mike,
Could you please post your running configuration? .. If you are not sure how to do that, let me know.
Regards,
AM
08-24-2013 07:14 PM
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
08-24-2013 11:21 PM
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
08-25-2013 03:54 PM
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
08-26-2013 05:40 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
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