Hi all, I can make it work shorewall following the transparent proxy
documentation.
My configuration is a virtual machine running Squid with shorewall,
connected with a virtual bridge to the host that also runs shorewall.
The Squid part (on the virtual machine) works perfectly with
shorewall. But the routing part on the host doesn''t.
My interfaces configuration is:
net eth0 detect logmartians,nosmurfs,routefilter,tcpflags
loc eth1 detect logmartians,nosmurfs,routefilter,tcpflags
kvm ovsbr0 detect
routeback,logmartians,nosmurfs,routefilter,tcpflags
ovsbr0 is the virtual switch where the Squid is connected, the switch
has IP 192.168.200.1 and the Squid VM 192.168.200.2
My masq configuration is:
eth0 10.0.0.0/8,\
192.168.200.2 157.X.X.X
policy:
$FW net ACCEPT
$FW kvm ACCEPT
loc net ACCEPT
loc kvm ACCEPT
kvm net ACCEPT
kvm loc ACCEPT
all all REJECT info
providers:
Squid 1 202 - ovsbr0 192.168.200.2 loose,notrack
tcrules:
202:P eth1:!192.168.200.2 0.0.0.0/0 tcp 80
zones:
fw firewall
net ipv4
loc ipv4
kvm ipv4
And if I do a tcpdump on the Squid VM I can see the packages entering
the VM and going out again to the machine that made the request like:
14:08:01.456450 IP 10.99.32.124.36480 > 173.194.42.1.80: Flags [S],
seq 2797245282, win 14600, options [mss 1460,sackOK,TS val 1975561 ecr
0,nop,wscale 4], length 0
14:08:01.456477 IP 173.194.42.1.80 > 10.99.32.124.36480: Flags [S.],
seq 1740205425, ack 2797245283, win 5792, options [mss 1460,sackOK,TS
val 455790 ecr 1975561,nop,wscale 6], length 0
try to access Google. But nothing appears on Squid logs and on the
request machine.
Last thing is that I know that the Squid part is working because using
the redirect rule in shorewall there and configuring the host by hand
and not shorewall it works as expected.
Let me know any other information that you may need to try solve my problem.
Thanks for all.
Ernesto
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/18/13 10:23 AM, "Ernesto Domato" <edomat@gmail.com> wrote:>Hi all, I can make it work shorewall following the transparent proxy >documentation. > >My configuration is a virtual machine running Squid with shorewall, >connected with a virtual bridge to the host that also runs shorewall. > >The Squid part (on the virtual machine) works perfectly with >shorewall. But the routing part on the host doesn''t. > >My interfaces configuration is: > >net eth0 detect logmartians,nosmurfs,routefilter,tcpflags >loc eth1 detect logmartians,nosmurfs,routefilter,tcpflags >kvm ovsbr0 detect >routeback,logmartians,nosmurfs,routefilter,tcpflags > >ovsbr0 is the virtual switch where the Squid is connected, the switch >has IP 192.168.200.1 and the Squid VM 192.168.200.2 > >My masq configuration is: > >eth0 10.0.0.0/8,\ > 192.168.200.2 157.X.X.X > >policy: > >$FW net ACCEPT >$FW kvm ACCEPT > >loc net ACCEPT >loc kvm ACCEPT >kvm net ACCEPT >kvm loc ACCEPT > >all all REJECT info > >providers: > >Squid 1 202 - ovsbr0 192.168.200.2 loose,notrack > >tcrules: > >202:P eth1:!192.168.200.2 0.0.0.0/0 tcp 80 > >zones: > >fw firewall >net ipv4 >loc ipv4 >kvm ipv4 > >And if I do a tcpdump on the Squid VM I can see the packages entering >the VM and going out again to the machine that made the request like: > >14:08:01.456450 IP 10.99.32.124.36480 > 173.194.42.1.80: Flags [S], >seq 2797245282, win 14600, options [mss 1460,sackOK,TS val 1975561 ecr >0,nop,wscale 4], length 0 > >14:08:01.456477 IP 173.194.42.1.80 > 10.99.32.124.36480: Flags [S.], >seq 1740205425, ack 2797245283, win 5792, options [mss 1460,sackOK,TS >val 455790 ecr 1975561,nop,wscale 6], length 0 > >try to access Google. But nothing appears on Squid logs and on the >request machine. > >Last thing is that I know that the Squid part is working because using >the redirect rule in shorewall there and configuring the host by hand >and not shorewall it works as expected. > >Let me know any other information that you may need to try solve my >problem.You have a REDIRECT rule on the system running Squid? -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On Thu, Apr 18, 2013 at 2:53 PM, Tom Eastep <teastep@shorewall.net> wrote:> You have a REDIRECT rule on the system running Squid? >Yes, I did this manually an also with shorewall and it works well. The configuration on the system running Squid is: interfaces; net eth0 detect tcpflags,logmartians,nosmurfs policy: $FW net ACCEPT net $FW ACCEPT all all REJECT info rules: REDIRECT net 3128 tcp www zones: fw firewall net ipv4 So, for that reason I guess that the problem is on the host system were I did the routing to the Squid system. Thanks. Ernesto ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/18/2013 12:10 PM, Ernesto Domato wrote:> On Thu, Apr 18, 2013 at 2:53 PM, Tom Eastep <teastep@shorewall.net> wrote: >> You have a REDIRECT rule on the system running Squid? >> > > > Yes, I did this manually an also with shorewall and it works well. The > configuration on the system running Squid is: > > interfaces; > > net eth0 detect tcpflags,logmartians,nosmurfs > > policy: > > $FW net ACCEPT > net $FW ACCEPT > all all REJECT info > > rules: > > REDIRECT net 3128 tcp www > > zones: > > fw firewall > net ipv4 > > So, for that reason I guess that the problem is on the host system > were I did the routing to the Squid system. >Please forward the output of ''shorewall dump'' collected as described at http://www.shorewall.net/support.htm#Guidelines Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
looks like you forgot a line in your rules rules: ACCEPT $FW net tcp www <- looks like you forgot this line REDIRECT loc 3128 tcp www To check if it is the fire wall or the proxy place #''s in front of both ACCEPT and REDIRECT this will effectively turn of the proxy. If you have connection with Internet then you have a problem with the proxy and if not you have a problem with the firewall. Eric ----- Original Message ----- From: "Tom Eastep" <teastep@shorewall.net> To: "Shorewall Users" <shorewall-users@lists.sourceforge.net> Sent: Thursday, April 18, 2013 2:26:51 PM Subject: Re: [Shorewall-users] Problem configuring transparent proxy On 04/18/2013 12:10 PM, Ernesto Domato wrote:> On Thu, Apr 18, 2013 at 2:53 PM, Tom Eastep <teastep@shorewall.net> wrote: >> You have a REDIRECT rule on the system running Squid? >> > > > Yes, I did this manually an also with shorewall and it works well. The > configuration on the system running Squid is: > > interfaces; > > net eth0 detect tcpflags,logmartians,nosmurfs > > policy: > > $FW net ACCEPT > net $FW ACCEPT > all all REJECT info > > rules: > > REDIRECT net 3128 tcp www > > zones: > > fw firewall > net ipv4 > > So, for that reason I guess that the problem is on the host system > were I did the routing to the Squid system. >Please forward the output of ''shorewall dump'' collected as described at http://www.shorewall.net/support.htm#Guidelines Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On Thu, Apr 18, 2013 at 4:26 PM, Tom Eastep <teastep@shorewall.net> wrote:> Please forward the output of ''shorewall dump'' collected as described at > http://www.shorewall.net/support.htm#Guidelines >Ok, here we go :-) Thanks. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On Thu, Apr 18, 2013 at 4:56 PM, Eric Teeter <teetere@charter.net> wrote:> looks like you forgot a line in your rules > > rules: > ACCEPT $FW net tcp www <- looks like you forgot this line > REDIRECT loc 3128 tcp www > > To check if it is the fire wall or the proxy place #''s in front of both ACCEPT and REDIRECT this will effectively turn of the proxy. > If you have connection with Internet then you have a problem with the proxy and if not you have a problem with the firewall. >If I''m not wrong, this rules are for the proxy system itself and the problem is not there. The transparent proxy works as expected. Indeed, the first rule is needed when the proxy server runs on the same machine that routes to internet, and that isn''t my case too. The problem is on the firewall that routes to the internet the connections and re-route the request to TCP port 80 to the proxy system. Thanks. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/19/2013 10:08 AM, Ernesto Domato wrote:> On Thu, Apr 18, 2013 at 4:26 PM, Tom Eastep <teastep@shorewall.net> wrote: >> Please forward the output of ''shorewall dump'' collected as described at >> http://www.shorewall.net/support.htm#Guidelines >> > > Ok, here we go :-)In /etc/shorewall/interfaces, make this change: kvm ovsbr0 detect routefilter=0,logmartians=0 ---------------------------- -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On Fri, Apr 19, 2013 at 4:55 PM, Tom Eastep <teastep@shorewall.net> wrote:> > In /etc/shorewall/interfaces, make this change: > > kvm ovsbr0 detect routefilter=0,logmartians=0 > ----------------------------Ok, I did this change on the firewall (the host machine that have the virtual one with the Squid) but it did no difference. Previous line was: kvm ovsbr0 detect routeback,logmartians,nosmurfs,routefilter,tcpflags Any other suggestion to try or way to debug the problem? :-) Thanks for all. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/22/2013 08:37 AM, Ernesto Domato wrote:> On Fri, Apr 19, 2013 at 4:55 PM, Tom Eastep <teastep@shorewall.net> wrote: >> >> In /etc/shorewall/interfaces, make this change: >> >> kvm ovsbr0 detect routefilter=0,logmartians=0 >> ---------------------------- > > Ok, I did this change on the firewall (the host machine that have the > virtual one with the Squid) but it did no difference. > > Previous line was: > > kvm ovsbr0 detect > routeback,logmartians,nosmurfs,routefilter,tcpflags > > Any other suggestion to try or way to debug the problem? :-)Are you seeing *any* messages in your system log (on either system) when you try to connect? -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On Mon, Apr 22, 2013 at 1:03 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 04/22/2013 08:37 AM, Ernesto Domato wrote: >> On Fri, Apr 19, 2013 at 4:55 PM, Tom Eastep <teastep@shorewall.net> wrote: >>> >>> In /etc/shorewall/interfaces, make this change: >>> >>> kvm ovsbr0 detect routefilter=0,logmartians=0 >>> ---------------------------- >> >> Ok, I did this change on the firewall (the host machine that have the >> virtual one with the Squid) but it did no difference. >> >> Previous line was: >> >> kvm ovsbr0 detect >> routeback,logmartians,nosmurfs,routefilter,tcpflags >> >> Any other suggestion to try or way to debug the problem? :-) > > Are you seeing *any* messages in your system log (on either system) when > you try to connect? >Ok, sorry for the late response, I didn''t have time to debug this further in this last week. I don''t see anything unusual on the logs. On the other hand, the test that I did today is to save the IPTABLES rules created by Shorewall to a file with "iptables-save > shorewall.rules". Then, I configured the machine to not start Shorewall at startup and reboot. When the machine comes up, I did "iptables-restore < shorewall.rules" and then configure the routing table to route the packets to the proxy and just turned on the ip_forward kernel flag and the transparent proxy worked as expected. So, I think that the problem that I''m having is maybe on some kernel parameter that Shorewall change. What did you suggest? Thanks. Ernesto ------------------------------------------------------------------------------ Try New Relic Now & We''ll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
On Mon, Apr 29, 2013 at 2:29 PM, Ernesto Domato <edomat@gmail.com> wrote:> On the other hand, the test that I did today is to save the IPTABLES > rules created by Shorewall to a file with "iptables-save > > shorewall.rules". Then, I configured the machine to not start > Shorewall at startup and reboot. When the machine comes up, I did > "iptables-restore < shorewall.rules" and then configure the routing > table to route the packets to the proxy and just turned on the > ip_forward kernel flag and the transparent proxy worked as expected. > > So, I think that the problem that I''m having is maybe on some kernel > parameter that Shorewall change. > > What did you suggest? >Ok, I''m still trying to solve my problem :-) The firewall machine has this interfaces: eth0 -> link to the internet eth1 -> link to the local network ovsbr0 -> OpenVSwitch connected to virtual machines (the Squid proxy server) Now, when I apply the full Shorewall rules (through "shorewall start") and do a tcpdump on eth1 and ovsbr0 I see syn packets going through ovsbr0 and syn reply packet coming back. But on the eth1 I just see the syn packet going in just one direction (the remote one that is routed by policy routing to the proxy machine) and not back to eth1 so it can reach the machine that made the request. When I apply the shorewall iptables rules only and configure ip forwarding and policy routing to the proxy by hand everything works fine. So, I still think that the problem is on some configuration on the firewall itself, even more on the kernel parameters. Any help?. Thanks. Ernesto ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On 04/30/2013 01:48 PM, Ernesto Domato wrote:> On Mon, Apr 29, 2013 at 2:29 PM, Ernesto Domato <edomat@gmail.com> wrote: >> On the other hand, the test that I did today is to save the IPTABLES >> rules created by Shorewall to a file with "iptables-save > >> shorewall.rules". Then, I configured the machine to not start >> Shorewall at startup and reboot. When the machine comes up, I did >> "iptables-restore < shorewall.rules" and then configure the routing >> table to route the packets to the proxy and just turned on the >> ip_forward kernel flag and the transparent proxy worked as expected. >> >> So, I think that the problem that I''m having is maybe on some kernel >> parameter that Shorewall change. >> >> What did you suggest? >> > > Ok, I''m still trying to solve my problem :-) > > The firewall machine has this interfaces: > > eth0 -> link to the internet > eth1 -> link to the local network > ovsbr0 -> OpenVSwitch connected to virtual machines (the Squid proxy server) > > Now, when I apply the full Shorewall rules (through "shorewall start") > and do a tcpdump on eth1 and ovsbr0 I see syn packets going through > ovsbr0 and syn reply packet coming back. But on the eth1 I just see > the syn packet going in just one direction (the remote one that is > routed by policy routing to the proxy machine) and not back to eth1 so > it can reach the machine that made the request. > > When I apply the shorewall iptables rules only and configure ip > forwarding and policy routing to the proxy by hand everything works > fine. > > So, I still think that the problem is on some configuration on the > firewall itself, even more on the kernel parameters. > > Any help?.Please capture the output of ''shorewall dump'' when it is working (by hand configuration) and when it is not working (shorewall start) and forward both. -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 \________________________________________________ ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On Tue, Apr 30, 2013 at 5:58 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 04/30/2013 01:48 PM, Ernesto Domato wrote: >> Ok, I''m still trying to solve my problem :-) >> >> The firewall machine has this interfaces: >> >> eth0 -> link to the internet >> eth1 -> link to the local network >> ovsbr0 -> OpenVSwitch connected to virtual machines (the Squid proxy server) >> >> Now, when I apply the full Shorewall rules (through "shorewall start") >> and do a tcpdump on eth1 and ovsbr0 I see syn packets going through >> ovsbr0 and syn reply packet coming back. But on the eth1 I just see >> the syn packet going in just one direction (the remote one that is >> routed by policy routing to the proxy machine) and not back to eth1 so >> it can reach the machine that made the request. >> >> When I apply the shorewall iptables rules only and configure ip >> forwarding and policy routing to the proxy by hand everything works >> fine. >> >> So, I still think that the problem is on some configuration on the >> firewall itself, even more on the kernel parameters. >> >> Any help?. > > Please capture the output of ''shorewall dump'' when it is working (by > hand configuration) and when it is not working (shorewall start) and > forward both. >Ok, here we go. Let me know what do you think? :-) Thanks. Ernesto ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On 05/02/2013 05:40 AM, Ernesto Domato wrote:> On Tue, Apr 30, 2013 at 5:58 PM, Tom Eastep <teastep@shorewall.net> wrote: >> On 04/30/2013 01:48 PM, Ernesto Domato wrote: >>> Ok, I''m still trying to solve my problem :-) >>> >>> The firewall machine has this interfaces: >>> >>> eth0 -> link to the internet >>> eth1 -> link to the local network >>> ovsbr0 -> OpenVSwitch connected to virtual machines (the Squid proxy server) >>> >>> Now, when I apply the full Shorewall rules (through "shorewall start") >>> and do a tcpdump on eth1 and ovsbr0 I see syn packets going through >>> ovsbr0 and syn reply packet coming back. But on the eth1 I just see >>> the syn packet going in just one direction (the remote one that is >>> routed by policy routing to the proxy machine) and not back to eth1 so >>> it can reach the machine that made the request. >>> >>> When I apply the shorewall iptables rules only and configure ip >>> forwarding and policy routing to the proxy by hand everything works >>> fine. >>> >>> So, I still think that the problem is on some configuration on the >>> firewall itself, even more on the kernel parameters. >>> >>> Any help?. >> >> Please capture the output of ''shorewall dump'' when it is working (by >> hand configuration) and when it is not working (shorewall start) and >> forward both. >> > > Ok, here we go. Let me know what do you think? :-) >Try setting ROUTE_FILTER=No in shorewall.conf and reboot. Does the Shorewall-generated configuration work now? Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On Thu, May 2, 2013 at 11:47 AM, Tom Eastep <teastep@shorewall.net> wrote:> Try setting ROUTE_FILTER=No in shorewall.conf and reboot. Does the > Shorewall-generated configuration work now? >YES, it does :-) So, can you briefly explain what happended? Thanks a lot. Ernesto ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On 05/02/2013 08:23 AM, Ernesto Domato wrote:> On Thu, May 2, 2013 at 11:47 AM, Tom Eastep <teastep@shorewall.net> wrote: >> Try setting ROUTE_FILTER=No in shorewall.conf and reboot. Does the >> Shorewall-generated configuration work now? >> > > YES, it does :-) > > So, can you briefly explain what happended? >I noticed in the non-working dump that the rp_filter flag was set on vnet0. While that should not matter, it was the only thing that I could see that might affect the outcome. You might try setting ROUTE_FILTER=Yes, and add these commands in /etc/shorewall/start: echo 0 > /proc/sys/net/ipv4/conf/vnet0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/vnet0/log_martians Does that also solve the problem? Thanks, -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 \________________________________________________ ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On Thu, May 2, 2013 at 12:31 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 05/02/2013 08:23 AM, Ernesto Domato wrote: >> On Thu, May 2, 2013 at 11:47 AM, Tom Eastep <teastep@shorewall.net> wrote: >>> Try setting ROUTE_FILTER=No in shorewall.conf and reboot. Does the >>> Shorewall-generated configuration work now? >>> >> >> YES, it does :-) >> >> So, can you briefly explain what happended? >> > > I noticed in the non-working dump that the rp_filter flag was set on > vnet0. While that should not matter, it was the only thing that I could > see that might affect the outcome. > > You might try setting ROUTE_FILTER=Yes, and add these commands in > /etc/shorewall/start: > > echo 0 > /proc/sys/net/ipv4/conf/vnet0/rp_filter > echo 0 > /proc/sys/net/ipv4/conf/vnet0/log_martians > > Does that also solve the problem? >No, it doesn''t. And I also added this lines for all the interfaces but the behavior remains, it doesn''t work. So, what does ROUTE_FILTER change?, I don''t want to look on the entire script. On the other hand, I would like to keep the anti-spoofing behavior with ROUTE_FILTER=Yes Thanks. Ernesto ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On 5/2/13 9:32 AM, "Ernesto Domato" <edomat@gmail.com> wrote:>No, it doesn''t. And I also added this lines for all the interfaces but >the behavior remains, it doesn''t work. > >So, what does ROUTE_FILTER change?, I don''t want to look on the entire >script. > >On the other hand, I would like to keep the anti-spoofing behavior >with ROUTE_FILTER=YesSet ROUTE_FILTER=No and in /etc/shorewall/interfaces, set routefilter and logmartians in the entry for eth0. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
On Thu, May 2, 2013 at 1:48 PM, Tom Eastep <teastep@shorewall.net> wrote:> On 5/2/13 9:32 AM, "Ernesto Domato" <edomat@gmail.com> wrote: >>On the other hand, I would like to keep the anti-spoofing behavior >>with ROUTE_FILTER=Yes > > Set ROUTE_FILTER=No and in /etc/shorewall/interfaces, set routefilter and > logmartians in the entry for eth0. >Ok, perfect. Thanks a lot. ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1