Link to home
Start Free TrialLog in
Avatar of tjwoollard
tjwoollardFlag for United Kingdom of Great Britain and Northern Ireland

asked on

pix v asa

i am in the process of changing a pix firewall to an asa5525. i have configured the asa with an inside interface an a outside interface. I have also configured the CX module. i configured an ip address on the inside interface and simply plugged it into the switch stack(cisco) expecting to do some testing. However as soon as I did that the users complained about no internet access which is via a MS TMG server as a proxyserver. And they were right the ASA stopped the the TMG from passsing any traffic and it seemed to be trying to route the TCP packets itself. I stopped this behaviour by turning off the cx module. There was also some other weird things happening eg no users could print via the MS printserver. I have had to dis-connect the ASA now but I am not able to explain this effect. I did make sure the IP address was unique on the network so it is not an address issue.
Avatar of btan
btan

probably is to do some troubleshooting too and looking at this guide (pdf)for CX. Note there is configuration step and can set Monitor mode such that policy in place does not drop traffic e.g.

(pg 3)
For testing purposes, you can configure the ASA to send a duplicate stream of
read-only traffic to the ASA CX module, so you can see how the module inspects the traffic without affecting the ASA traffic flow. In this mode, the ASA CX module inspects the traffic as usual, makes policy decisions, and generates events. However, because the packets are read-only copies, the module actions do not affect the actual traffic.


To enable ASA CX debugging, enter the following command:
debug cxsc [error | event | message] - Enables debugs at error, event, or message level.

(pg 31-32) Problems with the Authentication Proxy

If you are having a problem using the authentication proxy feature, follow these steps to troubleshoot your configuration and connections:
1. Check your configurations.
• On the ASA, check the output of the show asp table classify domain cxsc-auth-proxy command and make sure there are rules installed and that they are correct.
• In PRSM, ensure the directory realm is created with the correct credentials and test the connection to make sure you can reach the authentication server; also ensure that a policy object or objects are configured for authentication.
2. Check the output of the show service-policy cxsc command to see if any packets were proxied.
3. Perform a packet capture on the backplane, and check to see if traffic is being redirected on the correct configured port. See the “Capturing Module Traffic” section on page 28-30. You can check the configured port using the show running-config cxsc command or the show asp table classify domain cxsc-auth-proxy command.

If you have a connection between hosts on two ASA interfaces, and the ASA CX service policy is only configured for one of the interfaces, then all traffic between these hosts is sent to the ASA CX module, including traffic originating on the non-ASA CX interface (the feature is bidirectional). However, the ASA only performs the authentication proxy on the interface to which the service policy is applied, because this feature is ingress-only.

In this case, you may want to check the port used by TMG to ASA CX as compared to past TMG to PIX

Example 28-1 Make sure port 2000 is used consistently:

1. Check the authentication proxy port:
ciscoasa# show running-config cxsc
cxsc auth-proxy port 2000

2. Check the authentication proxy rules:
ciscoasa# show asp table classify domain cxsc-auth-proxy
Input Table
in id=0x7ffed86cc470, priority=121, domain=cxsc-auth-proxy, deny=false
hits=0, user_data=0x7ffed86ca220, cs_id=0x0, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=192.168.0.100, mask=255.255.255.255, port=2000, dscp=0x0
input_ifc=inside, output_ifc=identity

3. In the packet captures, the redirect request should be going to destination port 2000.
Avatar of tjwoollard

ASKER

Hi there,

Sorry for not comming back on this but it seems the problem is a lot worse that I thought.
I have 2 ASA devices configured in fail-over active/passive mode. It is to replace a 2 PIX firewall device running in active/passive mode. I have recently plugged the ASA device into the Cisco switch stack. Th PIX is still plugged in but the ASA is on a different IP address.
There is a MS TMG server which comprises of 2 servers running in NLB mode. Also we have 2 MS Exchange CAS servers running in NLB mode. About 20 minutes after plugging in the ASA device these server stop responding. The respond to a PING but not at the application level. I did not make the ASA the default router for any device on the network but they seem to be doing something weird to the servers but there are no reported errors on any device. Any ideas ?
That is really strange.

a-So if the ASA FW are not powered on yet and plugged in, will the effect still occurred?
b-If the powered ASA FW is unplugged, will the servers go revert back to work properly as intended?  

pretty tough to isolate but if static route is configured such that IP segment or VLAN for ASA FW is denied to access any routes to the existing servers and PIX, I dont see how it can create that effect. there may be some static routing that ASA FW is able to traffic out? or assume PIX FW ip due to ARP causing MAC confusion...
well it is the weirdest thing i have ever seen. if you unplug the ASA the problem disappears. If the interface is shutdown the problem does not occur. I have removed the static routes i had installed a and re-booted several times. Is it that the PIX is plugged into the same network ?. When I observe the ASA through ASDM it appears to be passing or at least monitoring traffic even though no devices a configured to use it. It is as if there is CDP configured and it is discovering the network. I am aware that CDP is not installed on ASA devices.
ASA should not be placed inline at all for a start and I supposed you shouldnt have PIX and ASA all at one switch. unplugging PIX may confused routes since PIX is likely the default gateway to each segments, the bouncer is controlling the traffic and PIX is the suspect. Maybe unplug PIX and see if the server behaviour for a while, plug in ASA FW to observe server, unplug ASA and observe server and plug in PIX FW. No change to any routes
ASKER CERTIFIED SOLUTION
Avatar of tjwoollard
tjwoollard
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
thanks for sharing but just want to check if the suggestion from posting has assisted in any way?
There is nothing wrong with the config or the device it is just that a PIX firewall can not be on the same network an an ASA device.
thanks and well received. As per last isolation testing stated to isolate them to verify if it work, have thought that helped though.