NAT Outbound LAN TCP:80 (HTTP) => proxy:3142
-
Hi guys,
Been poking on IRC a bit, but not finding any solution.
The closest I could find in the forum is this fairly old post (circa 2006), so I'm hoping that some advances or solutions have surfaved been made since then.I've set up a squid host, primarily to cache repo's & purge unwanted content at the gateway. HTTS can go through un-MitM'd
My pfSense host is an embedded box, running quite lean, so I'd like to avoid adding anything to it that I could otherwise avoid, or that would put load on it.I have tried adding the squid packages to achieve the "simple" functionality of pointing it to an upstream proxy (i.e. my squid host), but that seems like adding more resource-overhead to an otherwise lean system that should/could be achieved with an outbound NAT.
To this effect, I've set up a NAT (& associated rule) along these lines: (may need some work - comments welcome)
- Interface: LAN
- Protocol: TCP
- Source: [not] Single Host or Alias - set to an alias for my proxy (this is to avoid a recursive loop condition where the proxy would proxy itself)
- Source port range: any
- Destination: [not] LAN subnet
- Destination port range: HTTP
- Redirect target IP: proxy (alias as above)
- Redirect target port: 3128
I presently have the source address set to my own machine for testing purposes.
I've opened 2 terminals.
The 1st being a default shell - intercepted & NAT'd to the proxy via gateway, & the 2nd I've setexport http_proxy=proxy:3128
.On the proxy I've bust out tcpdump, to keep an eye on things (my skills here leave something to be desired :/ ).
For "http_proxy=proxy:3128", the client (curl, w3m, GET) works OK, but for "http_proxy=" (i.e "transparent" NAT), I can see TCP packets hitting the proxy - so I know the NAT is operational - but the results look slightly different, & the client fails to receive data.
tcpdump results for "http_proxy=proxy:3128"
$PROXY.3128 > $CLIENT.48989: Flags [.], cksum 0x1a91 (incorrect -> 0x82f0), seq 1:1449, ack 129, win 1944, options [nop,nop,TS val 7032248 ecr 37271399], length 1448 $PROXY.3128 > $CLIENT.48989: Flags [P.], cksum 0x1511 (incorrect -> 0x20cf), seq 1449:1489, ack 129, win 1944, options [nop,nop,TS val 7032248 ecr 37271399], length 40 $PROXY.3128 > $CLIENT.48989: Flags [P.], cksum 0x1a15 (incorrect -> 0x0fdb), seq 1489:2813, ack 129, win 1944, options [nop,nop,TS val 7032248 ecr 37271399], length 1324
tcpdump results for "http_proxy=" (NAT) - times out
$PROXY.3128 > $CLIENT.33846: Flags [S.], cksum 0x14f1 (incorrect -> 0xd4e4), seq 4039847871, ack 1431996432, win 14480, options [mss 1460,sackOK,TS val 7116342 ecr 37355132,nop,wscale 3], length 0 $PROXY.3128 > $CLIENT.33846: Flags [S.], cksum 0x14f1 (incorrect -> 0xd4b6), seq 4039847871, ack 1431996432, win 14480, options [mss 1460,sackOK,TS val 7116388 ecr 37355132,nop,wscale 3], length 0 $CLIENT.33847 > $PROXY.3128: Flags [s], cksum 0x0cb6 (correct), seq 3766908032, win 14600, options [mss 1460,sackOK,TS val 37357007 ecr 0,nop,wscale 7], length 0 $PROXY.3128 > $CLIENT.33847: Flags [S.], cksum 0x14f1 (incorrect -> 0xe571), seq 432765365, ack 3766908033, win 14480, options [mss 1460,sackOK,TS val 7116465 ecr 37356256,nop,wscale 3], length 0 $PROXY.3128 > $CLIENT.33847: Flags [S.], cksum 0x14f1 (incorrect -> 0xe55a), seq 432765365, ack 3766908033, win 14480, options [mss 1460,sackOK,TS val 7116488 ecr 37356256,nop,wscale 3], length 0 The latter block having a length of 0. At least, on the surface (some WIreShark next), this is the only discrepancy I could find. I'm hoping someone can aide in this - it seems that all/most functional components are in-place, but that I'm missing something somewhere. Thanks - J[/s]
-
I've always handled upstream transparent proxy like this:
-
Install squid package on pfSense
-
Configure squid for local proxy redirect
-
Set squid to forward to upstream proxy
It's always worked for me.
-
-
I've always handled upstream transparent proxy like this:
..
It's always worked for me.I've had it set up that way myself, but if I've got a proxy on the gateway pointing off to another proxy host, I might as well have it there to begin with - it's the load overhead associated with the gateway proxy I'd like to avoid.
May have to resort it this setup in the end, although it might not be ideal.