Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 May 2016 22:28:58 +0800
From:      Julian Elischer <julian@freebsd.org>
To:        Adonis Peralta <donileo@gmail.com>, freebsd-ipfw@freebsd.org
Subject:   Re: ipfw fwd sends to port but also through gateway
Message-ID:  <98c5b4fe-151f-1be1-7d29-89a89c5616ec@freebsd.org>
In-Reply-To: <9227BA17-B289-494D-8A82-603DB1B35457@gmail.com>
References:  <9227BA17-B289-494D-8A82-603DB1B35457@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 26/05/2016 2:03 AM, Adonis Peralta wrote:
> Hi all,
>
> I am noticing something weird in regards to ipfw forwarding when I am attempting to set up squid web proxying.
>
> Here is the info:
>
> ipfw rule: ipfw -q add fwd 127.0.0.1,8080 tcp from 192.168.1.0/24{1-5,7-254} to any dst-port 80 in via igb0 //I exclude the servers ip 192.168.1.6 here to prevent a loop
> Squid Proxy: running on localhost (127.0.0.1) port 8080.
> Freebsd box ip: 192.168.1.6
> Router box: 192.168.1.1
>
> Essentially when any ip (not my freebsd ip) makes a request to port 80 my router will route that ip using policy based routing to my freebsd box. Then the ipfw fwd rule above sends that traffic over to my squid proxy port. This is working fine and the fwd rule above does definitely match.
> However the issue Im seeing is that ipfw fwd not only sends the packet out to the squid proxy but ALSO sends it out to the original destination causing all sorts of issues for my client because it messes up the tcp flow/handshaking.
>
> To be more clear what I see is when client 192.168.1.3 makes a request on port 80… my freebsd box receives it.. then forwards it to squid but also sends it out to the original destination so for every packet coming to port 80 i see two going out..
>
> To debug this problem a bit further I stopped squid, and setup "nc -l 8080" to catch incoming requests via the fwd.
>
> Doing a tcpdump I see:
>
> 192.168.1.3.57653 > s3-us-west-1.amazonaws.com.http: Flags [S], cksum 0x9385 (correct), seq 1939422713, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1149232947 ecr 0,sackOK,eol], length 0
> 13:14:16.209753 IP (tos 0x0, ttl 64, id 10951, offset 0, flags [DF], proto TCP (6), length 60)
>      s3-us-west-1.amazonaws.com.http > 192.168.1.3.57653: Flags [S.], cksum 0xe4da (incorrect -> 0x8343), seq 3934654233, ack 1939422714, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 1794161828 ecr 1149232947], length 0
>
> Netcat catches the HTTP Get request (i can see it in netcats console).. but the above tcpdump definitely tells me that the request was also sent to to aws itself this is implied by the fact that aws responded back to original ip (192.168.1.3).
>
> When I have squid running I see the same thing in the above tcpdump but also communication between my freebsd box ip 192.168.1.6 and the requested http site.
>
>   Why is this happening? Is this a bug?
definitely sounds like a bug..  The fwd rule is supposed to terminate 
the search..  Can you confirm that a matching rule following the fwd 
does not see the packet continuing on? I used it for many years and it 
acted as expected.
Is there any rule you can add that catches the outgoing extra packet 
and blocks it (as a work-around)
what does squid's outgoing packet look like? is it masquerading the 
client or is it using its own address?


>
> -Adonis
> _______________________________________________
> freebsd-ipfw@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98c5b4fe-151f-1be1-7d29-89a89c5616ec>