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?
I am able to ping the server from my computer, but 443 traffic is not working. Do I need two separate rules? One allowing traffic from the vendor IP to the internal IP, then one from the internal IP to the vendor IP, then a rule translating my internal IP to the public IP the vendor is looking for?
What version og ASA are you running?
If you are running a version prior to 8.3 then the access list needs to read like this
remote public IP to Local server public IP port 443
If the version is 8.3 or higher it needs to read like this:
remote public IP to Local server private IP port 443
Hope this post helps.
I ran the packet trace, and it showd me a rule that is dropping the traffic in to my server from the outside. When I go to the rules that makes it drop, I am unable to edit it. Can someone help me make that edit, or let me know why I can not edit this implicit rule to allow the traffic? Going to the vendor server is fine, they just can't come in to me.
So the implicit deny is being matched? This is a default which is placed at the end of all ACLs and can not be edited. You would need to create another ACL above it allowing the traffic you wish to pass through the ASA.
The interface ACL configuration is located under the Configuration tab and then select Firewall on the left, and I think it is the top option...Access-lists or something like that. don't quite remember and I don't have ASDM open right now to check.
Here is a screenshot of the Access Rules. In the Network Objects section, I have the McKesson-Gateway defined with their public IP address. I have the WebViewServer defined as the private IP on my internal network. Is that my problem perhaps?
your web server would need to be defined with its public IP (if this is coming from the internet and the ASA is doing the NATing)
Yes, If you want it to be accessed from the internet you should not be exempting it from NAT. There should be a static NAT translating the private IP to a public IP. Very often the public IP will be the interface IP, depending on how many public IPs you have and can allocate.
The Exempt NAT is mostly used when wanting to send traffic over a VPN or in some special circumstances where the inside IPs are public IPs.
I made an inside rule and an outside rule. 192.168.2.220 is my internal server. The vendor is looking for that server on public IP address 18.104.22.168 port 443.
When I run the Packet Trace on the "outside" rule from 22.214.171.124:443 to 192.168.2.220:443, it fails and drops the packet then refers me to that implicit deny rule that I have a screen shot of above. I created a new any/any and permit, ut it still drops.
You have added the nat to the outside interface which is incorrect. Add it to the inside interface with a source of 192.168.2.220 and a translated address of 126.96.36.199. Even though this is applied to the outside interface it does translate both directions.
Then when running the packet tracer run it from a source outside interface IP 188.8.131.52 port 4444 with a destination 184.108.40.206 port 443.
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 220.127.116.11 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 18.104.22.168 and destination port 443
I ran into a problem. I was informed by the ISP I need to use a different IP address, 22.214.171.124 (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 126.96.36.199 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.
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.
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.
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?
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 (188.8.131.52) to the vendor IP (
184.108.40.206), 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?
Could you please post your running configuration? .. If you are not sure how to do that, let me know.
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.
The following ACL is configured incorrectly:
access-list outside extended permit tcp host 220.127.116.11 eq https host RDP-Outside eq https
It should read like this:
access-list outside extended permit tcp host 18.104.22.168 host RDP-Outside eq https
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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 eq https
3) Test it:
packet-trace input outside tcp vendor-address https 184.108.40.206 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 220.127.116.11 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 18.104.22.168 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.
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 22.214.171.124 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 126.96.36.199, then it connects them to the 192.168.2.220 server so they can work remotely.