Upgraded from Borderware to Cisco, Having Minor Issues

[darrenpenney]

Hello,

I have recent upgraded our firewall from a Borderware Steelgate v7.1 platform to a Cisco ASA 5520 platform.  Needless to say, the interface on the Cisco platform is much more complex, and I don't have much experience with Firewalls (so please take it easy on me).

For the most part, I have everything working regarding access rules, I just have two issues, one is minor and one major.

Issue #1 (minor): When the Cisco firewall is in place, I cannot ping google.ca.  I am connected to the Internet and I can access google, I just can't ping it.  Like I said, it is not a serious issue, but I use a continuous ping to google.ca to ensure that the network is up and running since we use a sat. link to connect to our internet source.

Issue #2 (major):  We use GroupWise and our mail client and the web access portion of GroupWise cannot be accessed from outside of our network.  I have setup the access rule the same as it was setup in Borderware, but it is just not working.  Is there another setting that needs to be enabled/disabled aside from the access rule in order for this to work?

Thanks in advance for any assistance.

[Allen P Chen]

You mentioned this in a previous post:

Issue #2: From outside, if you ping our webmail address, it returns with  the external interface IP address of the ASA.  From inside, the ping  will time out, but that is really not new.  Webmail never worked from  inside since there was no real need for it to work inside the company.

And now you mentioned this:

One question, when I ping the webmail web address, I get an ip address  XXX.XXX.XXX.XX2, but our External router is set to XXX.XXX.XXX.XX1

So the IP address of the Webmail address from the outside is not exactly the same as the external interface on the ASA, correct?  If so, this is definitely causing the issue.  If this is the case, you will need to change to your NAT and ACL statements.

Within the NAT rule in ASDM, instead of select "Use Interface IP Address", you will need to select "Use IP address" and type in XXX.XXX.XXX.XX2.

On the ACL, the destination will need to be changed to XXX.XXX.XXX.XX2 as well.

Therefore, under Tools>Command line interface on ASDM, if you type in "show run static" and send, you should see the following as one of the outputs:

static (internal,external) tcp XXX.XXX.XXX.XX2 82 443 netmask 255.255.255.255

And in the output of "show run access-list", you should see a line similar to:

access-list OUTSIDE_IN permit tcp any host XXX.XXX.XXX.XX2 eq 82

[darrenpenney]

I'm sorry, I gave you some wrong information there.  I checked the device setup and the External port IP is set to XXX.XXX.XXX.XX2.  This is verified because when I try to set my NAT rule to use IP address XXX.XXX.XXX.XX2, it replies back with an error stating that that is the External IP.

The part that I am getting hung up on is that in the Network Objects there is an external router created that uses XXX.XXX.XXX.XX1 (Netmask 255.255.255.255) and the overall external network uses XXX.XXX.XXX.XX0 (Netmask 255.255.255.248).  So in the access rule, I am trying to figure out how to get the destination to point to XXX.XXX.XXX.XX2, or even if that is the problem.

Also, I was not the one who originally setup this firewall, which is why I am trying to figure out all of the settings.

By the way, thanks for your patience and help with all of this.

[Allen P Chen · Accepted solution]

No worries, glad I can help, hopefully we can get things going for you.

What security levels are assigned to your internal and external interfaces?  0 for external and 100 for internal?

Just to confirm, the Webmail address is the same as the IP address assigned to the external interface of the ASA.  If that's the case, then the NAT and ACL statements will need to revert back.

- a NAT static rule with the original Interface set to  Internal, the source is webmail's server real IP address (internal IP).  The  translated interface is set to external and it is set to use Interface  IP Address.  PAT is enabled, the protocol is set to TCP.  The original  port should be set to 443 and the translated port is set to 82.

-access rule for the external interface with the source set to any, the destination set to the external interface, service set to tcp/82

With the settings above, what do you see in the logs when an attempt is made from the outside to https://:82?

[darrenpenney]

Sorry I haven't posted recently, but I have been in training this week and out of the office for next week.  But my co-worker will be working on this issue and he can  post the results you were looking for in this thread in order to get this running.  Thanks again.

[chrisjmolloy]

Hi Allen,

I am Darren's coworker who is going to work on this issue with you for now.  I have made the changes you suggested, and have enabled logging for that particular rule, as it was disabled for the external access rule.  where will I be able to view the logging info?  Will test now.

[Allen P Chen]

It would be best to enabled buffered logging at debugging level to troubleshoot:

logging enable

logging buffered 7

Since external users are attempting to accsss webmail on port 82, you can look through the logs with the output:

show log | inc 82

This will display all log messages that contain the keyword "82".

[chrisjmolloy]

Hi Allen,

Sorry for the delay, I am going to test this now and try to send the log messages to you.

[chrisjmolloy]

Hi Allen,

With the changes you suggested with the NAT rule webmail/webaccess is working via external connection.  This is great news, I am not sure where to go to view the logs, or to pass that information on to you.  Can you assist?

[Allen P Chen]

That is great news, so webmail from external is now working as desired, correct?  If so, I no longer need to see the logs.

To answer your question with regards to logging, if the following commands are entered on the ASA:

logging enable

logging buffered 7

The logs can then be seen in the buffer of the ASA.  The buffer logs can be seen on the console session of the ASA.  If you add the following:

logging asdm 7

You should be able to see the same logs within the ASDM interface.