Transparent HTTP Proxy

Discuss and get help configuring CacheGuard to protect Web end-users
eb_ottawa
Posts: 10
Joined: 21 Jul 2017 13:53

Transparent HTTP Proxy

Post by eb_ottawa » 21 Jul 2017 14:02

Here's a quick setup of our workstations VLAN and how it reaches the internet.

<(Workstation VLAN)> --- (Cisco ASA FW) --- (pfSense Router) -*-*- PTP Fibre to DC -*-*- (Cisco ASA Routing/FW) --- Internet
192.168.0.0/22 --- 192.168.0.1/192.168.255.2 --- 192.168.255.1/192.168.254.1 -*-*- 192.168.254.2/192.168.253.2 -*-*- 192.168.253.1/Public IP

IP Addresses are fictitious but that's pretty much the lay of the land.

I have CacheGuard setup at our DC in a VM, if I set my browser proxy settings to port 8080 I have no issues and it works. What I'm trying to accomplish is put a port forwarding rule on my pfSense router so that all 192.168.0.0/22 traffic routes to the Transport HTTP proxy but that doesn't seem to be working.

What would be the best way to accomplish this? I ask so that I can also route some wireless AP VLANs for guests/etc through the same THTTP/S

eb_ottawa
Posts: 10
Joined: 21 Jul 2017 13:53

Re: Transparent HTTP Proxy

Post by eb_ottawa » 21 Jul 2017 18:38

Forgot to mention, I'd obviously need to forward http/s traffic, not just tcp. I don't need to do SSL remediation, we just want to use cacheguard and blocklists for url guarding.

User avatar
david
Posts: 157
Joined: 08 Aug 2015 20:38

Re: Transparent HTTP Proxy

Post by david » 21 Jul 2017 18:56

Hi

Thank you for your post. Can you please give me the internal and external IP addresses (or equivalent fictitious IP addresses) of your CG so I can figure out where your CG is implemented in the chain?

Also you can find useful information in the documentation at: http://www.cacheguard.net/doc/guide/transparent.html.

Best Regards,
David Jan
CacheGuard Technical Team
https://www.cacheguard.com

eb_ottawa
Posts: 10
Joined: 21 Jul 2017 13:53

Re: Transparent HTTP Proxy

Post by eb_ottawa » 21 Jul 2017 19:00

CG is at the DataCenter end, let's say IP is 192.168.253.21 and 192.168.254.21.

User avatar
david
Posts: 157
Joined: 08 Aug 2015 20:38

Re: Transparent HTTP Proxy

Post by david » 21 Jul 2017 19:15

Hi,

If I understand this correctly the internal IP of your CG should be 192.168.254.21 and its external IP 192.168.253.21. Also my understanding is that your CG is implemented in parallel with your (Cisco ASA Routing / FW) at the DC end. Therefore CG as an explicit proxy is reached at 192.168.254.21:8080 from machines located on your Workstation VLAN (192.168.0.0/2). Can you confirm my understanding please?

Let's say YES to my question above. By simplifying, your network architecture should be similar to the diagram below.

To accomplish what you need you can't use a [Firewall /NAT / PortForward] rule on a pfSense. Actually if the pfSense is configured to froward the HTTP port to the internal interface of CG (192.168.254.21 in your case), you tell to CG that you want to address CG itself on its HTTP port. In this case you will get the content of http://192.168.254.21:80 (which contains some information about your CG) and not the content of the initial destination address (which could be http://www.cacheguard.net for instance). But you don't want that. Right? What you really need is to:

- Route all HTTP traffic via the internal interface of your CG (192.168.254.21) letting unchanged the destination address of HTTP traffic AND
- Let other traffic being routed via your Cisco ASA Routing/FW at the DC end.

To do so you will need to configure a policy routing rule on your pfSense that route HTTP traffic via your CG. I'm not a pfSense expert but after having taken a quick look at the WebGUI of my pfSense I think that you should do the following:

- Create a new gateway for your CG (System / Routing / Gateways).
- Define a firewall rule that uses CG as a gateway for HTTP traffic (Firewall / Rules / LAN, Advanced Options).

Please let me know if by doing so this works.

Kind Regards,
Attachments
PolicyRouting.jpeg
PolicyRouting.jpeg (24.96 KiB) Viewed 5669 times
David Jan
CacheGuard Technical Team
https://www.cacheguard.com

