http forward to proxy

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

http forward to proxy

Not applicable

Hi,

I try to forward my WiFi mobile users http communications to my proxy.

WiFi mobile users and proxy are in two different VLAN plug on Palo Alto (default gateway of mobile users and proxy is Palo Alto Firewall).

Is it possible with Palo Alto?

The problem is that I need to forward all HTTP (80) from mobile users to the proxy on a different port (8080) and you could not define a specific forward port on the next hop on the Policy Based forwarding menu.

I tried with nat but my squid proxy deny the request.

I've made lots of test in lab with the Policy Based Forwarding and NAT features but it's not working.

Can you please help me ?

Thanks

Matthieu

13 REPLIES 13

L5 Sessionator

Hi Matthieu,

Why do you want to forward from port 80 to port 8080. With policy based forwarding you can specify the next hop ip address. can you not select the source user ip subnet or WIFI subnet only and foraward it the proxy server's ip address which is basically your next hop ip address. Also make sure to select the http from the services tab so only port 80 traffic gets . Please let me know if that helps.

Thank you

mbutt

Not applicable

Hi mbutt and thanks for your quick answer.

That exacly the configuration I made.

I want to forward to the 8080 tcp port because my proxy is listening to the 8080 tcp port and is not working in transparent mode, that why I would like to know if I can forward the http mobile phone connexions to the proxy thanks to Palo Alto Firewall (mobile phones does not have proxy configured and I could not change the configuration).

The goal of this configuration is to apply the company internet policy (proxy filtering settings) to the unmanage mobile phones.

In checkpoint FW, the feature is called http_mapped service.

Thanks again for your help

Matthieu

Not applicable

oups, made a mistake in my previous message, the proxy is configured in transparent mode.

Not applicable

i just try to configured a simple forwarding policy rule (source IP: wifi_mobile ; dest. service http ; forward to proxy IP) and set the listen port of my proxy to tcp/80 (transparent mode) but this configurtion is not working.

Is there a way to correctly foward http connexion to a web proxy?

Not applicable

sorry again but I find the begining of the solution:

1/ my proxy is listening to the 8080 port in transparent mode

2/ the PA have a forward proxy rule from zone wifi_mobile to http service port => forward to proxy IP

3/ NAT configuration : from zone Wifi_mobile to zone "proxy" ; destination adresse 173.194.35.144 ; service http; nat source "none" ; nat dest. IP: proxy_IP ; nat port dest. 8080

This configuration is working when the mobile phone access to http://173.194.35.144

Hope you see the problem: I could not NAT all internet IP address to my unique proxy IP address.

A solution?

Thanks again Smiley Happy

The main difference between a transparent http-proxy and non-transparent http-proxy is how the request which the client sends looks like:

transparent:

GET /path/file.txt HTTP/1.0

Host: www.example.com

non-transparent (aka forward-proxy):

CONNECT http://www.example.com/path/file.txt HTTP/1.0

Also, when using a transparent proxy it will use the dstport on the inside as dstport on the outside. Which means that if you use a PA to DNAT the traffic from TCP80 into TCP8080 it will arrive to your proxy at TCP8080, the proxy (if runned in transparent mode) will then reuse the values of dstip and dstport on the packet it constructs on its outside before being sent to Internet (or whatever you might have there).

Which gives that if you cannot force your clients to use a proxysetting (so they send CONNECT http://www.example.com/ HTTP/1.0 instead of GET / HTTP/1.0) then you need to change your transparent proxy to act on the port (TCP80 and usually also TCP443) which the client tries to connect to (which the client thinks is the server it will speak to but by routing it will actually speak to the proxy session-wise).

thanks miklond but I don't know how to DNAT my dest port from 80 to 8080 because PA need an IP adresse (orginal dest & translated dest.) and I could not know the dest. IP (internet).

L5 Sessionator

Hi

you can look on page 15 on how to configure destination NAT of the following doc.

https://live.paloaltonetworks.com/docs/DOC-1517

Please let us know if this helps.

Thank you

mbutt

Not applicable

Hi

So I suppose your answer mean:"it's not possible because you could not create a port translation if in the orginal packet the destination IP is Internet (any)"

Cant you in the Translated Packet -> Destination Translation just leave the ip address blank and put in a value for translated port?

Nope.

If you leave blank the destination adresse you could not click on OK.

But what I need is to NAT the destination address (any) to the proxy adresse which is not possible...

I think there is no way to forward http communication to a proxy server... (not possible with PBF or NAT).

Again that depends on how you have setup your proxy.

If you proxy is a non-transparent one (see previous posts in this thread for an example of the differences) then you can just make the PA to force the traffic into the proxy by specify translated address into proxyip:proxyport.

But if you use a webproxy in transparent mode changing the dstport will break things in how the webproxy will handle the traffic.

This is what will happen (when things go bad if you try to change dstport when using a transparent proxy):

1) Your client wants to go to http://www.google.com and your dns resolver replies to the client with 173.194.71.105.

2) Client will now try to establish a tcp connection towards 173.194.71.105:80.

3) Traffic goes through your PA who (what you request if I understood your question correctly) will change dstport from 80 into 8080. So on the other end of the PA the packet has now 173.194.71.105:8080.

4) Traffic reaches your transparent proxy who accepts it and process it. On the other side of the transparent proxy the session which the proxy tries to establish will go to 173.194.71.105:8080 and not 173.194.71.105:80.

5) Since www.google.com [173.194.71.105] doesnt listen to TCP8080 the traffic cannot be established from the proxy and the proxy will reply to the client "ERROR: server unreachable" (or similar).

Now, in order for a DNAT redirecting traffic into your proxy (with changed dstport) to function you must configure it to non-transparent mode (and configure the clients to use proxy). Meaning that the proxy will look within the http header instead of ip header on where to make the outbound connection.

Another solution is to configure your transparent proxy to listen to TCP80 (and TCP443 and other ports you might expect http traffic on) which when using DNAT you will leave "translated port" empty and things will work...

Hope I correclty understand your reply but I'm not agree with:


"Another solution is to configure your transparent proxy to listen to TCP80 (and TCP443 and other ports you might expect http traffic on) which when using DNAT you will leave "translated port" empty and things will work..."

Because you could not DNAT destination IP if you don't know the IP address of the orginal packet.

And, of course, you could not set "Any" on original paquet dest. IP and the proxy IP on translated destination IP (Mismatch of destination address translation range between original address and translated address).


  • 7580 Views
  • 13 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!