I have been using shorewall and freeswan successfully for 3 or more years now. But they have all been using the Linux 2.4 kernel. My current configuration is (as the title suggests) using SuSE 9.1 which has a 2.6.5 kernel and freeswan 2.0.4 built-in. After much reading and a lot of trial and error, I did get this combination to work with Shorewall 2.0.9. It is happily talking to an older Mandrake 9.1 system with freeswan 1.99 and shorewall 1.3.14. But I am unsure of a couple of configuration choices I made and am wondering if I have opened myself up for any kinds of attack. The first thing I noticed is that with the 2.6 kernel, the ipsec0 device is gone. Both the VPN traffic and "wild internet" traffic come in as from eth1 (my external interface). This mirrors reality of course but makes it more difficult to discern the two types of traffic. After following the directions in the shorewall configuration guide, I was still plagued by a problem. From the SuSE system, I was able to access the subnets on the Mandrake system with no trouble. But attempting to access the SuSE 9.1 system from the Mandrake system caused a bunch of rfc1918 errors on eth1. The traffic was showing up as coming FROM my local 192.168.xxx.xxx subnet on the Mandrake side with a target of a 192.168.yyy.yyy on the SuSE side. I put the norfc1918 option in both the interface definition for eth1 and in the hosts definition for the vpn but this did not stop the rfc1918 rejections. I ended up having to add a RETURN entry to a local copy of the rfc1918 file for the local subnet on the SuSE side. So my questions are (1) was there some other place that norfc1918 needed to be specified as the extra step I took was not mentioned in the shorewall documentation (or is this a bug in shorewall or just a currently undocumented step) and (2) does allowing specific subnet rfc1918 entries through create any hole I should worry about. I do have routefilter turned on for the eth1 interface so that is supposed to prevent some level of spoofing. I did some searches of the archives before posting here but haven''t found anything relevant. Thanks for your time. SE
Hi Steve, I configured sucessfully a SuSE 9.1 System with freeswan and openswan packages. (not at the same time of course :-) ) First of all you need the development version of Shorewall to support native IPSEC (no ipsecN interfaces anymore). Also read the documentation about this written by Tom. see http://www.shorewall.net/IPSEC-2.6.html Also take a look at this page, it´s the private page of a SuSE member, he´s the responsible packager for the ipsec stuff and offers updated packages here: http://www.suse.de/~garloff/linux/FreeSWAN/ If you have further questions, just ask. Alex ----- Original Message ----- From: "Steve Estes" <gribnick@email.com> To: "Shorewall List" <shorewall-users@lists.shorewall.net> Sent: Wednesday, October 20, 2004 7:00 AM Subject: [Shorewall-users] Shorewall, Freeswan and SuSE 9.1> I have been using shorewall and freeswan successfully for 3 or more > years now. But they have all been using the Linux 2.4 kernel. My current > configuration is (as the title suggests) using SuSE 9.1 which has a > 2.6.5 kernel and freeswan 2.0.4 built-in. > > After much reading and a lot of trial and error, I did get this > combination to work with Shorewall 2.0.9. It is happily talking to an > older Mandrake 9.1 system with freeswan 1.99 and shorewall 1.3.14. But I > am unsure of a couple of configuration choices I made and am wondering > if I have opened myself up for any kinds of attack. > > The first thing I noticed is that with the 2.6 kernel, the ipsec0 device > is gone. Both the VPN traffic and "wild internet" traffic come in as > from eth1 (my external interface). This mirrors reality of course but > makes it more difficult to discern the two types of traffic. After > following the directions in the shorewall configuration guide, I was > still plagued by a problem. From the SuSE system, I was able to access > the subnets on the Mandrake system with no trouble. But attempting to > access the SuSE 9.1 system from the Mandrake system caused a bunch of > rfc1918 errors on eth1. The traffic was showing up as coming FROM my > local 192.168.xxx.xxx subnet on the Mandrake side with a target of a > 192.168.yyy.yyy on the SuSE side. I put the norfc1918 option in both the > interface definition for eth1 and in the hosts definition for the vpn > but this did not stop the rfc1918 rejections. I ended up having to add a > RETURN entry to a local copy of the rfc1918 file for the local subnet on > the SuSE side. > > So my questions are (1) was there some other place that norfc1918 needed > to be specified as the extra step I took was not mentioned in the > shorewall documentation (or is this a bug in shorewall or just a > currently undocumented step) and (2) does allowing specific subnet > rfc1918 entries through create any hole I should worry about. I do have > routefilter turned on for the eth1 interface so that is supposed to > prevent some level of spoofing. I did some searches of the archives > before posting here but haven''t found anything relevant. > > Thanks for your time. > > SE > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe:https://lists.shorewall.net/mailman/listinfo/shorewall-users> Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm >
Steve Estes wrote:> I have been using shorewall and freeswan successfully for 3 or more > years now. But they have all been using the Linux 2.4 kernel. My current > configuration is (as the title suggests) using SuSE 9.1 which has a > 2.6.5 kernel and freeswan 2.0.4 built-in.Go and download shorewall development (2.1.9). The ipsec interface is gone but SuSE 9.1 - at least if correctly updated - contains everything to use shorewall with the new ipsec features described in http://www.shorewall.net/IPSEC-2.6.html. I switched my system to shorewall development in 15 minutes and I''m using 2 tunnels to the dmz and the local net of my company from home. I''m using the built in freeswan, not kame/racoon as descibed in the above document. For your net - net tunnel the example "IPSec Gateway on the Firewall System" matches. Afterwards you can add your rfc1918 flag again on your interface.> > Thanks for your time. >-- __________________________________________________ Ralf Schenk fon (02 41) 9 91 21-0 fax (02 41) 9 91 21-59 rs@databay.de Databay AG Hüttenstraße 7 D-52068 Aachen www.databay.de Databay - einfach machen. _________________________________________________ Diese E-Mail und etwa angehängte Dateien enthalten vertrauliche Informationen und sind ausschließlich für den Adressaten bestimmt. Sollten Sie irrtümlich diese E-Mail erhalten haben, bitten wir Sie, uns darüber unter info@databay.de zu informieren und die E-Mail aus Ihrem System zu löschen. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify info@databay.de. If you are not the named recipient, you should return this message and delete it from your system.
Thanks for the replies Ralf and Alex, I have made the conversion from Shorewall 2.0.9 to 2.1.11 and as was mentioned, I can now run norfc1918 again but I do not have proper connectivity yet. It seems the proper association between the encrypted traffic and the vpn zone is not being created correctly. I''ve probably read the ipsec sections a dozen times but have yet to hit on a combination that works. Just to review since it has been a few days: Node A Suse 9.1 with the latest kernel and patches (2.6.5-111), shorewall 2.1.11, Freeswan 2.0.4. Node B Mandrake 9.1 w/2.4.21 kernel (last of the 9.x where builtin freeswan worked), shorewall 1.1.13, Freeswan 1.98b. I define 4 tunnels for complete gateway/subnet interconnects. The tunnels connect and I can see they are active. I have full access to NodeB from NodeA. However, when I try to access Subnet A from either GatewayB or SubnetB, I get net2all reject messages. Below is a sample message and the major settings I am using. This particular message is for a ping but the same thing happens for any other communication I attempt as well. The commented out settings represent things I have tried but I did not get to work. Note that in this config, eth1 is my external interface and eth0 is my internal interface which is different from Tom''s examples. I did not include the policy or rules file as they don''t seem to be having any effect on the result either. There are policies and rules for vpn->loc and loc->vpn but I don''t appear to be getting that far since this thinks it is in the net zone. Hoping someone has some words of wisdom.. Thanks all.. Steve ----------------------------------------- Oct 24 00:42:41 tnode1 kernel: Shorewall:net2all:DROP:IN=eth1 OUT=eth0 SRC=192.168.subnetB.x DST=192.168.subnetA.y LEN=84 TOS=0x00 PREC=0x00 TTL=62 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=55838 SEQ=1 params file: SUBNETA=192.168.subnetA.0/24 SUBNETB=192.168.subnetB.0/24 IPA=a.a.a.a IPB=b.b.b.b hosts file: #ZONE HOST(S) OPTIONS #vpn eth1:0.0.0.0/0 #vpn eth1:$SUBNETB,$IPB vpn eth1:$SUBNETB,$IPB ipsec #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE interfaces file: #ZONE INTERFACE BROADCAST OPTIONS net eth1 detect dhcp,routefilter,tcpflags,nosmurfs,nobogons,norfc1918 loc eth0 detect # #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE ipsec file: #ZONE IPSEC OPTIONS IN OUT # ONLY OPTIONS OPTIONS vpn Yes #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE masq file: #INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC #eth1:!$SUBNETB $SUBNETA #eth1 eth0 eth1 $SUBNETA #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE tunnels file: # TYPE ZONE GATEWAY GATEWAY # ZONE ipsec net $IPB #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE zones file: #ZONE DISPLAY COMMENTS vpn VPN FreeS/WAN Tunnel net Net Internet loc Local Local networks #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE On Wed, 2004-10-20 at 05:26, Ralf Schenk wrote:> Steve Estes wrote: > > I have been using shorewall and freeswan successfully for 3 or more > > years now. But they have all been using the Linux 2.4 kernel. My current > > configuration is (as the title suggests) using SuSE 9.1 which has a > > 2.6.5 kernel and freeswan 2.0.4 built-in. > > Go and download shorewall development (2.1.9). The ipsec interface is > gone but SuSE 9.1 - at least if correctly updated - contains everything > to use shorewall with the new ipsec features described in > http://www.shorewall.net/IPSEC-2.6.html. > > I switched my system to shorewall development in 15 minutes and I''m > using 2 tunnels to the dmz and the local net of my company from home. > I''m using the built in freeswan, not kame/racoon as descibed in the > above document. > > For your net - net tunnel the example "IPSec Gateway on the Firewall > System" matches. Afterwards you can add your rfc1918 flag again on your > interface. > > > > > Thanks for your time. > >
Hi Steve, seems that I have the same problem. :-( I didn´t mention it before, because I´m using only connections initiated from 2.6 kernel shorewall here to the remote 2.4 kernel shorewall. If I have time today I´ll try to find out why this traffic isn´t associated correctly. Alex Steve Estes wrote:>Thanks for the replies Ralf and Alex, > >I have made the conversion from Shorewall 2.0.9 to 2.1.11 and as was >mentioned, I can now run norfc1918 again but I do not have proper >connectivity yet. It seems the proper association between the encrypted >traffic and the vpn zone is not being created correctly. I''ve probably >read the ipsec sections a dozen times but have yet to hit on a >combination that works. > >Just to review since it has been a few days: > >Node A >Suse 9.1 with the latest kernel and patches (2.6.5-111), shorewall >2.1.11, Freeswan 2.0.4. > >Node B >Mandrake 9.1 w/2.4.21 kernel (last of the 9.x where builtin freeswan >worked), shorewall 1.1.13, Freeswan 1.98b. > >I define 4 tunnels for complete gateway/subnet interconnects. The >tunnels connect and I can see they are active. I have full access to >NodeB from NodeA. However, when I try to access Subnet A from either >GatewayB or SubnetB, I get net2all reject messages. Below is a sample >message and the major settings I am using. This particular message is >for a ping but the same thing happens for any other communication I >attempt as well. The commented out settings represent things I have >tried but I did not get to work. Note that in this config, eth1 is my >external interface and eth0 is my internal interface which is different >from Tom''s examples. I did not include the policy or rules file as they >don''t seem to be having any effect on the result either. There are >policies and rules for vpn->loc and loc->vpn but I don''t appear to be >getting that far since this thinks it is in the net zone. Hoping someone >has some words of wisdom.. Thanks all.. > >Steve > >----------------------------------------- >Oct 24 00:42:41 tnode1 kernel: Shorewall:net2all:DROP:IN=eth1 OUT=eth0 >SRC=192.168.subnetB.x DST=192.168.subnetA.y LEN=84 TOS=0x00 PREC=0x00 >TTL=62 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=55838 SEQ=1 > > >params file: > >SUBNETA=192.168.subnetA.0/24 >SUBNETB=192.168.subnetB.0/24 >IPA=a.a.a.a >IPB=b.b.b.b > > >hosts file: > >#ZONE HOST(S) OPTIONS >#vpn eth1:0.0.0.0/0 >#vpn eth1:$SUBNETB,$IPB >vpn eth1:$SUBNETB,$IPB ipsec >#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE > > >interfaces file: > >#ZONE INTERFACE BROADCAST OPTIONS >net eth1 detect dhcp,routefilter,tcpflags,nosmurfs,nobogons,norfc1918 >loc eth0 detect ># >#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > > >ipsec file: > >#ZONE IPSEC OPTIONS IN OUT ># ONLY OPTIONS OPTIONS >vpn Yes >#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > > >masq file: > >#INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC >#eth1:!$SUBNETB $SUBNETA >#eth1 eth0 >eth1 $SUBNETA >#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE > > >tunnels file: > ># TYPE ZONE GATEWAY GATEWAY ># ZONE >ipsec net $IPB >#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE > > >zones file: > >#ZONE DISPLAY COMMENTS >vpn VPN FreeS/WAN Tunnel >net Net Internet >loc Local Local networks >#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE > > > >On Wed, 2004-10-20 at 05:26, Ralf Schenk wrote: > > > >>Steve Estes wrote: >> >> >>>I have been using shorewall and freeswan successfully for 3 or more >>>years now. But they have all been using the Linux 2.4 kernel. My current >>>configuration is (as the title suggests) using SuSE 9.1 which has a >>>2.6.5 kernel and freeswan 2.0.4 built-in. >>> >>> >>Go and download shorewall development (2.1.9). The ipsec interface is >>gone but SuSE 9.1 - at least if correctly updated - contains everything >>to use shorewall with the new ipsec features described in >>http://www.shorewall.net/IPSEC-2.6.html. >> >>I switched my system to shorewall development in 15 minutes and I''m >>using 2 tunnels to the dmz and the local net of my company from home. >>I''m using the built in freeswan, not kame/racoon as descibed in the >>above document. >> >>For your net - net tunnel the example "IPSec Gateway on the Firewall >>System" matches. Afterwards you can add your rfc1918 flag again on your >>interface. >> >> >> >>>Thanks for your time. >>> >>> >>> >_______________________________________________ >Shorewall-users mailing list >Post: Shorewall-users@lists.shorewall.net >Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-users >Support: http://www.shorewall.net/support.htm >FAQ: http://www.shorewall.net/FAQ.htm > >
Hi Tom, hello list, here´s a little analysis of our problem. shorewall check shows me that the definition for my VPN zone defined vi the host file seems to be correct: VPN0 Zone: ppp0:172.24.0.0/16 ppp0:212.185.xxx.xxx my policy allows VPN0 -> loc0 traffic and vpn0 -> fw But I get exactly the same behaviour as Steve, the traffic from vpn0 to loc0 get´s dropped by net2all, only the traffic to fw itself works. If I add a policy like "net loc0 ACCEPT" it works. So it seems that this traffic is strangely associated with the wrong zone (net). Any ideas? More information needed? Alex Alexander Wilms wrote:> Hi Steve, > > seems that I have the same problem. :-( > I didn´t mention it before, because I´m using only connections > initiated from 2.6 kernel shorewall here to the remote 2.4 kernel > shorewall. > > If I have time today I´ll try to find out why this traffic isn´t > associated correctly. > > Alex > > Steve Estes wrote: > >> Thanks for the replies Ralf and Alex, >> >> I have made the conversion from Shorewall 2.0.9 to 2.1.11 and as was >> mentioned, I can now run norfc1918 again but I do not have proper >> connectivity yet. It seems the proper association between the encrypted >> traffic and the vpn zone is not being created correctly. I''ve probably >> read the ipsec sections a dozen times but have yet to hit on a >> combination that works. >> Just to review since it has been a few days: >> >> Node A >> Suse 9.1 with the latest kernel and patches (2.6.5-111), shorewall >> 2.1.11, Freeswan 2.0.4. >> >> Node B >> Mandrake 9.1 w/2.4.21 kernel (last of the 9.x where builtin freeswan >> worked), shorewall 1.1.13, Freeswan 1.98b. >> >> I define 4 tunnels for complete gateway/subnet interconnects. The >> tunnels connect and I can see they are active. I have full access to >> NodeB from NodeA. However, when I try to access Subnet A from either >> GatewayB or SubnetB, I get net2all reject messages. Below is a sample >> message and the major settings I am using. This particular message is >> for a ping but the same thing happens for any other communication I >> attempt as well. The commented out settings represent things I have >> tried but I did not get to work. Note that in this config, eth1 is my >> external interface and eth0 is my internal interface which is different >> from Tom''s examples. I did not include the policy or rules file as they >> don''t seem to be having any effect on the result either. There are >> policies and rules for vpn->loc and loc->vpn but I don''t appear to be >> getting that far since this thinks it is in the net zone. Hoping someone >> has some words of wisdom.. Thanks all.. >> >> Steve >> >> ----------------------------------------- >> Oct 24 00:42:41 tnode1 kernel: Shorewall:net2all:DROP:IN=eth1 OUT=eth0 >> SRC=192.168.subnetB.x DST=192.168.subnetA.y LEN=84 TOS=0x00 PREC=0x00 >> TTL=62 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=55838 SEQ=1 >> >> >> params file: >> >> SUBNETA=192.168.subnetA.0/24 >> SUBNETB=192.168.subnetB.0/24 >> IPA=a.a.a.a >> IPB=b.b.b.b >> >> >> hosts file: >> >> #ZONE HOST(S) OPTIONS >> #vpn eth1:0.0.0.0/0 >> #vpn eth1:$SUBNETB,$IPB >> vpn eth1:$SUBNETB,$IPB ipsec >> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE >> >> >> interfaces file: >> >> #ZONE INTERFACE BROADCAST OPTIONS >> net eth1 detect >> dhcp,routefilter,tcpflags,nosmurfs,nobogons,norfc1918 >> loc eth0 detect >> # >> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE >> >> >> ipsec file: >> >> #ZONE IPSEC OPTIONS IN OUT >> # ONLY OPTIONS OPTIONS >> vpn Yes >> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE >> >> >> masq file: >> >> #INTERFACE SUBNET ADDRESS PROTO >> PORT(S) IPSEC >> #eth1:!$SUBNETB $SUBNETA >> #eth1 eth0 >> eth1 $SUBNETA >> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE >> >> >> tunnels file: >> >> # TYPE ZONE GATEWAY GATEWAY >> # ZONE >> ipsec net $IPB >> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE >> >> >> zones file: >> >> #ZONE DISPLAY COMMENTS >> vpn VPN FreeS/WAN Tunnel >> net Net Internet loc Local Local networks >> #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE >> >> >> >> On Wed, 2004-10-20 at 05:26, Ralf Schenk wrote: >> >> >> >>> Steve Estes wrote: >>> >>> >>>> I have been using shorewall and freeswan successfully for 3 or more >>>> years now. But they have all been using the Linux 2.4 kernel. My >>>> current >>>> configuration is (as the title suggests) using SuSE 9.1 which has a >>>> 2.6.5 kernel and freeswan 2.0.4 built-in. >>>> >>> >>> Go and download shorewall development (2.1.9). The ipsec interface >>> is gone but SuSE 9.1 - at least if correctly updated - contains >>> everything to use shorewall with the new ipsec features described in >>> http://www.shorewall.net/IPSEC-2.6.html. >>> >>> I switched my system to shorewall development in 15 minutes and I''m >>> using 2 tunnels to the dmz and the local net of my company from >>> home. I''m using the built in freeswan, not kame/racoon as descibed >>> in the above document. >>> >>> For your net - net tunnel the example "IPSec Gateway on the Firewall >>> System" matches. Afterwards you can add your rfc1918 flag again on >>> your interface. >>> >>> >>> >>>> Thanks for your time. >>>> >>>> >>> >> _______________________________________________ >> Shorewall-users mailing list >> Post: Shorewall-users@lists.shorewall.net >> Subscribe/Unsubscribe: >> https://lists.shorewall.net/mailman/listinfo/shorewall-users >> Support: http://www.shorewall.net/support.htm >> FAQ: http://www.shorewall.net/FAQ.htm >> >> > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm
I switched to OpenVPN for the same reason: I couldn''t manage to get SuSE 9.1 with kernel 2.6 to work with Freeswan and Shorewall, although I used the version from here: http://www.suse.de/~garloff/linux/FreeSWAN/ <http://www.suse.de/%7Egarloff/linux/FreeSWAN/> I can only recommend a look at OpenVPN, it works like a charm! http://openvpn.sourceforge.net/ HTH, Philipp Alexander Wilms schrieb:> Hi Tom, hello list, > > here´s a little analysis of our problem. > > shorewall check shows me that the definition for my VPN zone defined > vi the host file seems to be correct: > VPN0 Zone: ppp0:172.24.0.0/16 ppp0:212.185.xxx.xxx > > my policy allows VPN0 -> loc0 traffic > and vpn0 -> fw > > But I get exactly the same behaviour as Steve, the traffic from vpn0 > to loc0 get´s dropped by net2all, only the traffic to fw itself works. > If I add a policy like "net loc0 ACCEPT" it works. > > So it seems that this traffic is strangely associated with the wrong > zone (net). > > Any ideas? More information needed? > > Alex > > > Alexander Wilms wrote: > >> Hi Steve, >> >> seems that I have the same problem. :-( >> I didn´t mention it before, because I´m using only connections >> initiated from 2.6 kernel shorewall here to the remote 2.4 kernel >> shorewall. >> >> If I have time today I´ll try to find out why this traffic isn´t >> associated correctly. >> >> Alex >> >> Steve Estes wrote: >> >>> Thanks for the replies Ralf and Alex, >>> >>> I have made the conversion from Shorewall 2.0.9 to 2.1.11 and as was >>> mentioned, I can now run norfc1918 again but I do not have proper >>> connectivity yet. It seems the proper association between the encrypted >>> traffic and the vpn zone is not being created correctly. I''ve probably >>> read the ipsec sections a dozen times but have yet to hit on a >>> combination that works. >>> Just to review since it has been a few days: >>> >>> Node A >>> Suse 9.1 with the latest kernel and patches (2.6.5-111), shorewall >>> 2.1.11, Freeswan 2.0.4. >>> >>> Node B >>> Mandrake 9.1 w/2.4.21 kernel (last of the 9.x where builtin freeswan >>> worked), shorewall 1.1.13, Freeswan 1.98b. >>> >>> I define 4 tunnels for complete gateway/subnet interconnects. The >>> tunnels connect and I can see they are active. I have full access to >>> NodeB from NodeA. However, when I try to access Subnet A from either >>> GatewayB or SubnetB, I get net2all reject messages. Below is a sample >>> message and the major settings I am using. This particular message is >>> for a ping but the same thing happens for any other communication I >>> attempt as well. The commented out settings represent things I have >>> tried but I did not get to work. Note that in this config, eth1 is my >>> external interface and eth0 is my internal interface which is different >>> from Tom''s examples. I did not include the policy or rules file as they >>> don''t seem to be having any effect on the result either. There are >>> policies and rules for vpn->loc and loc->vpn but I don''t appear to be >>> getting that far since this thinks it is in the net zone. Hoping >>> someone >>> has some words of wisdom.. Thanks all.. >>> >>> Steve >>> >>> ----------------------------------------- >>> Oct 24 00:42:41 tnode1 kernel: Shorewall:net2all:DROP:IN=eth1 OUT=eth0 >>> SRC=192.168.subnetB.x DST=192.168.subnetA.y LEN=84 TOS=0x00 PREC=0x00 >>> TTL=62 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=55838 SEQ=1 >>> >>> >>> params file: >>> >>> SUBNETA=192.168.subnetA.0/24 >>> SUBNETB=192.168.subnetB.0/24 >>> IPA=a.a.a.a >>> IPB=b.b.b.b >>> >>> >>> hosts file: >>> >>> #ZONE HOST(S) OPTIONS >>> #vpn eth1:0.0.0.0/0 >>> #vpn eth1:$SUBNETB,$IPB >>> vpn eth1:$SUBNETB,$IPB ipsec >>> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE >>> >>> >>> interfaces file: >>> >>> #ZONE INTERFACE BROADCAST OPTIONS >>> net eth1 detect >>> dhcp,routefilter,tcpflags,nosmurfs,nobogons,norfc1918 >>> loc eth0 detect >>> # >>> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE >>> >>> >>> ipsec file: >>> >>> #ZONE IPSEC OPTIONS IN OUT >>> # ONLY OPTIONS OPTIONS >>> vpn Yes >>> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE >>> >>> >>> masq file: >>> >>> #INTERFACE SUBNET ADDRESS PROTO >>> PORT(S) IPSEC >>> #eth1:!$SUBNETB $SUBNETA >>> #eth1 eth0 >>> eth1 $SUBNETA >>> #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE >>> >>> >>> tunnels file: >>> >>> # TYPE ZONE GATEWAY GATEWAY >>> # ZONE >>> ipsec net $IPB >>> #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE >>> >>> >>> zones file: >>> >>> #ZONE DISPLAY COMMENTS >>> vpn VPN FreeS/WAN Tunnel >>> net Net Internet loc Local Local networks >>> #LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE >>> >>> >>> >>> On Wed, 2004-10-20 at 05:26, Ralf Schenk wrote: >>> >>> >>> >>>> Steve Estes wrote: >>>> >>>> >>>>> I have been using shorewall and freeswan successfully for 3 or more >>>>> years now. But they have all been using the Linux 2.4 kernel. My >>>>> current >>>>> configuration is (as the title suggests) using SuSE 9.1 which has a >>>>> 2.6.5 kernel and freeswan 2.0.4 built-in. >>>>> >>>> >>>> >>>> Go and download shorewall development (2.1.9). The ipsec interface >>>> is gone but SuSE 9.1 - at least if correctly updated - contains >>>> everything to use shorewall with the new ipsec features described >>>> in http://www.shorewall.net/IPSEC-2.6.html. >>>> >>>> I switched my system to shorewall development in 15 minutes and I''m >>>> using 2 tunnels to the dmz and the local net of my company from >>>> home. I''m using the built in freeswan, not kame/racoon as descibed >>>> in the above document. >>>> >>>> For your net - net tunnel the example "IPSec Gateway on the >>>> Firewall System" matches. Afterwards you can add your rfc1918 flag >>>> again on your interface. >>>> >>>> >>>> >>>>> Thanks for your time. >>>>> >>>>> >>>> >>>> >>> _______________________________________________ >>> Shorewall-users mailing list >>> Post: Shorewall-users@lists.shorewall.net >>> Subscribe/Unsubscribe: >>> https://lists.shorewall.net/mailman/listinfo/shorewall-users >>> Support: http://www.shorewall.net/support.htm >>> FAQ: http://www.shorewall.net/FAQ.htm >>> >>> >> _______________________________________________ >> Shorewall-users mailing list >> Post: Shorewall-users@lists.shorewall.net >> Subscribe/Unsubscribe: >> https://lists.shorewall.net/mailman/listinfo/shorewall-users >> Support: http://www.shorewall.net/support.htm >> FAQ: http://www.shorewall.net/FAQ.htm > > > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: > https://lists.shorewall.net/mailman/listinfo/shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm >
On Sunday 24 October 2004 04:58, Alexander Wilms wrote:> Hi Tom, hello list, > > here´s a little analysis of our problem. > > shorewall check shows me that the definition for my VPN zone defined vi > the host file seems to be correct: > VPN0 Zone: ppp0:172.24.0.0/16 ppp0:212.185.xxx.xxx > > my policy allows VPN0 -> loc0 traffic > and vpn0 -> fw > > But I get exactly the same behaviour as Steve, the traffic from vpn0 to > loc0 get´s dropped by net2all, only the traffic to fw itself works. > If I add a policy like "net loc0 ACCEPT" it works. > > So it seems that this traffic is strangely associated with the wrong > zone (net). > > Any ideas? More information needed? >Please try the ''firewall'' script from the CVS Shorewall2/ project (install in /usr/share/shorewall/firewall). If that doesn''t help then please submit a proper problem report with the information listed at http://shorewall.net/support.htm (including the output of "shorewall status"!). Remember folks, this is still pre-beta software so telling me what your configuration files look like doesn''t really help; there are still going to be cases where correct config files produce the wrong Netfilter ruleset. -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 Sunday 24 October 2004 10:33, Alexander Wilms wrote:> Hi Tom, > the "firewall" script from CVS works as expected! >Thanks, Alex. I corrected one problem along these lines this week and I''m glad to hear that you haven''t found another one :-) -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 Sunday 24 October 2004 05:28, Philipp Rusch wrote:> I switched to OpenVPN for the same reason: > I couldn''t manage to get SuSE 9.1 with kernel 2.6 to work with Freeswan > and Shorewall, although I used the version from here: > http://www.suse.de/~garloff/linux/FreeSWAN/ > <http://www.suse.de/%7Egarloff/linux/FreeSWAN/> > > > I can only recommend a look at OpenVPN, it works like a charm! > http://openvpn.sourceforge.net/ >The 2.6 Kernel implementation of IPSEC also works very well if you have the latest CVS version of Shorewall 2.1 and follow the instructions at http://shorewall.net/IPSEC-2.6.html. I''m about to begin the Shorewall 2.2.0 Beta -- just as soon as I muster enough energy to update all of the Documentation. -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
Thanks Tom and Alex. Tiz working well for me also now.. Steve On Sun, 2004-10-24 at 13:41, Tom Eastep wrote:> On Sunday 24 October 2004 05:28, Philipp Rusch wrote: > > I switched to OpenVPN for the same reason: > > I couldn''t manage to get SuSE 9.1 with kernel 2.6 to work with Freeswan > > and Shorewall, although I used the version from here: > > http://www.suse.de/~garloff/linux/FreeSWAN/ > > <http://www.suse.de/%7Egarloff/linux/FreeSWAN/> > > > > > > I can only recommend a look at OpenVPN, it works like a charm! > > http://openvpn.sourceforge.net/ > > > > The 2.6 Kernel implementation of IPSEC also works very well if you have the > latest CVS version of Shorewall 2.1 and follow the instructions at > http://shorewall.net/IPSEC-2.6.html. > > I''m about to begin the Shorewall 2.2.0 Beta -- just as soon as I muster enough > energy to update all of the Documentation. > > -Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Steve Estes wrote:> Thanks Tom and Alex. Tiz working well for me also now.. >Good to hear, Steve. I realize that living on the bleeding edge isn''t always fun but I appreciate those who stick with me until I get it right. - -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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBfF5xO/MAbZfjDLIRAsBYAJ4w+AdxjaCenyQKOfXMXlrhbBiKPgCcCVzE YIhDdvjBfzXfA2pqA7o0v6k=jiKc -----END PGP SIGNATURE-----