User avatar
david
Posts: 157
Joined: 08 Aug 2015 20:38

Re: Transparent HTTP Proxy

Post by david » 23 Jul 2017 14:40

Hi,

We just finished to test the proposed architecture in our lab using a pfSense 2.3.4-RELEASE. We have found that pfSense policy routing does not work if both gateways (CG and ASA) are in the same VLAN. This is either a pfSense bug or a feature. Therefore we created a dedicated connectivity VLAN (in orange) between our CG and pfSense and it finally worked. Below the modified architecture diagram.

We therefore recommend to do the following:

- Use policy routing (and not port forwarding)
- Create a distinct VLAN between your pfSense and CG (here in orange)

I hope that you can create multiple VLANS/Subnets on your PTP Fibre to DC Inter LAN Switchs. Please let us know if our solutions works in your environment.

Best Regards,
Attachments
PolicyRouting-2.jpeg
PolicyRouting-2.jpeg (24.42 KiB) Viewed 5668 times
David Jan
CacheGuard Technical Team
https://www.cacheguard.com

eb_ottawa
Posts: 10
Joined: 21 Jul 2017 13:53

Re: Transparent HTTP Proxy

Post by eb_ottawa » 25 Jul 2017 14:46

Thanks for the info. So far I have made the CG be independent of ASA at the DC as mentioned and put through a VLAN on the PTP. I'm able to ping and get to wadmin portal of the CG.

On the pfSense I've created the routing policy for all HTTP/S traffic to use the the CG as the gateway, but it is just timing out when I run tests from my workstation.

So... to recap

Workstation IP is .13 -> pfSense CG Vlan .254 -> CG .250 -> ASA -> Internet

Do I need to specify ports somewhere or change thttp to port 80?

User avatar
david
Posts: 157
Joined: 08 Aug 2015 20:38

Re: Transparent HTTP Proxy

Post by david » 25 Jul 2017 15:44

Hi,

The port to route via CG should be the HTTP port (80) and not thttp (8081) which is for internal usage by CG only. Please don't modify this port unless you know what you do. Also you can't transparently route https traffic (port 443) via CG unless you activate the ssl mediation (on CG). SSL is protected against man in the middle attacks so it's simply not possible to be transparently intercepted.

I suggest that you validate your policy-based routing for HTTP (port 80) first. And then you can configure the SSL mediation (if needed).

You have the possibility to activate the auditing mode on CG and have a look at access logs in real time (to see if Web traffic are effectively routed via CG). To do so, please use the following commands (from the CLI):

Code: Select all

mode log on
log type web on
admin waudit on
apply force
The auditing Web GUI will then be available at https://<cg-internal-ip>:8091

Best Regards,
David Jan
CacheGuard Technical Team
https://www.cacheguard.com

User avatar
charles
Site Admin
Posts: 41
Joined: 06 Nov 2014 16:23
Location: Paris
Contact:

Re: Transparent HTTP Proxy

Post by charles » 25 Jul 2017 16:38

Hi

If you have changed your network topology, please double check your firewall rules and existing routes to ensure that you don't have asymmetric routes in your networks. CG as well as any other stateful firewall does not support asymmetric routing.

Best Regards,
Charles Tajvidi
IT Technical Architect
http://www.cacheguard.com

eb_ottawa
Posts: 10
Joined: 21 Jul 2017 13:53

Re: Transparent HTTP Proxy

Post by eb_ottawa » 25 Jul 2017 17:33

Hi Charles,

No, I've ensured routing is good and can easily setup proxy to the CG's tcp/8080 from Firefox, but alas my pfSense rule just isn't hitting the CG.

pfSense Rule (on workstation interface)
Protocol: TCP/UDP
Source: Workstation IP (.13)
Port: *
Destination: group_Internet4 (an alias with all public IPs)
Port: 80
Gateway: CGINT_Proxy (my CG's Internal Interface)

So with it turned on, nothing showing up in the logs and I can hit the CG's IP straight up and it tells me about it, I can hit the admin, etc... Within Firefox I've also setup proxy configs for tcp/8080 of CG's IP with no issue either.

pfSense routing allows me to navigate to the internal IP without fail, so I think routing is fine. I think the problem therein lies with the pfSense config. Maybe I shouldn't be using it as the GW IP for that rule?

Post Reply