NAT Outbound LAN TCP:80 (HTTP) => proxy:3142

freakalad

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 set export 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]

jonallport

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.

freakalad

@jonallport:

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.