Hi, I have the following rules to transparently redirect all port 80 traffic (including that originating on the firewall itself) to my firewall+proxy server while not going into a redirect loop for the processes running on the server itself (by excluding using !:group). However, a local process running on the server is also seeing its traffic redirected to the proxy resulting in a forwarding loop? Any ideas, or what are the requirements for the exclusion by group? REDIRECT loc 33128 tcp www - !10.0.0.0/28 REDIRECT $FW 33128 tcp www - !10.0.0.0/24 - !:proxy Thanks, Anshuman ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 07/04/2012 03:33 AM, Anshuman Aggarwal wrote:> Hi, > I have the following rules to transparently redirect all port 80 > traffic (including that originating on the firewall itself) to my > firewall+proxy server while not going into a redirect loop for the > processes running on the server itself (by excluding using !:group). > However, a local process running on the server is also seeing its > traffic redirected to the proxy resulting in a forwarding loop? > > Any ideas, or what are the requirements for the exclusion by group? > REDIRECT loc 33128 tcp www - !10.0.0.0/28 > REDIRECT $FW 33128 tcp www - > !10.0.0.0/24 - !:proxyWhen I try that, I don''t get a forwarding loop; but it doesn''t work and I''m seeing this: Jul 4 07:09:19 gateway fw-net REJECT IN= OUT=eth1 SRC=70.90.191.121 DST=127.0.0.1 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=61499 CE DF PROTO=TCP SPT=37282 DPT=3128 SEQ=2835240680 ACK=0 WINDOW=5840 SYN URGP=0 Note that it is trying to route packets to the local system (DST=127.0.0.1) out of eth1. The ip stack doesn''t seem to be re-routing the packet after NAT is applied. This is on Debian Squeeze. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 7/4/12 7:23 AM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 07/04/2012 03:33 AM, Anshuman Aggarwal wrote: >> Hi, >> I have the following rules to transparently redirect all port 80 >> traffic (including that originating on the firewall itself) to my >> firewall+proxy server while not going into a redirect loop for the >> processes running on the server itself (by excluding using !:group). >> However, a local process running on the server is also seeing its >> traffic redirected to the proxy resulting in a forwarding loop? >> >> Any ideas, or what are the requirements for the exclusion by group? >> REDIRECT loc 33128 tcp www - >>!10.0.0.0/28 >> REDIRECT $FW 33128 tcp www - >> !10.0.0.0/24 - !:proxy > >When I try that, I don''t get a forwarding loop; but it doesn''t work and >I''m seeing this: > >Jul 4 07:09:19 gateway fw-net REJECT IN= OUT=eth1 SRC=70.90.191.121 >DST=127.0.0.1 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=61499 CE DF PROTO=TCP >SPT=37282 DPT=3128 SEQ=2835240680 ACK=0 WINDOW=5840 SYN URGP=0 > >Note that it is trying to route packets to the local system >(DST=127.0.0.1) out of eth1. The ip stack doesn''t seem to be re-routing >the packet after NAT is applied. This is on Debian Squeeze.However, if I allow tcp port 80 *for all users* fw->net, then it works and still goes through the proxy (without loops). -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
I have allowed port 80 to all users and the redirect works. Problem is I have a apt-cacher-ng proxy process which is run as apt-cacher-ng with group apt-cacher-ng which proxies the debian packages and which I want to access port 80 directly. For this process to be excluded, I made its primary group ''proxy'' and changed the init script so it launched the process with the group as ''proxy'' . still the redirect loop is happening for this apt-cacher-ng process Thanks, Anshuman On 4 July 2012 19:53, Tom Eastep <teastep@shorewall.net> wrote:> On 07/04/2012 03:33 AM, Anshuman Aggarwal wrote: >> Hi, >> I have the following rules to transparently redirect all port 80 >> traffic (including that originating on the firewall itself) to my >> firewall+proxy server while not going into a redirect loop for the >> processes running on the server itself (by excluding using !:group). >> However, a local process running on the server is also seeing its >> traffic redirected to the proxy resulting in a forwarding loop? >> >> Any ideas, or what are the requirements for the exclusion by group? >> REDIRECT loc 33128 tcp www - !10.0.0.0/28 >> REDIRECT $FW 33128 tcp www - >> !10.0.0.0/24 - !:proxy > > When I try that, I don''t get a forwarding loop; but it doesn''t work and > I''m seeing this: > > Jul 4 07:09:19 gateway fw-net REJECT IN= OUT=eth1 SRC=70.90.191.121 > DST=127.0.0.1 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=61499 CE DF PROTO=TCP > SPT=37282 DPT=3128 SEQ=2835240680 ACK=0 WINDOW=5840 SYN URGP=0 > > Note that it is trying to route packets to the local system > (DST=127.0.0.1) out of eth1. The ip stack doesn''t seem to be re-routing > the packet after NAT is applied. This is on Debian Squeeze. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-usersOn 4 July 2012 23:55, Tom Eastep <teastep@shorewall.net> wrote:> On 7/4/12 7:23 AM, "Tom Eastep" <teastep@shorewall.net> wrote: > >>On 07/04/2012 03:33 AM, Anshuman Aggarwal wrote: >>> Hi, >>> I have the following rules to transparently redirect all port 80 >>> traffic (including that originating on the firewall itself) to my >>> firewall+proxy server while not going into a redirect loop for the >>> processes running on the server itself (by excluding using !:group). >>> However, a local process running on the server is also seeing its >>> traffic redirected to the proxy resulting in a forwarding loop? >>> >>> Any ideas, or what are the requirements for the exclusion by group? >>> REDIRECT loc 33128 tcp www - >>>!10.0.0.0/28 >>> REDIRECT $FW 33128 tcp www - >>> !10.0.0.0/24 - !:proxy >> >>When I try that, I don''t get a forwarding loop; but it doesn''t work and >>I''m seeing this: >> >>Jul 4 07:09:19 gateway fw-net REJECT IN= OUT=eth1 SRC=70.90.191.121 >>DST=127.0.0.1 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=61499 CE DF PROTO=TCP >>SPT=37282 DPT=3128 SEQ=2835240680 ACK=0 WINDOW=5840 SYN URGP=0 >> >>Note that it is trying to route packets to the local system >>(DST=127.0.0.1) out of eth1. The ip stack doesn''t seem to be re-routing >>the packet after NAT is applied. This is on Debian Squeeze. > > However, if I allow tcp port 80 *for all users* fw->net, then it works and > still goes through the proxy (without loops). > > -Tom > You do not need a parachute to skydive. You only need a parachute to > skydive twice. > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 7/4/12 11:25 AM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 7/4/12 7:23 AM, "Tom Eastep" <teastep@shorewall.net> wrote: > >>When I try that, I don''t get a forwarding loop; but it doesn''t work and >>I''m seeing this: >> >>Jul 4 07:09:19 gateway fw-net REJECT IN= OUT=eth1 SRC=70.90.191.121 >>DST=127.0.0.1 LEN=60 TOS=00 PREC=0x00 TTL=64 ID=61499 CE DF PROTO=TCP >>SPT=37282 DPT=3128 SEQ=2835240680 ACK=0 WINDOW=5840 SYN URGP=0 >> >>Note that it is trying to route packets to the local system >>(DST=127.0.0.1) out of eth1. The ip stack doesn''t seem to be re-routing >>the packet after NAT is applied. This is on Debian Squeeze. > >However, if I allow tcp port 80 *for all users* fw->net, then it works and >still goes through the proxy (without loops).As in: Web(ACCEPT) fw net - - - - - :proxy Web(REDIRECT-) fw 3128 tcp 80 - - - !:proxy ACCEPT:info(uid fw net:127.0.0.1 -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 7/4/12 11:35 AM, "Anshuman Aggarwal" <anshuman.aggarwal@gmail.com> wrote:>I have allowed port 80 to all users and the redirect works. > >Problem is I have a apt-cacher-ng proxy process which is run as >apt-cacher-ng with group apt-cacher-ng which proxies the debian >packages and which I want to access port 80 directly. For this process >to be excluded, I made its primary group ''proxy'' and changed the init >script so it launched the process with the group as ''proxy'' . still >the redirect loop is happening for this apt-cacher-ng processThen you are doing something different than I''m doing (besides running apt-cacher-ng rather than Squid3). -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 7/4/12 11:50 AM, Tom Eastep wrote:> On 7/4/12 11:35 AM, "Anshuman Aggarwal" <anshuman.aggarwal@gmail.com> > wrote: > >> I have allowed port 80 to all users and the redirect works. >> >> Problem is I have a apt-cacher-ng proxy process which is run as >> apt-cacher-ng with group apt-cacher-ng which proxies the debian >> packages and which I want to access port 80 directly. For this process >> to be excluded, I made its primary group ''proxy'' and changed the init >> script so it launched the process with the group as ''proxy'' . still >> the redirect loop is happening for this apt-cacher-ng process > > > Then you are doing something different than I''m doing (besides running > apt-cacher-ng rather than Squid3).If you send us the output of ''shorewall dump'' as a compressed attachment, we''ll take a look. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
I''m actually running both squid and apt-cacher-ng. Squid uses apt-cacher-ng internally as a parent, only for deb packages to save bandwidth since apt-cacher handles that better than squid...and both do it transparently. Here is how it''s supposed to work and was working earlier before I upgraded to Ubuntu Precise from Lucid. web request outgoing on port 80 -> FW -> port 33128 (squid) -> Internet apt request outgoing on port 80 -> FW -> port 33128 (squid) -> port 33142 (apt) -> Internet note both squid and apt are running locally on the firewall machine, under the primary group proxy. Attaching compressed shore wall dump Thanks, Anshuman On 5 July 2012 03:08, Tom Eastep <teastep@shorewall.net> wrote:> On 7/4/12 11:50 AM, Tom Eastep wrote: >> On 7/4/12 11:35 AM, "Anshuman Aggarwal" <anshuman.aggarwal@gmail.com> >> wrote: >> >>> I have allowed port 80 to all users and the redirect works. >>> >>> Problem is I have a apt-cacher-ng proxy process which is run as >>> apt-cacher-ng with group apt-cacher-ng which proxies the debian >>> packages and which I want to access port 80 directly. For this process >>> to be excluded, I made its primary group ''proxy'' and changed the init >>> script so it launched the process with the group as ''proxy'' . still >>> the redirect loop is happening for this apt-cacher-ng process >> >> >> Then you are doing something different than I''m doing (besides running >> apt-cacher-ng rather than Squid3). > > If you send us the output of ''shorewall dump'' as a compressed > attachment, we''ll take a look. > > -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today''s security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
On 07/04/2012 09:32 PM, Anshuman Aggarwal wrote:> I''m actually running both squid and apt-cacher-ng. Squid uses > apt-cacher-ng internally as a parent, only for deb packages to save > bandwidth since apt-cacher handles that better than squid...and both > do it transparently. > Here is how it''s supposed to work and was working earlier before I > upgraded to Ubuntu Precise from Lucid. > > web request outgoing on port 80 -> FW -> port 33128 (squid) -> Internet > apt request outgoing on port 80 -> FW -> port 33128 (squid) -> port > 33142 (apt) -> Internet > > note both squid and apt are running locally on the firewall machine, > under the primary group proxy. > > Attaching compressed shore wall dumpIn the dump, I don''t see any process listening on port 33142. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today''s security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/