×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

ASA 5510 inbound traffic question

Unanswered Question
Aug 23rd, 2013
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (20 ratings)
Loading.
MJones5150 Fri, 08/23/2013 - 10:03
User Badges:

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?


-Mike

Marius Gunnerud Fri, 08/23/2013 - 10:11
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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.

MJones5150 Fri, 08/23/2013 - 10:20
User Badges:

Hello Marius,


When I do a help and then about, it says ASA: 8.0(3).


Where would I enter that info from the ASDM?


-Mike

MJones5150 Fri, 08/23/2013 - 10:18
User Badges:

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.


-Mike

Marius Gunnerud Fri, 08/23/2013 - 10:20
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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.

Marius Gunnerud Fri, 08/23/2013 - 10:23
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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.

MJones5150 Fri, 08/23/2013 - 10:24
User Badges:

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?


Marius Gunnerud Fri, 08/23/2013 - 10:26
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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)

MJones5150 Fri, 08/23/2013 - 10:30
User Badges:

I have this setup under NAT rules. Maybe this is wrong?


Marius Gunnerud Fri, 08/23/2013 - 10:33
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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.

MJones5150 Fri, 08/23/2013 - 10:45
User Badges:

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 108.162.209.37 port 443.


MJones5150 Fri, 08/23/2013 - 10:54
User Badges:

When I run the Packet Trace on the "outside" rule from 108.162.209.37: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.

Marius Gunnerud Fri, 08/23/2013 - 11:05
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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 108.162.209.37.  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 4.2.2.2 port 4444 with a destination 108.162.209.37 port 443.

MJones5150 Fri, 08/23/2013 - 11:58
User Badges:

I deleted the rule. Now I have this below. Is it correct?


Marius Gunnerud Fri, 08/23/2013 - 12:02
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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

MJones5150 Fri, 08/23/2013 - 12:29
User Badges:

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?



Marius Gunnerud Fri, 08/23/2013 - 12:37
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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.

MJones5150 Fri, 08/23/2013 - 12:52
User Badges:

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.


Marius Gunnerud Fri, 08/23/2013 - 12:56
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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

Marius Gunnerud Fri, 08/23/2013 - 12:58
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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.

MJones5150 Fri, 08/23/2013 - 13:11
User Badges:

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.....


Marius Gunnerud Fri, 08/23/2013 - 13:19
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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?

MJones5150 Fri, 08/23/2013 - 13:36
User Badges:

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....



Marius Gunnerud Fri, 08/23/2013 - 22:55
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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?

turbo_engine26 Sat, 08/24/2013 - 15:21
User Badges:

Hi Mike,


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



Regards,

AM

MJones5150 Sat, 08/24/2013 - 19:14
User Badges:

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

Marius Gunnerud Sat, 08/24/2013 - 23:21
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Firewalling

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

turbo_engine26 Sun, 08/25/2013 - 15:54
User Badges:

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

MJones5150 Mon, 08/26/2013 - 05:40
User Badges:

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

turbo_engine26 Mon, 08/26/2013 - 12:03
User Badges:

Hi,


I didn't notice your ISP's new requirement about using address 75.150.96.33 instead. Sorry about that. Keep the static nat as it is then.


You must remove the access list that is applied on the inside interface. It is stopping everything (RDP sessions and HTTPS to your server) because you're applying it using the "out" keyword and even the source/destination incorrect. The "out" keyword tells the ASA to perform a second check for inbound traffic (traffing coming from internet) after the first ACL check on the outside interface. RDP sessions should come back to life after you remove it. In fact, you do NOT need any access lists applied on the inside interface to solve your server publishing issue.


Let me know the status.



Regards,

AM

MJones5150 Tue, 08/27/2013 - 08:51
User Badges:

**update** The issue has been resolved. HTTPS and RDP traffic both flow to the desired destinations.


I opened ASDM, clicked on Tools. then Command Line Interface. I entered the following three commands into the command line interface:

access-list outside extended permit tcp host 143.112.129.121 host 75.150.96.33 eq 443

static (inside,outside) TCP interface 443 192.168.2.220 443 netmask 255.255.255.255

static (inside,outside) TCP interface 3389 192.168.2.220 3389 netmask 255.255.255.255


After I ran those commands, I got a popup from ASDM telling me the config had changed and asked me if I wanted to update. I said yes. Afterwards, I checked the NAT and Access Rules list from ASDM. The rules it added were the same ones I had created through the ASDM. Does anyone know why it only worked when I used the CLI and not ASDM?

turbo_engine26 Tue, 08/27/2013 - 09:14
User Badges:

Hi,


Nice to hear that they are working for you now. But i wonder, are they working while you are still applying the inside ACL? or Did you remove it?



Does anyone know why it only worked when I used the CLI and not ASDM?


Because you used to enter wrong configurations in ASDM, that is why they didn't work. The CLI configurations you posted are correct, that is why they are working. Simple as that !!


Also, interface directions in ASDM is sometimes confusing to certain people, especially to those who are using CLI a lot.



