Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Oct 2008 18:12:37 -0400
From:      "Dan Johnson" <dan_johnson@doomed.us>
To:        freebsd-ipfw@freebsd.org
Subject:   IPFW fwd issue.
Message-ID:  <f29069d60810021512h1483be20t8010d62b69647991@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
After beating my head against this for days I ran out of places to look for
information, and almost sent this as a help request instead of an
observation. So excuse the present tense.


All I am actually trying to accomplish is a simple (This worked flawless
last i tried under 4.5) squid transparent proxy.
I'm using this rule before the nat rule:

00100 fwd 127.0.0.1,3128 log ip from any to any 80 out

When I attempt to hit port 80 on an external server, the security log shows
the rule was processed, and claims it was forwarded to 127.0.0.1,3128. OK

Watching tcpdump -nnvvei lo0 shows no relevant activity. BUT, watching
tcpdump -nnvvei xl1 (external iface) shows the port 80 SYN being sent to the
remote web server with the original source ip address from 192.168.0.0/24,
still using the destination MAC of my default gateway. This is with or
without the squid daemon running. And when i do have it running i have it on
the local console with debugging enabled (incase a stray packet actually
makes it in.)

The same holds true if i setup the fwd to my xl1 interface ip address, or
another host ex 192.168.0.30.

Running tcpdump (Linux) eth0 in promisc on 192.168.0.30 also doesn't show
any traffic being forwarded its way when configured to do so. So I'm
inclined to beleive this isn't just an error on tcpdumps part (as there is
an open issue reported with tcpdump and ipfw fwd) but that the traffic
really isn't being modified.

The only thing I was doing that is unique is I recompiled the ipfw module to
include -DIPFIREWALL_NAT and -DIPFIREWALL_FORWARD instead of adding the
whole mess to the base kernel.

After noting that I was using a module, I said screw it, and compiled IPFW
into the base kernel, viola now it works fine.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f29069d60810021512h1483be20t8010d62b69647991>