Hello all, I''m somewhat new to networking, and I''m having trouble masquerading connections that are coming over a bridge. The bridge only has a single port for now, but I''m going to add more ports later. I''m basing my configuration on the two-interface quick start guide. I''m using Shorewall 3.0.4 on Ubuntu Dapper. My network looks like this: * The firewall with eth0, eth1 and ppp0 - eth0 is part of the bridge lan0 - lan0 (the bridge) has IP 192.168.1.2 - eth1 is unused. - ppp0 is a PPPoE connection to the Internet over lan0 to a DSL modem * One DSL modem accessible over lan0 with IP address 192.168.1.1 * One laptop accessible over lan0 with IP address 192.168.1.3 My goal is to have the laptop access the Internet through the firewall Initially I set up Shorewall with eth0 as the internal interface and everything worked fine. Then I set up the bridge lan0, and added eth0 as a port. Then I changed /etc/shorewall/interfaces to use lan0 instead of eth0, and added the routeback option. After this, pinging works fine within the network, but I''m not able to access the Internet from the laptop. Internet access from the firewall itself works fine. Firestarter, which I used earlier, is working fine in the same configuration (Internal interface: lan0, external: ppp0). /etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS net ppp0 - tcpflags,norfc1918,routefilter,nosmurfs,logmartians loc lan0 192.168.1.255 routeback,dhcp,tcpflags,detectnets,nosmurfs #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE /etc/shorewall/policy: #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc net ACCEPT $FW net ACCEPT net all DROP info $FW loc ACCEPT loc $FW ACCEPT # THE FOLLOWING POLICY MUST BE LAST all all REJECT info #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE /etc/shorewall/masq: #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC ppp0 192.168.1.0/24 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE My /etc/shorewall/rules file is unchanged from the default in the two-interface guide. My /etc/shorewall/shorewall.conf file is unchanged except for setting IP_FORWARDING=On With these settings, after doing a "shorewall start", I am unable to ping any website from my laptop. Name resolution is working fine on the laptop since I''m running dnsmasq as a caching nameserver on the firewall, so LAN clients don''t have to access the Internet for DNS. The funny thing is that I can get Internet access on the laptop by doing: shorewall clear sudo iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j MASQUERADE I''ve attached a shorewall dump of this (see below) Such a rule is generated by shorewall, as you can see in the shorewall dump I''m attaching, and no other rule is blocking access. I don''t see therefore why a shorewall clear fixes the problem. Another symptom is that attempts to connect to the internet from within the LAN don''t produce any output in /var/log/kern.log, while random incoming packets on ppp0 are logged. The most puzzling thing of all is that I can get everything to work right by setting up eth0 as an interface, removing the bridge lan0, and changing /etc/shorewall/interfaces to eth0, without making any other changes. I wasn''t aware there was actually any difference logically between single-port bridges and normal interfaces, but switching from one to the other fixes the problem. Any help will be appreciated. I''m attaching three gzipped files: 1. dump-bad.gz - the shorewall dump in the non-working state, with shorewall started 2. dump-cleared.gz - dump produced after doing a shorewall clear and inserting the iptables masquerade rule manually (as described above) 3. dump-firestarter.gz - dump produced after clearing shorewall and starting firestarter (works perfectly) Thanks in advance, Roshan Shariff
On Tuesday 04 April 2006 16:39, Roshan Shariff wrote:> Any help will be appreciated. I''m attaching three gzipped files: > 1. dump-bad.gz - the shorewall dump in the non-working state, with > shorewall startedWhich is not particularly useful since you didn''t try to pass one single packet through the firewall (all packet counts are zero). I need to see a dump *after you have tried the connection that failed* as detailed at http://www.shorewall.net/support.htm. In your case, that means that I need to see what the dump looks like after you have tried to access the internet from a local system. I can''t see anything wrong with the MASQUERADE setup just looking at the static ruleset. -Tm -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On 4/5/06, Tom Eastep <teastep@shorewall.net> wrote:> Which is not particularly useful since you didn''t try to pass one single > packet through the firewall (all packet counts are zero). I need to see a > dump *after you have tried the connection that failed* as detailed atI''m sorry Tom, it was a stupid mistake. I''m sending another dump, this time taken after trying to ping www.google.com and access it with a browser, from the laptop. Thanks for the quick response. Roshan Shariff
On Tuesday 04 April 2006 18:08, Roshan Shariff wrote:> On 4/5/06, Tom Eastep <teastep@shorewall.net> wrote: > > Which is not particularly useful since you didn''t try to pass one single > > packet through the firewall (all packet counts are zero). I need to see a > > dump *after you have tried the connection that failed* as detailed at > > I''m sorry Tom, it was a stupid mistake. I''m sending another dump, this > time taken after trying to ping www.google.com and access it with a > browser, from the laptop. > > Thanks for the quick response.Roshan, I''m sorry to say that I have no clue what the problem is. 1) The MASQUERADE rule appears to be working: Chain ppp0_masq (1 references) pkts bytes target prot opt in out source destination 2 144 MASQUERADE all -- * * 192.168.1.0/24 0.0.0.0/0 2) The SYN packet is being sent, apparently with the correct addresses but is not being replied to: tcp 6 91 SYN_SENT src=192.168.1.3 dst=66.249.89.99 sport=2280 dport=80 packets=2 bytes=120 [UNREPLIED] src=66.249.89.99 dst=203.101.1.216 sport=80 dport=2280 packets=0 bytes=0 mark=0 use=1 I guess that the next thing to do is to: a) Start Shorewall b) tcpdump -nvvi ppp0 port 80 c) Try to browse www.google.com I''m particularly interested to see if tcpdump reports checksum errors. The only apparent differences between the Firestarter configuration and the Shorewall configuration WRT Masquerade are: 1) Shorewall''s MASQUERADE rule is in a user chain in the nat table whereas the Firestarter rule is in POSTROUTING. 2) Shorewall''s rule is restricted to packets with a source address in 192.168.1.0/24 (because of your ''detectnets'' specification in the interfaces file) whereas Firestarter''s rule include all source addresses. Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Dear Mr. Eastep, I spent the whole of last night trying to fix this problem, and my consolation is that at least it isn''t a trivial problem. I tried various things to diagnose it: First, to make sure that none of the settings in /proc/sys/net/ were causing the problem, I did for i in `find /proc/sys/net -type f`; do echo $i = `cat $i`; done > output.txt (this is the most complicated shell command I''ve written so far ;-)) for both firestarter and shorewall. I then diff''d the files and the only difference was that rp_filter was enabled on each interface in firestarter and only the ''all'' directory in shorewall. Thinking this had nothing to do with the problem, I nevertheless manually enabled rp_filter on each interface. It still didn''t work. Then I saved copies of the shorewall iptables and the firestarter iptables with iptables-save and ip6tables-save (even though I don''t use IPv6.) I then started shorewall and restored the firestarter iptables with iptables-restore. It still didn''t work. So I thought the problem must be somewhere outside iptables. However, when I tried restoring the firestarter ipv6 tables with ip6tables-restore, it suddenly started working. The firestarter ip6tables policy is ''accept'' in the input, output, and forward chains. In shorewall, with DISABLE_IPV6=Yes in shorewall.conf, the default policy is ''drop'' (with a specific rule to allow loopback) So now I can confirm that doing "ip6tables -P FORWARD ACCEPT" on a shorewall firewall makes it work properly and conversely "ip6tables -P FORWARD DROP" on a firestarter firewall stops it from working. So now, setting DISABLE_IPV6=No in shorewall.conf fixes the problem. I had tried that earlier, but it didn''t work because shorewall doesn''t actually enable IPv6, it just leaves it as is. So setting it to Off and restarting shorewall doesn''t fix the problem, because it was On earlier. However when starting shorewall on a clean iptables, it works fine. I can''t imagine what IPv6 has to do with my setup, since I''m not trying to contact an IPv6 address, just a normal IPv4 one. I''m also not sure what security holes it opens, since shorewall.conf says that people could bypass the firewall if IPv6 is enabled. I would be grateful if you could clarify exactly what is happening here. Is there something wrong with the way IPv6 is set up by default in Ubuntu? Should I open a bug on the Ubuntu bugtracker? I''m somewhat bitter at the moment, because the first supposed ''benefit'' that IPv6 has brought me is a sleepless night. On 4/5/06, Tom Eastep <teastep@shorewall.net> wrote:> I guess that the next thing to do is to: > > a) Start Shorewall > b) tcpdump -nvvi ppp0 port 80 > c) Try to browse www.google.com > > I''m particularly interested to see if tcpdump reports checksum errors.I''m attaching tcpdumps of both the non-working firewall (DISABLE_IPV6=Yes) and the working firewall (DISABLE_IPV6=Off and a fresh iptables) Thanks Roshan
Roshan Shariff wrote:> Dear Mr. Eastep, > > I spent the whole of last night trying to fix this problem, and my > consolation is that at least it isn''t a trivial problem. I tried > various things to diagnose it: > > First, to make sure that none of the settings in /proc/sys/net/ were > causing the problem, I did > for i in `find /proc/sys/net -type f`; do echo $i = `cat $i`; done > output.txt > (this is the most complicated shell command I''ve written so far ;-)) > for both firestarter and shorewall. I then diff''d the files and the > only difference was that rp_filter was enabled on each interface in > firestarter and only the ''all'' directory in shorewall. Thinking this > had nothing to do with the problem, I nevertheless manually enabled > rp_filter on each interface. It still didn''t work. > > Then I saved copies of the shorewall iptables and the firestarter > iptables with iptables-save and ip6tables-save (even though I don''t > use IPv6.) I then started shorewall and restored the firestarter > iptables with iptables-restore. It still didn''t work. So I thought the > problem must be somewhere outside iptables. > > However, when I tried restoring the firestarter ipv6 tables with > ip6tables-restore, it suddenly started working. The firestarter > ip6tables policy is ''accept'' in the input, output, and forward chains. > In shorewall, with DISABLE_IPV6=Yes in shorewall.conf, the default > policy is ''drop'' (with a specific rule to allow loopback) > > So now I can confirm that doing "ip6tables -P FORWARD ACCEPT" on a > shorewall firewall makes it work properly and conversely "ip6tables -P > FORWARD DROP" > on a firestarter firewall stops it from working. > > So now, setting DISABLE_IPV6=No in shorewall.conf fixes the problem. I > had tried that earlier, but it didn''t work because shorewall doesn''t > actually enable IPv6, it just leaves it as is. So setting it to Off > and restarting shorewall doesn''t fix the problem, because it was On > earlier. However when starting shorewall on a clean iptables, it works > fine. > > I can''t imagine what IPv6 has to do with my setup, since I''m not > trying to contact an IPv6 address, just a normal IPv4 one. I''m also > not sure what security holes it opens, since shorewall.conf says that > people could bypass the firewall if IPv6 is enabled. I would be > grateful if you could clarify exactly what is happening here. Is there > something wrong with the way IPv6 is set up by default in Ubuntu? > Should I open a bug on the Ubuntu bugtracker? >What a great peace of detective work on your part. I noticed that your running a 2.6.15 kernel, if I recall correctly, netfilter received a major overhaul, in the 2.6.15 version. Are you able to boot an older 2.6.14 kernel? Just to see if the same behavior is present or not with the older kernel, that would help narrow down the cause of your issue. I''m not sure if this is a Ubuntu, kernel, or a ip6 issue at this point. I''d open a bugtrack, if you block all ip6 access, that should not have any impact on your ip4 traffic. Having ip6 ''open'' just to have ip4 filtering work is not my idea of packet filtering.> I''m somewhat bitter at the moment, because the first supposed > ''benefit'' that IPv6 has brought me is a sleepless night. >Nod.... Sleep and IT sometimes don''t play nice together.... ;-) Sorry, off the top of my head I don''t have the silver bullet to slay this problem. Good luck, Jerry ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Wednesday 05 April 2006 07:31, Jerry Vonau wrote:> Roshan Shariff wrote: > > > > I can''t imagine what IPv6 has to do with my setup, since I''m not > > trying to contact an IPv6 address, just a normal IPv4 one. I''m also > > not sure what security holes it opens, since shorewall.conf says that > > people could bypass the firewall if IPv6 is enabled. I would be > > grateful if you could clarify exactly what is happening here. Is there > > something wrong with the way IPv6 is set up by default in Ubuntu? > > Should I open a bug on the Ubuntu bugtracker? > > What a great peace of detective work on your part.Ditto!> I noticed that your > running a 2.6.15 kernel, if I recall correctly, netfilter received a > major overhaul, in the 2.6.15 version. Are you able to boot an older > 2.6.14 kernel? Just to see if the same behavior is present or not with > the older kernel, that would help narrow down the cause of your issue. > I''m not sure if this is a Ubuntu, kernel, or a ip6 issue at this point. > > I''d open a bugtrack, if you block all ip6 access, that should not have > any impact on your ip4 traffic. Having ip6 ''open'' just to have ip4 > filtering work is not my idea of packet filtering.I agree. When you have IPv6 support in your kernel, the IPv4 packet filter that Shorewall configures doesn''t handle any IPv6 traffic; if you set DISABLE_IPV6=No, then your router is completely open to IPv6 traffic.> > > I''m somewhat bitter at the moment, because the first supposed > > ''benefit'' that IPv6 has brought me is a sleepless night. >-Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Hello Tom & Jerry [leaving that in for comic effect :-)] I''ve filed bug #38288 on Malone (the Ubuntu bugtracker). It''s available at https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/38288 I''d appreciate it if you could take a look and see if I''ve made any mistakes in describing the problem. On 4/5/06, Tom Eastep <teastep@shorewall.net> wrote:> On Wednesday 05 April 2006 07:31, Jerry Vonau wrote: > > I noticed that your > > running a 2.6.15 kernel, if I recall correctly, netfilter received a > > major overhaul, in the 2.6.15 version. Are you able to boot an older > > 2.6.14 kernel? Just to see if the same behavior is present or not with > > the older kernel, that would help narrow down the cause of your issue. > > I''m not sure if this is a Ubuntu, kernel, or a ip6 issue at this point.I''ve never compiled a kernel myself. I know how to do it in theory, but I''ve never actually done it. Apart from this, 2.6.14 is not in the Ubuntu repositories, so I''ll have to download the vanilla kernel from www.kernel.org and compile that. I could learn how to compile a kernel (I''ve already learned a lot in the course of identifying this bug) but I don''t have time right now. I''ve just finished high school and have to prepare for various college entrance exams. This is a critical time in the Indian educational system. However, I did try it out in Linux 2.6.12 (which was present on Ubuntu Breezy.) The same bug exists there. So it''s either a bug in the kernel or in Ubuntu-applied patches; this unlikely since I can''t think of a reason for the Ubuntu devs to modify networking-related code. I tried to check if the problem had been solved in 2.6.16. If you see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16 and search for "[NETFILTER]: Fix bridge netfilter related in xfrm_lookup" that could be the problem. Also see "[NETFILTER]: Fix xfrm lookup after SNAT". I''m not sure about the latter since it only applies to non-unicast packets. I think the fact that this only affects bridge interfaces narrows down the domain considerably. Anyway, the time I spent will at least be useful if I end up uncovering a kernel bug that''s been there since at least 2.6.12. It''s probably not that though, since my setup is pretty common (exactly the same as http://www.shorewall.net/SimpleBridge.html) and it''s unlikely nobody has run into this bug before. Thanks for all your help. This is the first time I''ve ever written to a mailing list for help with something and I am delighted with the response. I''m going to offer this as a counter-example to anyone who says that proprietary software is better supported than Free Software. Roshan Shariff ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Hiya As I noticed today, changing IP_FORWARDING from =keep to =on is essential for NAT to work properly. Is it possible to put this or in a install daemon or on =on by default? It would save everybody lots of TS time. Also, I would be happy to provide you with a check for a previous installation script, check for example the IP_FORWARDING= setting. Rouke ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Wednesday 05 April 2006 16:34, Rouke de Jong wrote:> Hiya > > As I noticed today, changing IP_FORWARDING from =keep to =on is essential > for NAT to work properly. Is it possible to put this or in a install daemon > or on =on by default?You must be running Debian -- IP_FORWARDING=On in the code that I release and the Debian maintainer changes it to keep (as described in the Shorewall README.Debian). This is also mentioned prominently in both the two- and three-interface QuickStart Guides. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
On Wednesday 05 April 2006 15:26, Roshan Shariff wrote:> > I''ve filed bug #38288 on Malone (the Ubuntu bugtracker). It''s > available at > https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/38288 > > I''d appreciate it if you could take a look and see if I''ve made any > mistakes in describing the problem.Looks fine to me.> > Thanks for all your help. This is the first time I''ve ever written to > a mailing list for help with something and I am delighted with the > response. I''m going to offer this as a counter-example to anyone who > says that proprietary software is better supported than Free Software.Thanks for the kind words, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Roshan Shariff wrote:> Hello Tom & Jerry > > [leaving that in for comic effect :-)] >I don''t mind... :-)> I''ve filed bug #38288 on Malone (the Ubuntu bugtracker). It''s > available at https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/38288 > > I''d appreciate it if you could take a look and see if I''ve made any > mistakes in describing the problem. >Looks good.> On 4/5/06, Tom Eastep <teastep@shorewall.net> wrote: >> On Wednesday 05 April 2006 07:31, Jerry Vonau wrote: >>> I noticed that your >>> running a 2.6.15 kernel, if I recall correctly, netfilter received a >>> major overhaul, in the 2.6.15 version. Are you able to boot an older >>> 2.6.14 kernel? Just to see if the same behavior is present or not with >>> the older kernel, that would help narrow down the cause of your issue. >>> I''m not sure if this is a Ubuntu, kernel, or a ip6 issue at this point. > > I''ve never compiled a kernel myself. I know how to do it in theory, > but I''ve never actually done it. Apart from this, 2.6.14 is not in the > Ubuntu repositories, so I''ll have to download the vanilla kernel from > www.kernel.org and compile that. >I don''t like to compile kernels, takes way too long on my 450 (Yes PII).> I could learn how to compile a kernel (I''ve already learned a lot in > the course of identifying this bug) but I don''t have time right now. > I''ve just finished high school and have to prepare for various college > entrance exams. This is a critical time in the Indian educational > system. >All the best in your exams.> However, I did try it out in Linux 2.6.12 (which was present on Ubuntu > Breezy.) The same bug exists there. So it''s either a bug in the kernel > or in Ubuntu-applied patches; this unlikely since I can''t think of a > reason for the Ubuntu devs to modify networking-related code. >Maybe you tried a version of 2.6.12 with the bridge-bug still unresolved Think that came across the mailing list at one point... Yes, in June/05, thought that bug was fixed. I don''t have the time right now to mock up a bridge environment, maybe next week. Anybody out there running a bridge with a kernel < 2.6.13 ?> I tried to check if the problem had been solved in 2.6.16. If you see > http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.16 and > search for "[NETFILTER]: Fix bridge netfilter related in xfrm_lookup" > that could be the problem. Also see "[NETFILTER]: Fix xfrm lookup > after SNAT". I''m not sure about the latter since it only applies to > non-unicast packets. > > I think the fact that this only affects bridge interfaces narrows down > the domain considerably. > > Anyway, the time I spent will at least be useful if I end up > uncovering a kernel bug that''s been there since at least 2.6.12. It''s > probably not that though, since my setup is pretty common (exactly the > same as http://www.shorewall.net/SimpleBridge.html) and it''s unlikely > nobody has run into this bug before. >See above.. I''m thinking that a bridge may now need to use the physdev module in netfilter, but I could be wrong. Perhaps you could try using the hosts file in shorewall with your bridge as in: http://www.shorewall.net/bridge.html, that will cause shorewall to invoke the physdev support in netfilter. Not sure if it will help at all, but that is quick to try.> Thanks for all your help. This is the first time I''ve ever written to > a mailing list for help with something and I am delighted with the > response. I''m going to offer this as a counter-example to anyone who > says that proprietary software is better supported than Free Software. >Thanks for the kind words and all your time that you put into debugging your own problem. Your own problem solving skills and effort is what lead you to the source of your problem. Great job, Jerry ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Heh, That explains it all :) I think a was in bit too much of a hurry then. Thanks! Also, just on the side as I noticed yesterday, is there a maximum size on the config files? Because as soon as I added another rule in "rules" Shorewall check gave me errors, removing the top line from the explanation fixed it, adding extra lines, even with only hashes made Shorewall check end with an error. Rouke -----Oorspronkelijk bericht----- Van: shorewall-users-admin@lists.sourceforge.net [mailto:shorewall-users-admin@lists.sourceforge.net] Namens Tom Eastep Verzonden: donderdag 6 april 2006 1:43 Aan: shorewall-users@lists.sourceforge.net Onderwerp: Re: [Shorewall-users] IP_FORWARDING=On essential with NAT-ting On Wednesday 05 April 2006 16:34, Rouke de Jong wrote:> Hiya > > As I noticed today, changing IP_FORWARDING from =keep to =on is essential > for NAT to work properly. Is it possible to put this or in a installdaemon> or on =on by default?You must be running Debian -- IP_FORWARDING=On in the code that I release and the Debian maintainer changes it to keep (as described in the Shorewall README.Debian). This is also mentioned prominently in both the two- and three-interface QuickStart Guides. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
On Thursday 06 April 2006 00:34, Rouke de Jong wrote:> Heh, > > That explains it all :) I think a was in bit too much of a hurry then. > Thanks! Also, just on the side as I noticed yesterday, is there a maximum > size on the config files? Because as soon as I added another rule in > "rules" Shorewall check gave me errors, removing the top line from the > explanation fixed it, adding extra lines, even with only hashes made > Shorewall check end with an error.There is no pre-defined limit. see http://www.shorewall.net/troubleshoot.htm for instructions about troubleshooting "shorewall start/check/restart" errors. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key
Tom Eastep wrote:> On Wednesday 05 April 2006 07:31, Jerry Vonau wrote: >> Roshan Shariff wrote: >>> I can''t imagine what IPv6 has to do with my setup, since I''m not >>> trying to contact an IPv6 address, just a normal IPv4 one. I''m also >>> not sure what security holes it opens, since shorewall.conf says that >>> people could bypass the firewall if IPv6 is enabled. I would be >>> grateful if you could clarify exactly what is happening here. Is there >>> something wrong with the way IPv6 is set up by default in Ubuntu? >>> Should I open a bug on the Ubuntu bugtracker? >> What a great peace of detective work on your part. > > Ditto! > >> I noticed that your >> running a 2.6.15 kernel, if I recall correctly, netfilter received a >> major overhaul, in the 2.6.15 version. Are you able to boot an older >> 2.6.14 kernel? Just to see if the same behavior is present or not with >> the older kernel, that would help narrow down the cause of your issue. >> I''m not sure if this is a Ubuntu, kernel, or a ip6 issue at this point. >> >> I''d open a bugtrack, if you block all ip6 access, that should not have >> any impact on your ip4 traffic. Having ip6 ''open'' just to have ip4 >> filtering work is not my idea of packet filtering. > > I agree. When you have IPv6 support in your kernel, the IPv4 packet filter > that Shorewall configures doesn''t handle any IPv6 traffic; if you set > DISABLE_IPV6=No, then your router is completely open to IPv6 traffic. >Roshan Shariff: I had a thought, a bit late, but this might help. You can disable ipv6 altogether, I did that awhile ago, forgot about it, and how I did it... I have these two entries in my modprobe.conf file: alias net-pf-10 off alias ipv6 off Not sure what the equivalent file to modprobe.conf is on your distro, but adding those entries, and a reboot should disable ipv6. Hope it helps someone, Jerry ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642