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

  • 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.


  • @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.