I am faced with a challenge with a setup which was previously running in a flat network without a firewall. They had a proxy server running which did NATTING for them on the WAN interface whereas the LAN segment was plugged into the LAN interface. The Windows server machine running a proxy server (Kerio Win route Firewall) for that matter acted as a proxy for all internet requests, firewall service and performed NAT translations towards the internet.
The new setup includes installing a new Cisco 5512 X series firewall in their setup. Now I have a number of zones that require intercommunication. New setup with zones:
DMZ = Servers
Inside = Inside corporate users
Outside = Internet users
The systems administrators wants all queries to be forwarded from the Inside segment to the DMZ segment where the proxy server and local DNS are hosted. The setup that we have recommended requires all web requests to first go to the proxy server in the DMZ segment and then being forwarded to the internet from there. This means I have created a NAT translation coming from the proxy server in the 'DMZ' zone and not the users inside the 'INSIDE' zone. The client would ideally enter proxy details in their web browser, skype, MSN Messenger etc. with the gateway being the IP address of the zone on the ASA which would forward all internet requests to the proxy server in the DMZ zone. The proxy server would then forward all internet related queries on behalf of the inside users to the internet (Outside Zone). Now I just need to confirm whether there is a way where I could stop the client having to enter the proxy details manually in their client PCs and whether I could create entries on the firewall which would automatically forward all queries to the proxy server. The proxy server can then judge what to do with that traffic and then send it to the firewall which would forward it to the internet via a default route using a NAT entry.
Transparent redirectionf from inside to DMZ would work with WCCP on any router, but ASA has restriction in this scenario:
WCCP redirection is supported only on the ingress of an interface. The only topology that the ASA supports is when client and cache engine are behind the same interface of the ASA and the cache engine can directly communicate with the client, without going through the ASA.
Thanks for your reply in this regard. The WCCP Server protocol requires a service running the WCCP client protocol at the proxy/client end. The router/ASA running WCCP would forward requests that match the WCCP ACL to the Cisco Cache Engine running application. Now, as mentioned in the following link: http://en.wikipedia.org/wiki/Web_Cache_Communication_Protocol only a handful of client proxy applications actually integrate with WCCP and not all of them do that. However, with the ASA's, can we have run a transparent proxy with our ASA using two subinterfaces ie. the inside zone and the DMZ would be positioned on two separate subinterfaces (two different zones) albeit on the same 'physical' interface since the requirement is to have them on two different interfaces. I'm just thinking of a workaround to this limitation. The document also does mention that if the traffic goes through the ASA this won't be possible but I am just hoping this would work. Just so yo know I am using ASA 5512x which runs the latest code of 8.6. In anycase, I do not think using transparent redirection would quite work for me considering the proxy I am using is 'Kerio Win route Firewall' and it does not support Cisco's WCCP. Please do let me know if I am understanding how these technologies would integrate.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...