cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

5558
Views
100
Helpful
39
Replies
MJones5150
Beginner

ASA 5510 inbound traffic question

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

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

**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?

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

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.

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

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

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

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

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?

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

Regards,

AM

Content for Community-Ad