IPFW fwd issue.
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. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW fwd issue.
Dan Johnson wrote: 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. so, what revision are you trying to do this on? I think in 6.1 it was disabled without an extra option. (see in LINT) 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.) that sounds a bit like the problem I mention above... however, sending it to 127.0.0.1 doesn't mean it goes through lo0 so you'll never see it there. 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. ah that will fail because the IPFIREWALL_FORWARD option has to change things in teh tcp and Ip code too. After noting that I was using a module, I said screw it, and compiled IPFW into the base kernel, viola now it works fine. yeah the whole ip stack need to be compiled with those options.. ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW fwd issue.
On Fri, Oct 3, 2008 at 12:01 AM, Julian Elischer [EMAIL PROTECTED]wrote: Dan Johnson wrote: 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. so, what revision are you trying to do this on? I think in 6.1 it was disabled without an extra option. (see in LINT) 7.0-Release. In my research I'd found that in 6 and I believe some point in 5.x the option IPFIREWALL_FORWARD_EXTENDED was needed for this configuration, but apparently it was switched back for 7. 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.) that sounds a bit like the problem I mention above... however, sending it to 127.0.0.1 doesn't mean it goes through lo0 so you'll never see it there. 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. ah that will fail because the IPFIREWALL_FORWARD option has to change things in teh tcp and Ip code too. Thats what I figured might have been the case, odd that there were no errors logged in the firewall logs though. After noting that I was using a module, I said screw it, and compiled IPFW into the base kernel, viola now it works fine. yeah the whole ip stack need to be compiled with those options.. Hopefully next person with this issue wont bang their head on the wall as long once this thread is indexed. :) ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPFW fwd issue.
Dan Johnson wrote: On Fri, Oct 3, 2008 at 12:01 AM, Julian Elischer [EMAIL PROTECTED]wrote: Dan Johnson wrote: 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. so, what revision are you trying to do this on? I think in 6.1 it was disabled without an extra option. (see in LINT) 7.0-Release. In my research I'd found that in 6 and I believe some point in 5.x the option IPFIREWALL_FORWARD_EXTENDED was needed for this configuration, but apparently it was switched back for 7. yeah that was me switching it back.. the whole feature is kinds useless without being able to do that.. man ssh 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.) that sounds a bit like the problem I mention above... however, sending it to 127.0.0.1 doesn't mean it goes through lo0 so you'll never see it there. 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. ah that will fail because the IPFIREWALL_FORWARD option has to change things in teh tcp and Ip code too. Thats what I figured might have been the case, odd that there were no errors logged in the firewall logs though. After noting that I was using a module, I said screw it, and compiled IPFW into the base kernel, viola now it works fine. yeah the whole ip stack need to be compiled with those options.. Hopefully next person with this issue wont bang their head on the wall as long once this thread is indexed. :) ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to [EMAIL PROTECTED]
