How do I stop the ProxySG from using a SOCKS Gateway instead of the configured Forwarding Host?
Article ID: 166176
Updated On:
Products
Issue/Introduction
You have two ProxySGs configured in a proxy chain. Between the two proxies sits a firewall that only allows HTTP Port 8080 to pass. The downstream proxy has both a forwarding host and SOCKS gateway configured. There is a policy for the proxy to forward the traffic using the Forwarding Host (HTTP Proxy).
After some investigating, you find that the user traffic that is supposed to use the Forwarding Host (HTTP Proxy) to forward the traffic to the upstream proxy is using the Socks Gateway instead.
This leads to the traffic being dropped since SOCKS port 1080 is blocked on the firewall.
The Forwarding settings for this scenario are below:!- BEGIN proxies
forwarding ;mode
create host "SG1" 10.105.13.210 http=8080 ssl-verify-server=no proxy
exit
socks-gateways ;mode
create gateway "SOCKS_SG1" 10.105.13.210 1080 version=4sequence add "SOCKS_SG1"
exit
!- END proxies
And the policy as below:
; Default proxy policy is ALLOW ; Policy Rules <Forward> forward("SG1") forward.fail_open(no)
Resolution
This issue is caused by the configuration of the SOCKS gateway default sequence. Removing all the SOCKS gateway default sequence will resolve the issue.
However this behaviour is expected, when a SOCKS gateway default sequence has been configured. Forwarding hosts and SOCKS gateways are not mutually exclusive. It is expected that traffic can be sent through both at once (where the SG would connect to the SOCKS gateway and tell it to connect to the forwarding host, and then the SG would send the forwarding host an HTTP request which referenced the URL of the origin server.
If you have a SOCKS default sequence configured and the ProxySG policy does not have a socks_gateway(no) rule in policy, the expected behavior would be to use the SOCKS gateway in the default sequence even if a forwarding host rule matches. The forwarding rule would just cause the SG to tell the SOCKS gateway to connect to the forwarding host instead of the Origin Content Server (OCS).
Troubleshooting information, used to confirm the cause and lead to the above solution
The policy trace shows that the client matched the rule where it suppose to use the Forwarding Host object and not the SOCKS Gateway. start transaction ------------------- CPL Evaluation Trace: transaction ID=374766 <Forward> MATCH: forward("SG1") forward.fail_open(no) <Proxy> MATCH: client.address=10.105.13.211 trace.request(yes) trace.rules(all) trace.destination(Trace1) connection: service.name=Explicit HTTP client.address=10.105.13.211 proxy.port=8080 time: 2012-07-09 02:49:56 UTC GET http://www.google.com.my/ user: unauthenticated application.name: none application.operation: none DSCP client outbound: 65 DSCP server outbound: 65 stop transaction -------------------- The Child proxy pcap shows that the client IP - 10.105.13.211 sends the request (www.google.com.my) to the child proxy (eg: frame 315) and that child proxy (10.105.13.214) forwards the traffic to the parent proxy using the SOCKS gateway on port 1080 (eg: Frame 321) instead. It should forward the traffic on HTTP port 8080 to the upstream proxy (10.105.13.210): No. Time Source Destination SrcPort DstPort PacketLengths Protocol Info 315 13.967999 10.105.13.211 10.105.13.214 1405 8080 847 HTTP GET http://www.google.com.my/ HTTP/1.0 321 13.976999 10.105.13.214 10.105.13.210 58380 1080 939 HTTP GET http://www.google.com.my/ HTTP/1.0 609 14.951000 10.105.13.211 10.105.13.214 1406 8080 802 HTTP GET http://www.google.com.my/xjs/_/js/s/s,st,anim,bbd,c,sb,hv,wta,cr,cdos,pj,tbpr,tbui,rsn,ob,mb,lc,du,ada,bihu,lu,m,shb,tng,hsm,j,p,pcc,csitl/rt=j/ver=3_CKYLPB3pI.en_US./d=1/rs=AItRSTPfqL3ISdDDm5M0pWK5d5DIH-_vDA HTTP/1.0 615 14.967000 10.105.13.214 10.105.13.210 57840 1080 944 HTTP GET http://www.google.com.my/xjs/_/js/s/s,st,anim,bbd,c,sb,hv,wta,cr,cdos,pj,tbpr,tbui,rsn,ob,mb,lc,du,ada,bihu,lu,m,shb,tng,hsm,j,p,pcc,csitl/rt=j/ver=3_CKYLPB3pI.en_US./d=1/rs=AItRSTPfqL3ISdDDm5M0pWK5d5DIH-_vDA HTTP/1.0 1136 15.075000 10.105.13.211 10.105.13.214 1407 8080 418 HTTP GET http://ssl.gstatic.com/gb/js/sem_feed2a2e2d54cd5f40fb4b5f5244fff2.js HTTP/1.0 1197 15.101000 10.105.13.214 10.105.13.210 50583 1080 560 HTTP GET http://ssl.gstatic.com/gb/js/sem_feed2a2e2d54cd5f40fb4b5f5244fff2.js HTTP/1.0 1243 15.146999 10.105.13.211 10.105.13.214 1408 8080 916 HTTP GET http://www.google.com.my/compressiontest/gzip.html HTTP/1.0 1274 15.161000 10.105.13.214 10.105.13.210 54841 1080 1008 HTTP GET http://www.google.com.my/compressiontest/gzip.html HTTP/1.0 1286 15.230999 10.105.13.211 10.105.13.214 1409 8080 672 HTTP GET http://www.google.com/gen_204?atyp=i&zx=1341802198505&oge=8&ogex=38909&ogf=.36.40.&ogp=1&ogrp=&ogsr=1&ogv=1340918248.1340829706&oggv=es_plusone_gc_20120617.0_p0&ogd=com.my&ogl=en HTTP/1.0 1292 15.238000 10.105.13.214 10.105.13.210 55108 1080 764 HTTP GET http://www.google.com/gen_204?atyp=i&zx=1341802198505&oge=8&ogex=38909&ogf=.36.40.&ogp=1&ogrp=&ogsr=1&ogv=1340918248.1340829706&oggv=es_plusone_gc_20120617.0_p0&ogd=com.my&ogl=en HTTP/1.0 1301 15.325000 10.105.13.211 10.105.13.214 1409 8080 822 HTTP GET http://www.google.com.my/csi?v=3&s=webhp&action=&e=25657,38787,38816,38909,39366,39370,39514,39604,39730,39840&ei=1Eb6T4D-M9DhrAezocTUAQ&imc=1&imn=1&imp=0&rt=xjsls.782,prt.875,ol.875,iml.875,xjses.969,xjsee.1063,xjs.1172 HTTP/1.0 1307 15.332999 10.105.13.214 10.105.13.210 57930 1080 914 HTTP GET http://www.google.com.my/csi?v=3&s=webhp&action=&e=25657,38787,38816,38909,39366,39370,39514,39604,39730,39840&ei=1Eb6T4D-M9DhrAezocTUAQ&imc=1&imn=1&imp=0&rt=xjsls.782,prt.875,ol.875,iml.875,xjses.969,xjsee.1063,xjs.1172 HTTP/1.0
Feedback