After I ran those commands, I got a popup from ASDM telling me the config had changed and asked me if I wanted to update. I said yes. Afterwards, I checked the NAT and Access Rules list from ASDM. The rules it added were the same ones I had created through the ASDM. 


This is normal. When you open an ASDM session and make configuration changes in CLI, the changes are replicated to ASDM to reflect the same configurations. No worries about that.


Regards,

AM

MJones5150 Tue, 08/27/2013 - 10:15
User Badges:

I did not remove anything. I only entered those three commands in succession.


I am not familiar with ASDM or CLI, so they are both confusing to me. But I agree with you, I was not using ASDM correctly even though it looked like I was.


Can you help me with a new issue? I need to enable RDP to a new server in the same network, but on a different port for testing, then eventually the 3389 traffic. Can I have two rules for 3389 but pointing to a different internal server? How would those rules look? I tried the command below in the CLI, but when I opened RDP it would not connect me from my home computer...

static (inside,outside) TCP interface 33899 192.168.2.230 33899 netmask 255.255.255.255


*Note...I am using port 33899 while testing in case I cannot route two rules on 3389.

turbo_engine26 Tue, 08/27/2013 - 12:46
User Badges:
Can I have two rules for 3389 but pointing to a different internal server? 

Yes, you can ONLY IF the different internal server is published using a different Public IP.


Having two servers listen to the same port and to be published using the same interface's address is impossible. Why? because traffic to those servers are not unique and ASA won't be able to differentiate between them. If you want to use the same interface's address for NAT, You MUST configure the new server itself (192.168.2.230) to use a different listening port for RDP permanently. What i mean by permanently is, you can't later use 3389 on it. So, whether it is for testing or not, you have to stick with that different port to that second server. However, the drawback of this approach is that you must instruct the remote users to use the new port in their RDP client when they connect to the new server.


I assume your server is running Windows server OS. 


To change the listening port for RDP on the server, follow this: http://www.wikihow.com/Change-the-Listening-Port-for-Remote-Desktop


To configure the RDP client to connect to the new port, follow this: http://support.microsoft.com/kb/304304



Another option, of course, is to use a different public ip address for the new server without changing the default RDP port.


Regards,

AM

MJones5150 Tue, 08/27/2013 - 13:27
User Badges:

It is the same IP. Perhaps for testing I could set up the new RDP on port 33899? Would that be easier?

turbo_engine26 Tue, 08/27/2013 - 17:53
User Badges:

Hi,


Your case here is not about what option would be easier. In fact, you do not have choices to choose from. You have only (and only) one option if you want two servers to share the same PAT interface and both provide the same service (RDP in this case). So as you and i mentioned, the only option you have is to make one of the servers listen to the default port as it is (3389) and the other server listen to custom port (33899). But again, this is not for testing, this is for real.


Remember: You must configure the new server to listen to the new port for RDP because it is still listening to the standard RDP port 3389. That is why you could not connect even if you created a static NAT for 33899. The firewall itself will NOT magically make your server listens to the new port by creating an access list or NAT statements The firewall is just passing traffic for an already configured services.


Steps to do:


1) Configure the server (ITSELF) to listen to a different RDP port (33899)


2) Configure Static PAT for it:


static (inside,outside) tcp interface 33899 192.168.2.230 33899 netmask 255.255.255.255


3) Configure access list entry:


access-list outside permit tcp host some-address host 75.150.96.33 eq 33899


Regards,

AM

turbo_engine26 Tue, 08/27/2013 - 18:22
User Badges:

If you do not want to change the default RDP port in the new server, you can use the below nat command instead:


static (inside,outside) tcp interface 33899 192.168.2.230 3389 netmask 255.255.255.255


But you still need the same access list that i posted.


access-list outside permit tcp host some-address host 75.150.96.33 eq 33899


I tested it and it is working.



Regards,

AM

MJones5150 Wed, 08/28/2013 - 06:42
User Badges:

I tried your ACL.....

access-list outside permit tcp host some-address host 75.150.96.33 eq 33899

and I got an error. I had to change it to....

access-list outside permit tcp any host 75.150.96.33 eq 33899


I confirmed, it is working. Now I am ready to undo these changes and make port 3389 go to the 2.230 server. If I remember correctly, I need to put a "no" in front of the commands I used to set up the testing of 33899 to remove those, and to remove the current port 3389 traffic to 2.220? Would it go like this....

no access-list outside permit tcp any host 75.150.96.33 eq 33899

no static (inside,outside) tcp interface 33899 192.168.2.230 3389 netmask 255.255.255.255

no static (inside,outside) tcp interface 3389 192.168.2.220 3389 netmask 255.255.255.255


Then put in.....

static (inside,outside) tcp interface 3389 192.168.2.230 3389 netmask 255.255.255.255

access-list outside permit tcp any host 75.150.96.33 eq 3389


Is that correct?

turbo_engine26 Wed, 08/28/2013 - 10:24
User Badges:

Yes, correct as along as you remove the 2.220 static nat. Now, the 2.230 only will listen for external RDP.


Regards,

AM

Actions

This Discussion