Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

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

    NAT
    2
    3
    2967
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • F
      freakalad last edited by

      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]
      
      1 Reply Last reply Reply Quote 0
      • J
        jonallport last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • F
          freakalad last edited by

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

          1 Reply Last reply Reply Quote 0
          • First post
            Last post

          Products

          • Platform Overview
          • TNSR
          • pfSense
          • Appliances

          Services

          • Training
          • Professional Services

          Support

          • Subscription Plans
          • Contact Support
          • Product Lifecycle
          • Documentation

          News

          • Media Coverage
          • Press
          • Events

          Resources

          • Blog
          • FAQ
          • Find a Partner
          • Resource Library
          • Security Information

          Company

          • About Us
          • Careers
          • Partners
          • Contact Us
          • Legal
          Our Mission

          We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

          Subscribe to our Newsletter

          Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

          © 2021 Rubicon Communications, LLC | Privacy Policy