Hi, I''m running Slackware 13.37 x86 using Shorewall 4.4.21 with OpenVPN and the VPN options I''m using in Slackware 13.37 will not work in Shorewall, but in Slackware 13.1 using the same Shorewall version and files, the ''interfaces'', ''policy'' and ''zone'', are all I have configured, it was working and this also works in Arch at present too, with the same Shorewall version and files. So I suspect something to do with Slackware has changed since 13.1 causing this issue because I tried this out with the default kernel that ships with Slackware and it still would not work. For *POLICY* line 1 & 2 if I use it the way you see it below this allows me to have a connection over eth0 or wlan0. With it like this and I then connect to OpenVPN, after I''m connected to the VPN, I then comment out line 2 and uncomment line 1, restart shorewall and now the connection stays routed over the VPN and if the VPN is disconnected for any reason and I try to get back online with 1 uncommented and 2 commented I can''t and this is the behaviour I''d like to keep. I''m attaching a dump I did which is ''diff -u'' with Arch online with the VPN running with the policy line 1 uncommented and line 2 commented and working and the same settings for the policy in Slackware but the VPN connection won''t go online. Hopefully with the dump.txt someone can tell me why Slackware will not work with the VPN in the policy line 1 uncommented and line 2 commented.... THANKS Das *INTERFACES* ############################################################################### #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,tcpflags,logmartians,nosmurfs net wlan0 detect dhcp,tcpflags,logmartians,nosmurfs # OpenVPN Interface vpn tun0 detect vpn tap0 detect * POLICY* ############################################################################### #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: # LEVEL BURST MASK # # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules *1. #$FW net DROP info* # Allow NET Zone when not on VPN - (Allow all connection requests from the firewall to the Internet) *2. $FW net ACCEPT * # Allow this machine to access the VPN ZONE for everything $FW vpn ACCEPT # Block anything from the NET ZONE to all other zones - (Drop (ignore) all connection requests from the Internet to your firewall) net all DROP info # Block from using another connection net net NONE # # The FOLLOWING POLICY MUST BE LAST # # Block everything else - (Reject all other connection requests (Shorewall requires this catchall policy) all all REJECT info *ZONE* ############################################################################### #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 #vpn ipsec vpn ipv4 ------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/
Hi, I just sent the first message which for some reason took the attachement, I thought we could add attachements and it put it in the post instead of this information below. So here it is again, sorry if I wasn''t suppose to add an attachment... I''m running Slackware 13.37 x86 using Shorewall 4.4.21 with OpenVPN and the VPN options I''m using in Slackware 13.37 will not work in Shorewall, but in Slackware 13.1 using the same Shorewall version and files, the ''interfaces'', ''policy'' and ''zone'', are all I have configured, it was working and this also works in Arch at present too, with the same Shorewall version and files. So I suspect something to do with Slackware has changed since 13.1 causing this issue because I tried this out with the default kernel that ships with Slackware and it still would not work. For *POLICY* line 1 & 2 if I use it the way you see it below this allows me to have a connection over eth0 or wlan0. With it like this and I then connect to OpenVPN, after I''m connected to the VPN, I then comment out line 2 and uncomment line 1, restart shorewall and now the connection stays routed over the VPN and if the VPN is disconnected for any reason and I try to get back online with 1 uncommented and 2 commented I can''t and this is the behaviour I''d like to keep. I''m attaching a dump I did which is ''diff -u'' with Arch online with the VPN running with the policy line 1 uncommented and line 2 commented and working and the same settings for the policy in Slackware but the VPN connection won''t go online. Hopefully with the dump.txt someone can tell me why Slackware will not work with the VPN in the policy line 1 uncommented and line 2 commented.... THANKS Das *INTERFACES* #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,tcpflags,logmartians,nosmurfs net wlan0 detect dhcp,tcpflags,logmartians,nosmurfs # OpenVPN Interface vpn tun0 detect vpn tap0 detect * POLICY* #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: # LEVEL BURST MASK # # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules *1. #$FW net DROP info* # Allow NET Zone when not on VPN - (Allow all connection requests from the firewall to the Internet) *2. $FW net ACCEPT * # Allow this machine to access the VPN ZONE for everything $FW vpn ACCEPT # Block anything from the NET ZONE to all other zones - (Drop (ignore) all connection requests from the Internet to your firewall) net all DROP info # Block from using another connection net net NONE # # The FOLLOWING POLICY MUST BE LAST # # Block everything else - (Reject all other connection requests (Shorewall requires this catchall policy) all all REJECT info *ZONE* #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 #vpn ipsec vpn ipv4 ------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/
On Wed, 2011-07-20 at 20:36 -1000, Das wrote:> I''m attaching a dump I did which is ''diff -u'' with Arch online with > the VPN running with the policy line 1 uncommented and line 2 > commented and working and the same settings for the policy in > Slackware but the VPN connection won''t go online.What failure messages does OpenVPN generate?> # OpenVPN Interface > vpn tun0 detect > vpn tap0 detectWhy both tap and tun devices? Do you have both routed and bridged OpenVPN configurations? -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 \________________________________________________ ------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/
On Thu, 2011-07-21 at 06:29 -0700, Tom Eastep wrote:> On Wed, 2011-07-20 at 20:36 -1000, Das wrote: > > > I''m attaching a dump I did which is ''diff -u'' with Arch online with > > the VPN running with the policy line 1 uncommented and line 2 > > commented and working and the same settings for the policy in > > Slackware but the VPN connection won''t go online. > > What failure messages does OpenVPN generate? > > > # OpenVPN Interface > > vpn tun0 detect > > vpn tap0 detect > > Why both tap and tun devices? Do you have both routed and bridged > OpenVPN configurations? >Here are some more observations: 1) fw->net rules. Chain fw2net (2 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:67:68 - 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED - 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 + 1 97 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED + 4 236 Drop all -- * * 0.0.0.0/0 0.0.0.0/0 + 4 236 ULOG all -- * * 0.0.0.0/0 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix `Shorewall:fw2net:DROP:'' queue_threshold 1 + 4 236 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 In neither configuration do you have an ACCEPT rule allowing outgoing OpenVPN. Which begs the question as to how the Arch configuration works. The Shorewall OpenVPN HOWTO clearly shows the need for a tunnels file entry (preferably openvpnclient, in your case). 2) Logging. -Log (/var/log/shorewall) +Log (/var/log/shorewall-init.log) The fact that there are no differences shown in log entries indicates that the LOGFILE setting on both configurations is wrong. The Netfilter log is one of the primary tools you need to use to troubleshoot connection problems. 3) Routing. +94.231.84.82 via 192.168.1.1 dev eth0 <=============+192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.8 metric 202 +10.235.0.0/16 dev tun0 proto kernel scope link src 10.235.0.151 +127.0.0.0/8 dev lo scope link +0.0.0.0/1 via 10.235.0.1 dev tun0 +128.0.0.0/1 via 10.235.0.1 dev tun0 default via 192.168.1.1 dev eth0 metric 202 -94.231.84.81 via 192.168.1.1 dev eth0 <==============-192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 metric 202 Different static routes are defined in the two configurations. -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 \________________________________________________ ------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/
Hi Tom, I forgot to mention, I''m just a client using a VPN service, I''m not running an OpenVPN server and then connecting to it. I originally thought just like how the docs show, you use a protocol and it''s port and you define those in the rules and possibly host and tunnel as well but I don''t need to, it''s working just fine with only those 3 files and I''ve actually used 4 different VPN providers over the past year with those 3 files just like they are and all connections to all of the VPN providers worked just fine, that was in Slackware 13.1 earlier in the year. I have tap and tun because I was using in the past IPsec which uses tap, so I keep it there in case I start using IPsec again. I do not see any types of failure or error messages, it''s like taking your Cat5 and unplugging it then trying to ping or go online, the same effect, nothing happens, that''s all. I have played with using tunnels and host and seen no changes on any of the systems to improve or degrade the outcome, it''s all the same whether I use them or not, everything works the same, in short, it doesn''t change anything... LOGFILE=/var/log/shorewall-init.log This is the same shorewall.conf I''ve always used; http://pastebin.com/9HY0XrsJ I forgot how you spell his name but pad-twk said the routes below were fine when I asked him the other day online, he said it was like that because that''s two different computers sitting behind the nat router, or he said something to this affect... THANKS On Thu, Jul 21, 2011 at 6:19 AM, Tom Eastep <teastep@shorewall.net> wrote:> On Thu, 2011-07-21 at 06:29 -0700, Tom Eastep wrote: > > On Wed, 2011-07-20 at 20:36 -1000, Das wrote: > > > > > I''m attaching a dump I did which is ''diff -u'' with Arch online with > > > the VPN running with the policy line 1 uncommented and line 2 > > > commented and working and the same settings for the policy in > > > Slackware but the VPN connection won''t go online. > > > > What failure messages does OpenVPN generate? > > > > > # OpenVPN Interface > > > vpn tun0 detect > > > vpn tap0 detect > > > > Why both tap and tun devices? Do you have both routed and bridged > > OpenVPN configurations? > > > > Here are some more observations: > > 1) fw->net rules. > > Chain fw2net (2 references) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp dpts:67:68 > - 0 0 ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 ctstate RELATED,ESTABLISHED > - 0 0 ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 > + 1 97 ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 ctstate RELATED,ESTABLISHED > + 4 236 Drop all -- * * 0.0.0.0/0 > 0.0.0.0/0 > + 4 236 ULOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix > `Shorewall:fw2net:DROP:'' queue_threshold 1 > + 4 236 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 > > In neither configuration do you have an ACCEPT rule allowing outgoing > OpenVPN. Which begs the question as to how the Arch configuration works. > > The Shorewall OpenVPN HOWTO clearly shows the need for a tunnels file > entry (preferably openvpnclient, in your case). > > 2) Logging. > > -Log (/var/log/shorewall) > +Log (/var/log/shorewall-init.log) > > The fact that there are no differences shown in log entries indicates > that the LOGFILE setting on both configurations is wrong. The Netfilter > log is one of the primary tools you need to use to troubleshoot > connection problems. > > 3) Routing. > > +94.231.84.82 via 192.168.1.1 dev eth0 <=============> +192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.8 > metric 202 > +10.235.0.0/16 dev tun0 proto kernel scope link src 10.235.0.151 > +127.0.0.0/8 dev lo scope link > +0.0.0.0/1 via 10.235.0.1 dev tun0 > +128.0.0.0/1 via 10.235.0.1 dev tun0 > default via 192.168.1.1 dev eth0 metric 202 > -94.231.84.81 via 192.168.1.1 dev eth0 <==============> -192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 > metric 202 > > Different static routes are defined in the two configurations. > > -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 \________________________________________________ > > > > ------------------------------------------------------------------------------ > 5 Ways to Improve & Secure Unified Communications > Unified Communications promises greater efficiencies for business. UC can > improve internal communications as well as offer faster, more efficient > ways > to interact with customers and streamline customer service. Learn more! > http://www.accelacomm.com/jaw/sfnl/114/51426253/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/
Hi, My bad I accidently changed it by mistake my LOGFILE= when I put Shorewall on Arch to test it. This is what I''ve always used in the past and put it back; LOGFILE=/var/log/ulogd.syslogemu THANKS On Thu, Jul 21, 2011 at 11:44 AM, Das <dasfox@gmail.com> wrote:> Hi Tom, > > I forgot to mention, I''m just a client using a VPN service, I''m not running > an OpenVPN server and then connecting to it. > > I originally thought just like how the docs show, you use a protocol and > it''s port and you define those in the rules and possibly host and tunnel as > well but I don''t need to, it''s working just fine with only those 3 files and > I''ve actually used 4 different VPN providers over the past year with those 3 > files just like they are and all connections to all of the VPN providers > worked just fine, that was in Slackware 13.1 earlier in the year. > > I have tap and tun because I was using in the past IPsec which uses tap, so > I keep it there in case I start using IPsec again. > > I do not see any types of failure or error messages, it''s like taking your > Cat5 and unplugging it then trying to ping or go online, the same effect, > nothing happens, that''s all. > > I have played with using tunnels and host and seen no changes on any of the > systems to improve or degrade the outcome, it''s all the same whether I use > them or not, everything works the same, in short, it doesn''t change > anything... > > LOGFILE=/var/log/shorewall-init.log > > This is the same shorewall.conf I''ve always used; > > http://pastebin.com/9HY0XrsJ > > I forgot how you spell his name but pad-twk said the routes below were fine > when I asked him the other day online, he said it was like that because > that''s two different computers sitting behind the nat router, or he said > something to this affect... > > > THANKS > > > On Thu, Jul 21, 2011 at 6:19 AM, Tom Eastep <teastep@shorewall.net> wrote: > >> On Thu, 2011-07-21 at 06:29 -0700, Tom Eastep wrote: >> > On Wed, 2011-07-20 at 20:36 -1000, Das wrote: >> > >> > > I''m attaching a dump I did which is ''diff -u'' with Arch online with >> > > the VPN running with the policy line 1 uncommented and line 2 >> > > commented and working and the same settings for the policy in >> > > Slackware but the VPN connection won''t go online. >> > >> > What failure messages does OpenVPN generate? >> > >> > > # OpenVPN Interface >> > > vpn tun0 detect >> > > vpn tap0 detect >> > >> > Why both tap and tun devices? Do you have both routed and bridged >> > OpenVPN configurations? >> > >> >> Here are some more observations: >> >> 1) fw->net rules. >> >> Chain fw2net (2 references) >> pkts bytes target prot opt in out source >> destination >> 0 0 ACCEPT udp -- * * 0.0.0.0/0 >> 0.0.0.0/0 udp dpts:67:68 >> - 0 0 ACCEPT all -- * * 0.0.0.0/0 >> 0.0.0.0/0 ctstate RELATED,ESTABLISHED >> - 0 0 ACCEPT all -- * * 0.0.0.0/0 >> 0.0.0.0/0 >> + 1 97 ACCEPT all -- * * 0.0.0.0/0 >> 0.0.0.0/0 ctstate RELATED,ESTABLISHED >> + 4 236 Drop all -- * * 0.0.0.0/0 >> 0.0.0.0/0 >> + 4 236 ULOG all -- * * 0.0.0.0/0 >> 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix >> `Shorewall:fw2net:DROP:'' queue_threshold 1 >> + 4 236 DROP all -- * * 0.0.0.0/0 >> 0.0.0.0/0 >> >> In neither configuration do you have an ACCEPT rule allowing outgoing >> OpenVPN. Which begs the question as to how the Arch configuration works. >> >> The Shorewall OpenVPN HOWTO clearly shows the need for a tunnels file >> entry (preferably openvpnclient, in your case). >> >> 2) Logging. >> >> -Log (/var/log/shorewall) >> +Log (/var/log/shorewall-init.log) >> >> The fact that there are no differences shown in log entries indicates >> that the LOGFILE setting on both configurations is wrong. The Netfilter >> log is one of the primary tools you need to use to troubleshoot >> connection problems. >> >> 3) Routing. >> >> +94.231.84.82 via 192.168.1.1 dev eth0 <=============>> +192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.8 >> metric 202 >> +10.235.0.0/16 dev tun0 proto kernel scope link src 10.235.0.151 >> +127.0.0.0/8 dev lo scope link >> +0.0.0.0/1 via 10.235.0.1 dev tun0 >> +128.0.0.0/1 via 10.235.0.1 dev tun0 >> default via 192.168.1.1 dev eth0 metric 202 >> -94.231.84.81 via 192.168.1.1 dev eth0 <==============>> -192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 >> metric 202 >> >> Different static routes are defined in the two configurations. >> >> -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 \________________________________________________ >> >> >> >> ------------------------------------------------------------------------------ >> 5 Ways to Improve & Secure Unified Communications >> Unified Communications promises greater efficiencies for business. UC can >> improve internal communications as well as offer faster, more efficient >> ways >> to interact with customers and streamline customer service. Learn more! >> http://www.accelacomm.com/jaw/sfnl/114/51426253/ >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >> >------------------------------------------------------------------------------ 5 Ways to Improve & Secure Unified Communications Unified Communications promises greater efficiencies for business. UC can improve internal communications as well as offer faster, more efficient ways to interact with customers and streamline customer service. Learn more! http://www.accelacomm.com/jaw/sfnl/114/51426253/
Hi, Here is some more info to hopefully help; ip r, ifconfig, iptables-save; http://pastebin.com/bSc8Tw8a THANKS On Thu, Jul 21, 2011 at 11:55 AM, Das <dasfox@gmail.com> wrote:> Hi, > > My bad I accidently changed it by mistake my LOGFILE= when I put Shorewall > on Arch to test it. > > This is what I''ve always used in the past and put it back; > > LOGFILE=/var/log/ulogd.syslogemu > > > THANKS > > > On Thu, Jul 21, 2011 at 11:44 AM, Das <dasfox@gmail.com> wrote: > >> Hi Tom, >> >> I forgot to mention, I''m just a client using a VPN service, I''m not >> running an OpenVPN server and then connecting to it. >> >> I originally thought just like how the docs show, you use a protocol and >> it''s port and you define those in the rules and possibly host and tunnel as >> well but I don''t need to, it''s working just fine with only those 3 files and >> I''ve actually used 4 different VPN providers over the past year with those 3 >> files just like they are and all connections to all of the VPN providers >> worked just fine, that was in Slackware 13.1 earlier in the year. >> >> I have tap and tun because I was using in the past IPsec which uses tap, >> so I keep it there in case I start using IPsec again. >> >> I do not see any types of failure or error messages, it''s like taking your >> Cat5 and unplugging it then trying to ping or go online, the same effect, >> nothing happens, that''s all. >> >> I have played with using tunnels and host and seen no changes on any of >> the systems to improve or degrade the outcome, it''s all the same whether I >> use them or not, everything works the same, in short, it doesn''t change >> anything... >> >> LOGFILE=/var/log/shorewall-init.log >> >> This is the same shorewall.conf I''ve always used; >> >> http://pastebin.com/9HY0XrsJ >> >> I forgot how you spell his name but pad-twk said the routes below were >> fine when I asked him the other day online, he said it was like that because >> that''s two different computers sitting behind the nat router, or he said >> something to this affect... >> >> >> THANKS >> >> >> On Thu, Jul 21, 2011 at 6:19 AM, Tom Eastep <teastep@shorewall.net>wrote: >> >>> On Thu, 2011-07-21 at 06:29 -0700, Tom Eastep wrote: >>> > On Wed, 2011-07-20 at 20:36 -1000, Das wrote: >>> > >>> > > I''m attaching a dump I did which is ''diff -u'' with Arch online with >>> > > the VPN running with the policy line 1 uncommented and line 2 >>> > > commented and working and the same settings for the policy in >>> > > Slackware but the VPN connection won''t go online. >>> > >>> > What failure messages does OpenVPN generate? >>> > >>> > > # OpenVPN Interface >>> > > vpn tun0 detect >>> > > vpn tap0 detect >>> > >>> > Why both tap and tun devices? Do you have both routed and bridged >>> > OpenVPN configurations? >>> > >>> >>> Here are some more observations: >>> >>> 1) fw->net rules. >>> >>> Chain fw2net (2 references) >>> pkts bytes target prot opt in out source >>> destination >>> 0 0 ACCEPT udp -- * * 0.0.0.0/0 >>> 0.0.0.0/0 udp dpts:67:68 >>> - 0 0 ACCEPT all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 ctstate RELATED,ESTABLISHED >>> - 0 0 ACCEPT all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 >>> + 1 97 ACCEPT all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 ctstate RELATED,ESTABLISHED >>> + 4 236 Drop all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 >>> + 4 236 ULOG all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix >>> `Shorewall:fw2net:DROP:'' queue_threshold 1 >>> + 4 236 DROP all -- * * 0.0.0.0/0 >>> 0.0.0.0/0 >>> >>> In neither configuration do you have an ACCEPT rule allowing outgoing >>> OpenVPN. Which begs the question as to how the Arch configuration works. >>> >>> The Shorewall OpenVPN HOWTO clearly shows the need for a tunnels file >>> entry (preferably openvpnclient, in your case). >>> >>> 2) Logging. >>> >>> -Log (/var/log/shorewall) >>> +Log (/var/log/shorewall-init.log) >>> >>> The fact that there are no differences shown in log entries indicates >>> that the LOGFILE setting on both configurations is wrong. The Netfilter >>> log is one of the primary tools you need to use to troubleshoot >>> connection problems. >>> >>> 3) Routing. >>> >>> +94.231.84.82 via 192.168.1.1 dev eth0 <=============>>> +192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.8 >>> metric 202 >>> +10.235.0.0/16 dev tun0 proto kernel scope link src 10.235.0.151 >>> +127.0.0.0/8 dev lo scope link >>> +0.0.0.0/1 via 10.235.0.1 dev tun0 >>> +128.0.0.0/1 via 10.235.0.1 dev tun0 >>> default via 192.168.1.1 dev eth0 metric 202 >>> -94.231.84.81 via 192.168.1.1 dev eth0 <==============>>> -192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3 >>> metric 202 >>> >>> Different static routes are defined in the two configurations. >>> >>> -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 \________________________________________________ >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 5 Ways to Improve & Secure Unified Communications >>> Unified Communications promises greater efficiencies for business. UC can >>> improve internal communications as well as offer faster, more efficient >>> ways >>> to interact with customers and streamline customer service. Learn more! >>> http://www.accelacomm.com/jaw/sfnl/114/51426253/ >>> _______________________________________________ >>> Shorewall-users mailing list >>> Shorewall-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/shorewall-users >>> >>> >> >------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/
On Jul 21, 2011, at 2:55 PM, Das wrote:> > I forgot to mention, I''m just a client using a VPN service, I''m not running an OpenVPN server and then connecting to it. > > I originally thought just like how the docs show, you use a protocol and it''s port and you define those in the rules and possibly host and tunnel as well but I don''t need to, it''s working just fine with only those 3 files and I''ve actually used 4 different VPN providers over the past year with those 3 files just like they are and all connections to all of the VPN providers worked just fine, that was in Slackware 13.1 earlier in the year.And I''m telling you that there is absolutely no reason for it to have worked at all, which makes me wonder if Shorewall is even started.> > I have tap and tun because I was using in the past IPsec which uses tap, so I keep it there in case I start using IPsec again. > > I do not see any types of failure or error messages, it''s like taking your Cat5 and unplugging it then trying to ping or go online, the same effect, nothing happens, that''s all.The Slackware configuration was logging messages out of the fw->net chain.> > I have played with using tunnels and host and seen no changes on any of the systems to improve or degrade the outcome, it''s all the same whether I use them or not, everything works the same, in short, it doesn''t change anything…Please add the openvpnclient tunnel, Configure LOGFILE correctly and try to start OpenVPN with the latest Slackware -- then post the *entire* dump. -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 \________________________________________________ ------------------------------------------------------------------------------ 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/
Hi Tom, I was at it for a few days with Slackware users that were very knowledgeable and experienced with iptables and netfiler and they couldn''t figure it out or see anything wrong and why it wasn''t working... I just chalked it up to a possible routing bug in Slack. I had a backup image so I reinstalled 13.37 with it. The problem happened under a fresh install of Slack, not the backup image. Well the backup image, everything is now working as it was before. So if you want me to run any tests to have you look at this to see how this is working, without needing any rules, host, or tunnels configured and just the 3 files I use is all, policy, interfaces, zones, I''ll be glad to show you it works now as I''ve been using it. Which by the way I do find odd, unless, because I''m using a VPN service, I do not need to configure things the way I''ve read online, since I''m not running an OpenVPN sever, I''m just a client connecting to a VPN service. But I still thought even in this sense I''d need to have a rule to open the ports and protocols and I don''t. I don''t even need to open/forward the ports on my router.... THANKS On Thu, Jul 21, 2011 at 3:00 PM, Tom Eastep <teastep@shorewall.net> wrote:> > On Jul 21, 2011, at 2:55 PM, Das wrote: > > >> I forgot to mention, I''m just a client using a VPN service, I''m not >> running an OpenVPN server and then connecting to it. >> >> I originally thought just like how the docs show, you use a protocol and >> it''s port and you define those in the rules and possibly host and tunnel as >> well but I don''t need to, it''s working just fine with only those 3 files and >> I''ve actually used 4 different VPN providers over the past year with those 3 >> files just like they are and all connections to all of the VPN providers >> worked just fine, that was in Slackware 13.1 earlier in the year. >> > > And I''m telling you that there is absolutely no reason for it to have > worked at all, which makes me wonder if Shorewall is even started. > > >> I have tap and tun because I was using in the past IPsec which uses tap, >> so I keep it there in case I start using IPsec again. >> >> I do not see any types of failure or error messages, it''s like taking your >> Cat5 and unplugging it then trying to ping or go online, the same effect, >> nothing happens, that''s all. > > > The Slackware configuration was logging messages out of the fw->net chain. > > > >> I have played with using tunnels and host and seen no changes on any of >> the systems to improve or degrade the outcome, it''s all the same whether I >> use them or not, everything works the same, in short, it doesn''t change >> anything… >> > > Please add the openvpnclient tunnel, Configure LOGFILE correctly and try to > start OpenVPN with the latest Slackware -- then post the *entire* dump. > > > -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 \________________________________________________ > > > > > ------------------------------------------------------------------------------ > 10 Tips for Better Web Security > Learn 10 ways to better secure your business today. Topics covered include: > Web security, SSL, hacker attacks & Denial of Service (DoS), private keys, > security Microsoft Exchange, secure Instant Messaging, and much more. > http://www.accelacomm.com/jaw/sfnl/114/51426210/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
Hi Tom,
Ok just using only the interfaces, policy and zones here''s a dump while
connected to the vpn with it working with it like this in the policy as I
mentioned before;
$FW net DROP ULOG
#$FW net ACCEPT
$FW vpn ACCEPT
Here''s the dump;
Shorewall 4.4.20.3 Dump at slackware - Tue Jul 26 11:38:50 HST 2011
Counters reset Tue Jul 26 11:19:27 HST 2011
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
3 192 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
3781 2702K eth0_in all -- eth0 * 0.0.0.0/0
0.0.0.0/0
0 0 wlan0_in all -- wlan0 * 0.0.0.0/0
0.0.0.0/0
3701 2401K vpn2fw all -- tun0 * 0.0.0.0/0
0.0.0.0/0
0 0 vpn2fw all -- tap0 * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
0 0 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:INPUT:REJECT:'' queue_threshold 1
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0 [goto]
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 eth0_fwd all -- eth0 * 0.0.0.0/0
0.0.0.0/0
0 0 wlan0_fwd all -- wlan0 * 0.0.0.0/0
0.0.0.0/0
0 0 vpn_frwd all -- tun0 * 0.0.0.0/0
0.0.0.0/0
0 0 vpn_frwd all -- tap0 * 0.0.0.0/0
0.0.0.0/0
0 0 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:FORWARD:REJECT:'' queue_threshold 1
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0 [goto]
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
3770 747K fw2net all -- * eth0 0.0.0.0/0
0.0.0.0/0
0 0 fw2net all -- * wlan0 0.0.0.0/0
0.0.0.0/0
3690 451K fw2vpn all -- * tun0 0.0.0.0/0
0.0.0.0/0
0 0 fw2vpn all -- * tap0 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all -- * lo 0.0.0.0/0
0.0.0.0/0
0 0 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:OUTPUT:REJECT:'' queue_threshold 1
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0 [goto]
Chain Drop (3 references)
pkts bytes target prot opt in out source
destination
6 360 all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:113 /* Auth */
6 360 dropBcast all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 3 code 4 /* Needed ICMP types */
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 11 /* Needed ICMP types */
6 360 dropInvalid all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 135,445 /* SMB */
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:137:139 /* SMB */
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp spt:137 dpts:1024:65535 /* SMB */
0 0 DROP tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 135,139,445 /* SMB */
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:1900 /* UPnP */
6 360 dropNotSyn tcp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp spt:53 /* Late DNS Replies */
Chain Reject (5 references)
pkts bytes target prot opt in out source
destination
0 0 all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:113 /* Auth */
0 0 dropBcast all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 3 code 4 /* Needed ICMP types */
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 11 /* Needed ICMP types */
0 0 dropInvalid all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 135,445 /* SMB */
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:137:139 /* SMB */
0 0 reject udp -- * * 0.0.0.0/0
0.0.0.0/0 udp spt:137 dpts:1024:65535 /* SMB */
0 0 reject tcp -- * * 0.0.0.0/0
0.0.0.0/0 multiport dports 135,139,445 /* SMB */
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpt:1900 /* UPnP */
0 0 dropNotSyn tcp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 DROP udp -- * * 0.0.0.0/0
0.0.0.0/0 udp spt:53 /* Late DNS Replies */
Chain dropBcast (2 references)
pkts bytes target prot opt in out source
destination
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0 ADDRTYPE match dst-type BROADCAST
0 0 DROP all -- * * 0.0.0.0/0
224.0.0.0/4
Chain dropInvalid (2 references)
pkts bytes target prot opt in out source
destination
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID
Chain dropNotSyn (2 references)
pkts bytes target prot opt in out source
destination
0 0 DROP tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp flags:!0x17/0x02
Chain dynamic (7 references)
pkts bytes target prot opt in out source
destination
Chain eth0_fwd (1 references)
pkts bytes target prot opt in out source
destination
0 0 sfilter all -- * eth0 0.0.0.0/0
0.0.0.0/0 [goto]
0 0 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
0 0 smurfs all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
0 0 tcpflags tcp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 net_frwd all -- * * 0.0.0.0/0
0.0.0.0/0
Chain eth0_in (1 references)
pkts bytes target prot opt in out source
destination
3 192 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
3 192 smurfs all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
3 192 tcpflags tcp -- * * 0.0.0.0/0
0.0.0.0/0
3781 2702K net2fw all -- * * 0.0.0.0/0
0.0.0.0/0
Chain fw2net (2 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
3764 747K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT esp -- * * 0.0.0.0/0
10.99.99.10
0 0 ACCEPT udp -- * * 0.0.0.0/0
10.99.99.10 udp dpt:500 ctstate NEW
0 0 ACCEPT icmp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:51413
6 360 Drop all -- * * 0.0.0.0/0
0.0.0.0/0
6 360 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:fw2net:DROP:'' queue_threshold 1
6 360 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain fw2vpn (2 references)
pkts bytes target prot opt in out source
destination
2727 391K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT esp -- * * 0.0.0.0/0
10.99.99.10
0 0 ACCEPT udp -- * * 0.0.0.0/0
10.99.99.10 udp dpt:500 ctstate NEW
963 60146 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0
Chain logdrop (0 references)
pkts bytes target prot opt in out source
destination
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain logflags (5 references)
pkts bytes target prot opt in out source
destination
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:logflags:DROP:'' queue_threshold 1
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain logreject (0 references)
pkts bytes target prot opt in out source
destination
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net2fw (2 references)
pkts bytes target prot opt in out source
destination
3778 2702K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT esp -- * * 10.99.99.10
0.0.0.0/0
0 0 ACCEPT udp -- * * 10.99.99.10
0.0.0.0/0 udp dpt:500 ctstate NEW
0 0 DROP icmp -- * * 0.0.0.0/0
0.0.0.0/0 icmp type 8 /* Ping */
0 0 DROP tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:113
3 192 ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:51413
0 0 Drop all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:net2fw:DROP:'' queue_threshold 1
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net2vpn (2 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 Drop all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:net2vpn:DROP:'' queue_threshold 1
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain net_frwd (2 references)
pkts bytes target prot opt in out source
destination
0 0 net2vpn all -- * tun0 0.0.0.0/0
0.0.0.0/0
0 0 net2vpn all -- * tap0 0.0.0.0/0
0.0.0.0/0
Chain reject (12 references)
pkts bytes target prot opt in out source
destination
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0 ADDRTYPE match src-type BROADCAST
0 0 DROP all -- * * 224.0.0.0/4
0.0.0.0/0
0 0 DROP 2 -- * * 0.0.0.0/0
0.0.0.0/0
0 0 REJECT tcp -- * * 0.0.0.0/0
0.0.0.0/0 reject-with tcp-reset
0 0 REJECT udp -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-port-unreachable
0 0 REJECT icmp -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-unreachable
0 0 REJECT all -- * * 0.0.0.0/0
0.0.0.0/0 reject-with icmp-host-prohibited
Chain sfilter (4 references)
pkts bytes target prot opt in out source
destination
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:sfilter:DROP:'' queue_threshold 1
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain shorewall (0 references)
pkts bytes target prot opt in out source
destination
Chain smurflog (2 references)
pkts bytes target prot opt in out source
destination
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:smurfs:DROP:'' queue_threshold 1
0 0 DROP all -- * * 0.0.0.0/0
0.0.0.0/0
Chain smurfs (4 references)
pkts bytes target prot opt in out source
destination
0 0 RETURN all -- * * 0.0.0.0
0.0.0.0/0
0 0 smurflog all -- * * 0.0.0.0/0
0.0.0.0/0 [goto] ADDRTYPE match src-type BROADCAST
0 0 smurflog all -- * * 224.0.0.0/4
0.0.0.0/0 [goto]
Chain tcpflags (4 references)
pkts bytes target prot opt in out source
destination
0 0 logflags tcp -- * * 0.0.0.0/0
0.0.0.0/0 [goto] tcp flags:0x3F/0x29
0 0 logflags tcp -- * * 0.0.0.0/0
0.0.0.0/0 [goto] tcp flags:0x3F/0x00
0 0 logflags tcp -- * * 0.0.0.0/0
0.0.0.0/0 [goto] tcp flags:0x06/0x06
0 0 logflags tcp -- * * 0.0.0.0/0
0.0.0.0/0 [goto] tcp flags:0x03/0x03
0 0 logflags tcp -- * * 0.0.0.0/0
0.0.0.0/0 [goto] tcp spt:0 flags:0x17/0x02
Chain vpn2fw (2 references)
pkts bytes target prot opt in out source
destination
0 0 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
3701 2401K ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 ACCEPT esp -- * * 10.99.99.10
0.0.0.0/0
0 0 ACCEPT udp -- * * 10.99.99.10
0.0.0.0/0 udp dpt:500 ctstate NEW
0 0 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:vpn2fw:REJECT:'' queue_threshold 1
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0 [goto]
Chain vpn2net (2 references)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate RELATED,ESTABLISHED
0 0 Reject all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 ULOG all -- * * 0.0.0.0/0
0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix
`Shorewall:vpn2net:REJECT:'' queue_threshold 1
0 0 reject all -- * * 0.0.0.0/0
0.0.0.0/0 [goto]
Chain vpn_frwd (2 references)
pkts bytes target prot opt in out source
destination
0 0 sfilter all -- * tun0 0.0.0.0/0
0.0.0.0/0 [goto]
0 0 sfilter all -- * tap0 0.0.0.0/0
0.0.0.0/0 [goto]
0 0 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
0 0 vpn2net all -- * eth0 0.0.0.0/0
0.0.0.0/0
0 0 vpn2net all -- * wlan0 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all -- * tun0 0.0.0.0/0
0.0.0.0/0
0 0 ACCEPT all -- * tap0 0.0.0.0/0
0.0.0.0/0
Chain wlan0_fwd (1 references)
pkts bytes target prot opt in out source
destination
0 0 sfilter all -- * wlan0 0.0.0.0/0
0.0.0.0/0 [goto]
0 0 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
0 0 smurfs all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
0 0 tcpflags tcp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 net_frwd all -- * * 0.0.0.0/0
0.0.0.0/0
Chain wlan0_in (1 references)
pkts bytes target prot opt in out source
destination
0 0 dynamic all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
0 0 smurfs all -- * * 0.0.0.0/0
0.0.0.0/0 ctstate INVALID,NEW
0 0 ACCEPT udp -- * * 0.0.0.0/0
0.0.0.0/0 udp dpts:67:68
0 0 tcpflags tcp -- * * 0.0.0.0/0
0.0.0.0/0
0 0 net2fw all -- * * 0.0.0.0/0
0.0.0.0/0
Log (/var/log/ulogd.syslogemu)
Jul 26 11:20:10 fw2net:DROP: IN= OUT=eth0 SRC=192.168.1.2 DST=94.231.84.80
LEN=60 TOS=00 PREC=0x00 TTL=64 ID=53602 CE DF PROTO=TCP SPT=40535 DPT=80
SEQ=597166587 ACK=0 WINDOW=5840 SYN URGP=0
Jul 26 11:20:13 fw2net:DROP: IN= OUT=eth0 SRC=192.168.1.2 DST=94.231.84.80
LEN=60 TOS=00 PREC=0x00 TTL=64 ID=53603 CE DF PROTO=TCP SPT=40535 DPT=80
SEQ=597166587 ACK=0 WINDOW=5840 SYN URGP=0
Jul 26 11:20:19 fw2net:DROP: IN= OUT=eth0 SRC=192.168.1.2 DST=94.231.84.80
LEN=60 TOS=00 PREC=0x00 TTL=64 ID=53604 CE DF PROTO=TCP SPT=40535 DPT=80
SEQ=597166587 ACK=0 WINDOW=5840 SYN URGP=0
Jul 26 11:20:31 fw2net:DROP: IN= OUT=eth0 SRC=192.168.1.2 DST=94.231.84.80
LEN=60 TOS=00 PREC=0x00 TTL=64 ID=53605 CE DF PROTO=TCP SPT=40535 DPT=80
SEQ=597166587 ACK=0 WINDOW=5840 SYN URGP=0
Jul 26 11:20:55 fw2net:DROP: IN= OUT=eth0 SRC=192.168.1.2 DST=94.231.84.80
LEN=60 TOS=00 PREC=0x00 TTL=64 ID=53606 CE DF PROTO=TCP SPT=40535 DPT=80
SEQ=597166587 ACK=0 WINDOW=5840 SYN URGP=0
Jul 26 11:21:43 fw2net:DROP: IN= OUT=eth0 SRC=192.168.1.2 DST=94.231.84.80
LEN=60 TOS=00 PREC=0x00 TTL=64 ID=53607 CE DF PROTO=TCP SPT=40535 DPT=80
SEQ=597166587 ACK=0 WINDOW=5840 SYN URGP=0
NAT Table
Chain PREROUTING (policy ACCEPT 3 packets, 192 bytes)
pkts bytes target prot opt in out source
destination
Chain INPUT (policy ACCEPT 3 packets, 192 bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 969 packets, 60506 bytes)
pkts bytes target prot opt in out source
destination
Chain POSTROUTING (policy ACCEPT 963 packets, 60146 bytes)
pkts bytes target prot opt in out source
destination
Mangle Table
Chain PREROUTING (policy ACCEPT 7482 packets, 5103K bytes)
pkts bytes target prot opt in out source
destination
7482 5103K tcpre all -- * * 0.0.0.0/0
0.0.0.0/0
Chain INPUT (policy ACCEPT 7482 packets, 5103K bytes)
pkts bytes target prot opt in out source
destination
7482 5103K tcin all -- * * 0.0.0.0/0
0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
0 0 MARK all -- * * 0.0.0.0/0
0.0.0.0/0 MARK and 0xffffff00
0 0 tcfor all -- * * 0.0.0.0/0
0.0.0.0/0
Chain OUTPUT (policy ACCEPT 7460 packets, 1198K bytes)
pkts bytes target prot opt in out source
destination
7460 1198K tcout all -- * * 0.0.0.0/0
0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 7454 packets, 1198K bytes)
pkts bytes target prot opt in out source
destination
7454 1198K tcpost all -- * * 0.0.0.0/0
0.0.0.0/0
Chain tcfor (1 references)
pkts bytes target prot opt in out source
destination
Chain tcin (1 references)
pkts bytes target prot opt in out source
destination
Chain tcout (1 references)
pkts bytes target prot opt in out source
destination
Chain tcpost (1 references)
pkts bytes target prot opt in out source
destination
Chain tcpre (1 references)
pkts bytes target prot opt in out source
destination
Raw Table
Chain PREROUTING (policy ACCEPT 7482 packets, 5103K bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy ACCEPT 7460 packets, 1198K bytes)
pkts bytes target prot opt in out source
destination
Conntrack Table (17 out of 65536)
tcp 6 79 TIME_WAIT src=10.233.0.148 dst=66.227.46.190 sport=36769
dport=80 src=66.227.46.190 dst=10.233.0.148 sport=80 dport=36769 [ASSURED]
mark=0 use=2
tcp 6 79 TIME_WAIT src=10.233.0.148 dst=66.227.46.190 sport=36771
dport=80 src=66.227.46.190 dst=10.233.0.148 sport=80 dport=36771 [ASSURED]
mark=0 use=2
tcp 6 89 TIME_WAIT src=10.233.0.148 dst=66.227.46.190 sport=36772
dport=80 src=66.227.46.190 dst=10.233.0.148 sport=80 dport=36772 [ASSURED]
mark=0 use=2
tcp 6 20 TIME_WAIT src=10.233.0.148 dst=64.214.231.153 sport=50741
dport=80 src=64.214.231.153 dst=10.233.0.148 sport=80 dport=50741 [ASSURED]
mark=0 use=2
tcp 6 79 TIME_WAIT src=10.233.0.148 dst=66.227.46.190 sport=36768
dport=80 src=66.227.46.190 dst=10.233.0.148 sport=80 dport=36768 [ASSURED]
mark=0 use=2
udp 17 11 src=10.233.0.148 dst=156.154.70.22 sport=59746 dport=53
src=156.154.70.22 dst=10.233.0.148 sport=53 dport=59746 mark=0 use=2
udp 17 12 src=10.233.0.148 dst=156.154.70.22 sport=37197 dport=53
src=156.154.70.22 dst=10.233.0.148 sport=53 dport=37197 mark=0 use=2
udp 17 13 src=10.233.0.148 dst=156.154.70.22 sport=60930 dport=53
src=156.154.70.22 dst=10.233.0.148 sport=53 dport=60930 mark=0 use=2
udp 17 175 src=192.168.1.2 dst=94.231.84.80 sport=35711 dport=1194
src=94.231.84.80 dst=192.168.1.2 sport=1194 dport=35711 [ASSURED] mark=0
use=2
tcp 6 79 TIME_WAIT src=10.233.0.148 dst=66.227.46.190 sport=36770
dport=80 src=66.227.46.190 dst=10.233.0.148 sport=80 dport=36770 [ASSURED]
mark=0 use=2
icmp 1 15 src=10.233.0.148 dst=67.195.160.76 type=8 code=0 id=2391
src=67.195.160.76 dst=10.233.0.148 type=0 code=0 id=2391 mark=0 use=2
tcp 6 78 TIME_WAIT src=10.233.0.148 dst=66.227.46.190 sport=36767
dport=80 src=66.227.46.190 dst=10.233.0.148 sport=80 dport=36767 [ASSURED]
mark=0 use=2
tcp 6 24 TIME_WAIT src=10.233.0.148 dst=66.227.46.190 sport=36765
dport=80 src=66.227.46.190 dst=10.233.0.148 sport=80 dport=36765 [ASSURED]
mark=0 use=2
udp 17 10 src=10.233.0.148 dst=156.154.70.22 sport=54292 dport=53
src=156.154.70.22 dst=10.233.0.148 sport=53 dport=54292 mark=0 use=2
tcp 6 73 TIME_WAIT src=10.233.0.148 dst=74.125.79.18 sport=49344
dport=443 src=74.125.79.18 dst=10.233.0.148 sport=443 dport=49344 [ASSURED]
mark=0 use=2
udp 17 14 src=10.233.0.148 dst=156.154.70.22 sport=60784 dport=53
src=156.154.70.22 dst=10.233.0.148 sport=53 dport=60784 mark=0 use=2
tcp 6 21 TIME_WAIT src=10.233.0.148 dst=64.214.231.145 sport=53445
dport=80 src=64.214.231.145 dst=10.233.0.148 sport=80 dport=53445 [ASSURED]
mark=0 use=2
IP Configuration
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP qlen 1000
inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast
state UNKNOWN qlen 100
inet 10.233.0.148/16 brd 10.233.255.255 scope global tun0
IP Stats
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP qlen 1000
link/ether 00:29:23:1b:d6:3d brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
2777404 3908 0 0 0 0
TX: bytes packets errors dropped carrier collsns
812650 3900 0 0 1 0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN
qlen 1000
link/ether 0c:60:76:51:82:c2 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
4: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen
1000
link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast
state UNKNOWN qlen 100
link/none
RX: bytes packets errors dropped overrun mcast
2403873 3718 0 0 0 0
TX: bytes packets errors dropped carrier collsns
452386 3707 0 0 0 0
Per-IP Counters
iptaccount is not installed
/proc
/proc/version = Linux version 2.6.36.4 (root@slackware) (gcc version
4.5.2 (GCC) ) #2 PREEMPT Mon Jul 11 18:10:05 HST 2011
/proc/sys/net/ipv4/ip_forward = 1
/proc/sys/net/ipv4/icmp_echo_ignore_all = 0
/proc/sys/net/ipv4/conf/all/proxy_arp = 0
/proc/sys/net/ipv4/conf/all/arp_filter = 0
/proc/sys/net/ipv4/conf/all/arp_ignore = 0
/proc/sys/net/ipv4/conf/all/rp_filter = 0
/proc/sys/net/ipv4/conf/all/log_martians = 0
/proc/sys/net/ipv4/conf/default/proxy_arp = 0
/proc/sys/net/ipv4/conf/default/arp_filter = 0
/proc/sys/net/ipv4/conf/default/arp_ignore = 0
/proc/sys/net/ipv4/conf/default/rp_filter = 0
/proc/sys/net/ipv4/conf/default/log_martians = 1
/proc/sys/net/ipv4/conf/eth0/proxy_arp = 0
/proc/sys/net/ipv4/conf/eth0/arp_filter = 0
/proc/sys/net/ipv4/conf/eth0/arp_ignore = 0
/proc/sys/net/ipv4/conf/eth0/rp_filter = 0
/proc/sys/net/ipv4/conf/eth0/log_martians = 1
/proc/sys/net/ipv4/conf/lo/proxy_arp = 0
/proc/sys/net/ipv4/conf/lo/arp_filter = 0
/proc/sys/net/ipv4/conf/lo/arp_ignore = 0
/proc/sys/net/ipv4/conf/lo/rp_filter = 0
/proc/sys/net/ipv4/conf/lo/log_martians = 1
/proc/sys/net/ipv4/conf/tun0/proxy_arp = 0
/proc/sys/net/ipv4/conf/tun0/arp_filter = 0
/proc/sys/net/ipv4/conf/tun0/arp_ignore = 0
/proc/sys/net/ipv4/conf/tun0/rp_filter = 0
/proc/sys/net/ipv4/conf/tun0/log_martians = 1
/proc/sys/net/ipv4/conf/vboxnet0/proxy_arp = 0
/proc/sys/net/ipv4/conf/vboxnet0/arp_filter = 0
/proc/sys/net/ipv4/conf/vboxnet0/arp_ignore = 0
/proc/sys/net/ipv4/conf/vboxnet0/rp_filter = 0
/proc/sys/net/ipv4/conf/vboxnet0/log_martians = 1
/proc/sys/net/ipv4/conf/wlan0/proxy_arp = 0
/proc/sys/net/ipv4/conf/wlan0/arp_filter = 0
/proc/sys/net/ipv4/conf/wlan0/arp_ignore = 0
/proc/sys/net/ipv4/conf/wlan0/rp_filter = 0
/proc/sys/net/ipv4/conf/wlan0/log_martians = 1
Routing Rules
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Table default:
Table local:
broadcast 192.168.1.0 dev eth0 proto kernel scope link src 192.168.1.2
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 192.168.1.2 dev eth0 proto kernel scope host src 192.168.1.2
broadcast 10.233.255.255 dev tun0 proto kernel scope link src
10.233.0.148
broadcast 10.233.0.0 dev tun0 proto kernel scope link src 10.233.0.148
local 10.233.0.148 dev tun0 proto kernel scope host src 10.233.0.148
broadcast 192.168.1.255 dev eth0 proto kernel scope link src 192.168.1.2
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
Table main:
94.231.84.80 via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 metric
202
10.233.0.0/16 dev tun0 proto kernel scope link src 10.233.0.148
127.0.0.0/8 dev lo scope link
0.0.0.0/1 via 10.233.0.1 dev tun0
128.0.0.0/1 via 10.233.0.1 dev tun0
default via 192.168.1.1 dev eth0 metric 202
ARP
? (192.168.1.1) at 00:22:3f:d4:65:c2 [ether] on eth0
Modules
ip_tables 7946 4
iptable_nat,iptable_raw,iptable_mangle,iptable_filter
ipt_REJECT 1570 4
ipt_ULOG 3833 12
ipt_addrtype 1401 3
iptable_filter 1012 1
iptable_mangle 1100 1
iptable_nat 2928 0
iptable_raw 924 0
nf_conntrack 38356 21
iptable_nat,xt_conntrack,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_ftp,nf_nat,nf_conntrack_ipv4,nf_conntrack_tftp,nf_conntrack_sip,nf_conntrack_proto_sctp,nf_conntrack_pptp,nf_conntrack_proto_gre,nf_conntrack_netlink,nf_conntrack_netbios_ns,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_ftp
nf_conntrack_ftp 4121 1 nf_nat_ftp
nf_conntrack_h323 30773 1 nf_nat_h323
nf_conntrack_ipv4 8182 25 iptable_nat,nf_nat
nf_conntrack_irc 2403 1 nf_nat_irc
nf_conntrack_netbios_ns 970 0
nf_conntrack_netlink 10514 0
nf_conntrack_pptp 3357 1 nf_nat_pptp
nf_conntrack_proto_gre 2932 1 nf_conntrack_pptp
nf_conntrack_proto_sctp 4885 0
nf_conntrack_sip 13762 1 nf_nat_sip
nf_conntrack_tftp 2369 1 nf_nat_tftp
nf_defrag_ipv4 903 1 nf_conntrack_ipv4
nf_nat 11396 8
iptable_nat,nf_nat_tftp,nf_nat_sip,nf_nat_pptp,nf_nat_proto_gre,nf_nat_irc,nf_nat_h323,nf_nat_ftp
nf_nat_ftp 1136 0
nf_nat_h323 4346 0
nf_nat_irc 958 0
nf_nat_pptp 1699 0
nf_nat_proto_gre 913 1 nf_nat_pptp
nf_nat_sip 4417 0
nf_nat_snmp_basic 6363 0
nf_nat_tftp 642 0
xt_comment 615 19
xt_conntrack 1953 22
xt_mark 785 1
xt_multiport 1264 4
xt_tcpudp 1738 26
Shorewall has detected the following iptables/netfilter capabilities:
NAT: Available
Packet Mangling: Available
Multi-port Match: Available
Extended Multi-port Match: Available
Connection Tracking Match: Available
Extended Connection Tracking Match Support: Available
Packet Type Match: Available
Policy Match: Available
Physdev Match: Not available
Physdev-is-bridged Support: Not available
Packet length Match: Available
IP range Match: Available
Recent Match: Available
Owner Match: Available
CONNMARK Target: Available
Extended CONNMARK Target: Available
Connmark Match: Available
Extended Connmark Match: Available
Raw Table: Available
IPP2P Match: Not available
CLASSIFY Target: Available
Extended REJECT: Available
Repeat match: Available
MARK Target: Available
Extended MARK Target: Available
Extended MARK Target 2: Available
Mangle FORWARD Chain: Available
Comments: Available
Address Type Match: Available
TCPMSS Match: Available
Hashlimit Match: Available
NFQUEUE Target: Available
Realm Match: Available
Helper Match: Available
Connlimit Match: Available
Time Match: Available
Goto Support: Available
LOGMARK Target: Not available
IPMARK Target: Not available
LOG Target: Available
Persistent SNAT: Available
TPROXY Target: Available
FLOW Classifier: Available
fwmark route mask: Available
Mark in any table: Available
Header Match: Not available
ACCOUNT Target: Not available
AUDIT Target: Not available
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State PID/Program name
udp 0 0 0.0.0.0:35711 0.0.0.0:*
1887/openvpn
Traffic Control
Device eth0:
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1
1 1 1
Sent 811998 bytes 3900 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Device wlan0:
qdisc mq 0: root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :1 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :2 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :3 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class mq :4 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Device tun0:
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1
1 1 1
Sent 452386 bytes 3707 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
TC Filters
Device eth0:
Device wlan0:
Device tun0:
On Fri, Jul 22, 2011 at 3:33 PM, Das <dasfox@gmail.com> wrote:
> Hi Tom,
>
> I was at it for a few days with Slackware users that were very
> knowledgeable and experienced with iptables and netfiler and they
couldn''t
> figure it out or see anything wrong and why it wasn''t working...
>
> I just chalked it up to a possible routing bug in Slack.
>
> I had a backup image so I reinstalled 13.37 with it. The problem happened
> under a fresh install of Slack, not the backup image. Well the backup
image,
> everything is now working as it was before.
>
> So if you want me to run any tests to have you look at this to see how this
> is working, without needing any rules, host, or tunnels configured and just
> the 3 files I use is all, policy, interfaces, zones, I''ll be glad
to show
> you it works now as I''ve been using it. Which by the way I do find
odd,
> unless, because I''m using a VPN service, I do not need to
configure things
> the way I''ve read online, since I''m not running an
OpenVPN sever, I''m just a
> client connecting to a VPN service. But I still thought even in this sense
> I''d need to have a rule to open the ports and protocols and I
don''t. I don''t
> even need to open/forward the ports on my router....
>
> THANKS
>
>
>
>
> On Thu, Jul 21, 2011 at 3:00 PM, Tom Eastep <teastep@shorewall.net>
wrote:
>
>>
>> On Jul 21, 2011, at 2:55 PM, Das wrote:
>>
>>
>>> I forgot to mention, I''m just a client using a VPN
service, I''m not
>>> running an OpenVPN server and then connecting to it.
>>>
>>> I originally thought just like how the docs show, you use a
protocol and
>>> it''s port and you define those in the rules and possibly
host and tunnel as
>>> well but I don''t need to, it''s working just fine
with only those 3 files and
>>> I''ve actually used 4 different VPN providers over the past
year with those 3
>>> files just like they are and all connections to all of the VPN
providers
>>> worked just fine, that was in Slackware 13.1 earlier in the year.
>>>
>>
>> And I''m telling you that there is absolutely no reason for it
to have
>> worked at all, which makes me wonder if Shorewall is even started.
>>
>>
>>> I have tap and tun because I was using in the past IPsec which uses
tap,
>>> so I keep it there in case I start using IPsec again.
>>>
>>> I do not see any types of failure or error messages, it''s
like taking
>>> your Cat5 and unplugging it then trying to ping or go online, the
same
>>> effect, nothing happens, that''s all.
>>
>>
>> The Slackware configuration was logging messages out of the fw->net
chain.
>>
>>
>>
>>> I have played with using tunnels and host and seen no changes on
any of
>>> the systems to improve or degrade the outcome, it''s all
the same whether I
>>> use them or not, everything works the same, in short, it
doesn''t change
>>> anything…
>>>
>>
>> Please add the openvpnclient tunnel, Configure LOGFILE correctly and
try
>> to start OpenVPN with the latest Slackware -- then post the *entire*
dump.
>>
>>
>> -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 \________________________________________________
>>
>>
>>
>>
>>
------------------------------------------------------------------------------
>> 10 Tips for Better Web Security
>> Learn 10 ways to better secure your business today. Topics covered
>> include:
>> Web security, SSL, hacker attacks & Denial of Service (DoS),
private keys,
>> security Microsoft Exchange, secure Instant Messaging, and much more.
>> http://www.accelacomm.com/jaw/sfnl/114/51426210/
>>
>> _______________________________________________
>> Shorewall-users mailing list
>> Shorewall-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>>
>>
>
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don''t ask for help often.
Plus, you''ll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
On Jul 26, 2011, at 2:42 PM, Das wrote:> Hi Tom, > > Ok just using only the interfaces, policy and zones here''s a dump while > connected to the vpn with it working with it like this in the policy as I > mentioned before; > > $FW net DROP ULOG > #$FW net ACCEPT > $FW vpn ACCEPT > > Here''s the dump; >Unbelievable -- Shorewall dump output embedded in an HTML/RTF email message.> Shorewall 4.4.20.3 Dump at slackware - Tue Jul 26 11:38:50 HST 2011 > > Counters reset Tue Jul 26 11:19:27 HST 2011 > > > Chain OUTPUT (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > 3770 747K fw2net all -- * eth0 0.0.0.0/0 > 0.0.0.0/0 > 0 0 fw2net all -- * wlan0 0.0.0.0/0 > 0.0.0.0/0 > 3690 451K fw2vpn all -- * tun0 0.0.0.0/0 > 0.0.0.0/0 > 0 0 fw2vpn all -- * tap0 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ACCEPT all -- * lo 0.0.0.0/0 > 0.0.0.0/0 > 0 0 Reject all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 0 0 ULOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix > `Shorewall:OUTPUT:REJECT:'' queue_threshold 1 > 0 0 reject all -- * * 0.0.0.0/0 > 0.0.0.0/0 [goto] >Above is the OUTPUT chain. Traffic originating on the firewall and leaving on eth0 is sent through chain ''fw2net''.> Chain fw2net (2 references) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 udp dpts:67:68The above is DHCP.> 3764 747K ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 ctstate RELATED,ESTABLISHEDThe above just handles packets that are part of a connection> 0 0 ACCEPT esp -- * * 0.0.0.0/0 > 10.99.99.10 > 0 0 ACCEPT udp -- * * 0.0.0.0/0 > 10.99.99.10 udp dpt:500 ctstate NEW > 0 0 ACCEPT icmp -- * * 0.0.0.0/0 > 0.0.0.0/0The above are for IPSEC.> 0 0 ACCEPT tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 tcp dpt:51413Don''t know why you want to allow TCP 51413.> 6 360 Drop all -- * * 0.0.0.0/0 > 0.0.0.0/0 > 6 360 ULOG all -- * * 0.0.0.0/0 > 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix > `Shorewall:fw2net:DROP:'' queue_threshold 1 > 6 360 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 >''Drop'' Filters what gets logged by the next rule. ULOG logs it and DROP discards it. Note that *no new connections* other than DNS have been established since Shorewall was [re]started Tue Jul 26 11:19:27 HST 2011.> Conntrack Table (17 out of 65536) >...> > udp 17 175 src=192.168.1.2 dst=94.231.84.80 sport=35711 dport=1194 > src=94.231.84.80 dst=192.168.1.2 sport=1194 dport=35711 [ASSURED] mark=0 > use=2This connection is your OpenVPN tunnel. That is a fw->net UDP connection to UDP port 1194.> IP Configuration > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN > inet 127.0.0.1/8 scope host lo > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state > UP qlen 1000 > inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0 > 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > state UNKNOWN qlen 100 > inet 10.233.0.148/16 brd 10.233.255.255 scope global tun0 > >The src address of the tunnel is the IP address of eth0.> Routing Rules > > 0: from all lookup local > 32766: from all lookup main > 32767: from all lookup default > > Table default: > > > Table local: > > broadcast 192.168.1.0 dev eth0 proto kernel scope link src 192.168.1.2 > broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 > local 192.168.1.2 dev eth0 proto kernel scope host src 192.168.1.2 > broadcast 10.233.255.255 dev tun0 proto kernel scope link src > 10.233.0.148 > broadcast 10.233.0.0 dev tun0 proto kernel scope link src 10.233.0.148 > local 10.233.0.148 dev tun0 proto kernel scope host src 10.233.0.148 > broadcast 192.168.1.255 dev eth0 proto kernel scope link src 192.168.1.2 > broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 > local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 > local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 > > Table main: > > 94.231.84.80 via 192.168.1.1 dev eth0 <==========================> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 metric > 202 > 10.233.0.0/16 dev tun0 proto kernel scope link src 10.233.0.148 > 127.0.0.0/8 dev lo scope link > 0.0.0.0/1 via 10.233.0.1 dev tun0 > 128.0.0.0/1 via 10.233.0.1 dev tun0 > default via 192.168.1.1 dev eth0 metric 202 >Which makes sense since the connection would be routed out of eth0 by the first route in the main table. Conclusion. Either: a) The tunnel was established before Shorewall started. b) Something is *really* wrong with Netfilter on this system. -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Sorry what? ---> Unbelievable -- Shorewall dump output embedded in an HTML/RTF email message. You told me in the last email to post the entire dump, I assumed that meant to just paste it into the email? a) The tunnel was established before Shorewall started. I put Shorewall into a slackware package that has /etc/rc.d/rc.firewall and rc.shorewall so shorewall starts up when my system boots and is always running from the beginning. b) Something is *really* wrong with Netfilter on this system. Like any distro, if someone hasn''t touched anything, then what could be wrong and how could there be something wrong? I thought netfilter on all distros works out the box... As I mentioned before, this works also on Arch the same way... I have Slack on a backup image, it only takes me 5mins to install it and everything back up and running, so it''s not a problem and I''m more then willing to install any distro of your choice that you know out the box is going to work and not have any problems with netfilter so that we can rule that out, because I don''t believe it''s this... THANKS On Tue, Jul 26, 2011 at 1:43 PM, Tom Eastep <teastep@shorewall.net> wrote:> On Jul 26, 2011, at 2:42 PM, Das wrote: > > > Hi Tom, > > > > Ok just using only the interfaces, policy and zones here''s a dump while > > connected to the vpn with it working with it like this in the policy as I > > mentioned before; > > > > $FW net DROP ULOG > > #$FW net ACCEPT > > $FW vpn ACCEPT > > > > Here''s the dump; > > > > Unbelievable -- Shorewall dump output embedded in an HTML/RTF email > message. > > > Shorewall 4.4.20.3 Dump at slackware - Tue Jul 26 11:38:50 HST 2011 > > > > Counters reset Tue Jul 26 11:19:27 HST 2011 > > > > > > Chain OUTPUT (policy DROP 0 packets, 0 bytes) > > pkts bytes target prot opt in out source > > destination > > 3770 747K fw2net all -- * eth0 0.0.0.0/0 > > 0.0.0.0/0 > > 0 0 fw2net all -- * wlan0 0.0.0.0/0 > > 0.0.0.0/0 > > 3690 451K fw2vpn all -- * tun0 0.0.0.0/0 > > 0.0.0.0/0 > > 0 0 fw2vpn all -- * tap0 0.0.0.0/0 > > 0.0.0.0/0 > > 0 0 ACCEPT all -- * lo 0.0.0.0/0 > > 0.0.0.0/0 > > 0 0 Reject all -- * * 0.0.0.0/0 > > 0.0.0.0/0 > > 0 0 ULOG all -- * * 0.0.0.0/0 > > 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix > > `Shorewall:OUTPUT:REJECT:'' queue_threshold 1 > > 0 0 reject all -- * * 0.0.0.0/0 > > 0.0.0.0/0 [goto] > > > > Above is the OUTPUT chain. Traffic originating on the firewall and leaving > on eth0 is sent through chain ''fw2net''. > > > > Chain fw2net (2 references) > > pkts bytes target prot opt in out source > > destination > > 0 0 ACCEPT udp -- * * 0.0.0.0/0 > > 0.0.0.0/0 udp dpts:67:68 > > The above is DHCP. > > > 3764 747K ACCEPT all -- * * 0.0.0.0/0 > > 0.0.0.0/0 ctstate RELATED,ESTABLISHED > > The above just handles packets that are part of a connection > > > 0 0 ACCEPT esp -- * * 0.0.0.0/0 > > 10.99.99.10 > > 0 0 ACCEPT udp -- * * 0.0.0.0/0 > > 10.99.99.10 udp dpt:500 ctstate NEW > > 0 0 ACCEPT icmp -- * * 0.0.0.0/0 > > 0.0.0.0/0 > > The above are for IPSEC. > > > 0 0 ACCEPT tcp -- * * 0.0.0.0/0 > > 0.0.0.0/0 tcp dpt:51413 > > Don''t know why you want to allow TCP 51413. > > > 6 360 Drop all -- * * 0.0.0.0/0 > > 0.0.0.0/0 > > 6 360 ULOG all -- * * 0.0.0.0/0 > > 0.0.0.0/0 ULOG copy_range 0 nlgroup 1 prefix > > `Shorewall:fw2net:DROP:'' queue_threshold 1 > > 6 360 DROP all -- * * 0.0.0.0/0 > > 0.0.0.0/0 > > > > ''Drop'' Filters what gets logged by the next rule. ULOG logs it and DROP > discards it. Note that *no new connections* other than DNS have been > established since Shorewall was [re]started Tue Jul 26 11:19:27 HST 2011. > > > Conntrack Table (17 out of 65536) > > > ... > > > > udp 17 175 src=192.168.1.2 dst=94.231.84.80 sport=35711 dport=1194 > > src=94.231.84.80 dst=192.168.1.2 sport=1194 dport=35711 [ASSURED] mark=0 > > use=2 > > This connection is your OpenVPN tunnel. That is a fw->net UDP connection to > UDP port 1194. > > > IP Configuration > > > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN > > inet 127.0.0.1/8 scope host lo > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > state > > UP qlen 1000 > > inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0 > > 5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc > pfifo_fast > > state UNKNOWN qlen 100 > > inet 10.233.0.148/16 brd 10.233.255.255 scope global tun0 > > > > > > The src address of the tunnel is the IP address of eth0. > > > Routing Rules > > > > 0: from all lookup local > > 32766: from all lookup main > > 32767: from all lookup default > > > > Table default: > > > > > > Table local: > > > > broadcast 192.168.1.0 dev eth0 proto kernel scope link src 192.168.1.2 > > broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 > > local 192.168.1.2 dev eth0 proto kernel scope host src 192.168.1.2 > > broadcast 10.233.255.255 dev tun0 proto kernel scope link src > > 10.233.0.148 > > broadcast 10.233.0.0 dev tun0 proto kernel scope link src 10.233.0.148 > > local 10.233.0.148 dev tun0 proto kernel scope host src 10.233.0.148 > > broadcast 192.168.1.255 dev eth0 proto kernel scope link src > 192.168.1.2 > > broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 > > local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 > > local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 > > > > Table main: > > > > 94.231.84.80 via 192.168.1.1 dev eth0 <==========================> > 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2 > metric > > 202 > > 10.233.0.0/16 dev tun0 proto kernel scope link src 10.233.0.148 > > 127.0.0.0/8 dev lo scope link > > 0.0.0.0/1 via 10.233.0.1 dev tun0 > > 128.0.0.0/1 via 10.233.0.1 dev tun0 > > default via 192.168.1.1 dev eth0 metric 202 > > > > > Which makes sense since the connection would be routed out of eth0 by the > first route in the main table. > > Conclusion. Either: > > a) The tunnel was established before Shorewall started. > b) Something is *really* wrong with Netfilter on this system. > > -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 \________________________________________________ > > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
I typically just use pastebin but when Tom said post it, I didn''t stop to think... I''m using Gmail to post, so I haven''t looked at settings to disable HTML, I just leave it alone for other emails I use... THANKS On Tue, Jul 26, 2011 at 4:22 PM, <peasthope@shaw.ca> wrote:> Hello Das, > > > You told me in the last email to post the entire dump, I assumed that > meant > > to just paste it into the email? > > HTML in email, when plain text will suffice, is generally viewed as bad > etiquette. Similarly for RTF. One atop the other is un-etiquette squared. > Can HTML be turned off in your mailer? RTF? > > Also, your message, which I reply to, is a top-post. > http://en.wikipedia.org/wiki/Posting_style > > Also, if you have Web space, as provided by many ISPs, you might consider > putting a dump there and providing a link in the pertinent emessage. > > None of this is catastrophic. Hopefully a learning process. > > Regards, ... Peter E. > > > [-- > Telephone 1 360 450 2132. bcc: peasthope at shaw.ca > Shop pages http://carnot.yi.org/ accessible as long as the old drives > survive. > Personal pages http://members.shaw.ca/peasthope/ . > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hello Das,> You told me in the last email to post the entire dump, I assumed that meant > to just paste it into the email?HTML in email, when plain text will suffice, is generally viewed as bad etiquette. Similarly for RTF. One atop the other is un-etiquette squared. Can HTML be turned off in your mailer? RTF? Also, your message, which I reply to, is a top-post. http://en.wikipedia.org/wiki/Posting_style Also, if you have Web space, as provided by many ISPs, you might consider putting a dump there and providing a link in the pertinent emessage. None of this is catastrophic. Hopefully a learning process. Regards, ... Peter E. [-- Telephone 1 360 450 2132. bcc: peasthope at shaw.ca Shop pages http://carnot.yi.org/ accessible as long as the old drives survive. Personal pages http://members.shaw.ca/peasthope/ . ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Jul 26, 2011, at 6:35 PM, Das wrote:> I typically just use pastebin but when Tom said post it, I didn''t stop to think…A common failure...> > I''m using Gmail to post, so I haven''t looked at settings to disable HTML, I just leave it alone for other emails I use…We have what I believe are very clear instructions for asking for help with Shorewall - they are at http://www.shorewall.net/support.htm#Guidelines. They specifically ask that the output of ''shorewall dump'' be forwarded *as an attachment*. Trying to look at a dump that has been folded, spindled and mutilated by your mailer is no fun; and a mail reader is certainly *not* the ideal tools for examining this type of complex information. -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Jul 26, 2011, at 5:51 PM, Das wrote:> Sorry what? ---> Unbelievable -- Shorewall dump output embedded in an HTML/RTF email message. > > You told me in the last email to post the entire dump, I assumed that meant to just paste it into the email?That is covered in my response to Peter Easthope''s post.> > a) The tunnel was established before Shorewall started. > > I put Shorewall into a slackware package that has /etc/rc.d/rc.firewall and rc.shorewall so shorewall starts up when my system boots and is always running from the beginning.Yep -- and I suspect that someone at Slackware finally came to their senses and invoke that script *before* starting OpenVPN.> > b) Something is *really* wrong with Netfilter on this system. > > Like any distro, if someone hasn''t touched anything, then what could be wrong and how could there be something wrong? I thought netfilter on all distros works out the box…All distros are not the same.> > As I mentioned before, this works also on Arch the same way... > > I have Slack on a backup image, it only takes me 5mins to install it and everything back up and running, so it''s not a problem and I''m more then willing to install any distro of your choice that you know out the box is going to work and not have any problems with netfilter so that we can rule that out, because I don''t believe it''s this...… Miles of quoted stuff deleted…. It is not my responsibility to police the order in which all distributions (including Arch and Slackware) start services at boot. If you have a problem with that order, I can''t change it -- only the distro can. -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hi, Sorry for the dump... Shorewall runs at startup on my box, always has... I just mentioned give me a distro that you feel comfortable with, if you felt like it was a problem with a distro/netfilter being used... So far I''ve used this on 2 distros, Arch and Slackware and two versions of Slack, 13.1 and 13.37 everything working the same... I didn''t think netflter would vary much from distro to distro... THANKS On Tue, Jul 26, 2011 at 5:25 PM, Tom Eastep <teastep@shorewall.net> wrote:> > On Jul 26, 2011, at 5:51 PM, Das wrote: > > Sorry what? ---> Unbelievable -- Shorewall dump output embedded in an > HTML/RTF email message. > > You told me in the last email to post the entire dump, I assumed that meant > to just paste it into the email? > > > That is covered in my response to Peter Easthope''s post. > > > a) The tunnel was established before Shorewall started. > > I put Shorewall into a slackware package that has /etc/rc.d/rc.firewall and > rc.shorewall so shorewall starts up when my system boots and is always > running from the beginning. > > > Yep -- and I suspect that someone at Slackware finally came to their senses > and invoke that script *before* starting OpenVPN. > > > b) Something is *really* wrong with Netfilter on this system. > > Like any distro, if someone hasn''t touched anything, then what could be > wrong and how could there be something wrong? I thought netfilter on all > distros works out the box… > > > All distros are not the same. > > > As I mentioned before, this works also on Arch the same way... > > I have Slack on a backup image, it only takes me 5mins to install it and > everything back up and running, so it''s not a problem and I''m more then > willing to install any distro of your choice that you know out the box is > going to work and not have any problems with netfilter so that we can rule > that out, because I don''t believe it''s this... > > > … Miles of quoted stuff deleted…. > > It is not my responsibility to police the order in which all distributions > (including Arch and Slackware) start services at boot. If you have a problem > with that order, I can''t change it -- only the distro can. > > -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 \________________________________________________ > > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hi Forgot to ask, was the dump ok to read, or would you like me to attach it to the email or put it on pastebin? THANKS On Tue, Jul 26, 2011 at 6:02 PM, Das <dasfox@gmail.com> wrote:> Hi, > > Sorry for the dump... > > Shorewall runs at startup on my box, always has... > > I just mentioned give me a distro that you feel comfortable with, if you > felt like it was a problem with a distro/netfilter being used... > > So far I''ve used this on 2 distros, Arch and Slackware and two versions of > Slack, 13.1 and 13.37 everything working the same... > > I didn''t think netflter would vary much from distro to distro... > > > THANKS > > > On Tue, Jul 26, 2011 at 5:25 PM, Tom Eastep <teastep@shorewall.net> wrote: > >> >> On Jul 26, 2011, at 5:51 PM, Das wrote: >> >> Sorry what? ---> Unbelievable -- Shorewall dump output embedded in an >> HTML/RTF email message. >> >> You told me in the last email to post the entire dump, I assumed that >> meant to just paste it into the email? >> >> >> That is covered in my response to Peter Easthope''s post. >> >> >> a) The tunnel was established before Shorewall started. >> >> I put Shorewall into a slackware package that has /etc/rc.d/rc.firewall >> and rc.shorewall so shorewall starts up when my system boots and is always >> running from the beginning. >> >> >> Yep -- and I suspect that someone at Slackware finally came to their >> senses and invoke that script *before* starting OpenVPN. >> >> >> b) Something is *really* wrong with Netfilter on this system. >> >> Like any distro, if someone hasn''t touched anything, then what could be >> wrong and how could there be something wrong? I thought netfilter on all >> distros works out the box… >> >> >> All distros are not the same. >> >> >> As I mentioned before, this works also on Arch the same way... >> >> I have Slack on a backup image, it only takes me 5mins to install it and >> everything back up and running, so it''s not a problem and I''m more then >> willing to install any distro of your choice that you know out the box is >> going to work and not have any problems with netfilter so that we can rule >> that out, because I don''t believe it''s this... >> >> >> … Miles of quoted stuff deleted…. >> >> It is not my responsibility to police the order in which all distributions >> (including Arch and Slackware) start services at boot. If you have a problem >> with that order, I can''t change it -- only the distro can. >> >> -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 \________________________________________________ >> >> >> >> >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don''t ask for help often. >> Plus, you''ll get a chance to win $100 to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >> >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hi, By the way I''m not talking about running an OpenVPN server I just run OpenVPN as a client connecting to a VPN service, I mentioned this before... Because you said; Yep -- and I suspect that someone at Slackware finally came to their senses and invoke that script *before* starting OpenVPN. When I read that, looked like you thought the openvpn server... THANKS On Tue, Jul 26, 2011 at 6:09 PM, Das <dasfox@gmail.com> wrote:> Hi > > Forgot to ask, was the dump ok to read, or would you like me to attach it > to the email or put it on pastebin? > > > THANKS > > > > On Tue, Jul 26, 2011 at 6:02 PM, Das <dasfox@gmail.com> wrote: > >> Hi, >> >> Sorry for the dump... >> >> Shorewall runs at startup on my box, always has... >> >> I just mentioned give me a distro that you feel comfortable with, if you >> felt like it was a problem with a distro/netfilter being used... >> >> So far I''ve used this on 2 distros, Arch and Slackware and two versions of >> Slack, 13.1 and 13.37 everything working the same... >> >> I didn''t think netflter would vary much from distro to distro... >> >> >> THANKS >> >> >> On Tue, Jul 26, 2011 at 5:25 PM, Tom Eastep <teastep@shorewall.net>wrote: >> >>> >>> On Jul 26, 2011, at 5:51 PM, Das wrote: >>> >>> Sorry what? ---> Unbelievable -- Shorewall dump output embedded in an >>> HTML/RTF email message. >>> >>> You told me in the last email to post the entire dump, I assumed that >>> meant to just paste it into the email? >>> >>> >>> That is covered in my response to Peter Easthope''s post. >>> >>> >>> a) The tunnel was established before Shorewall started. >>> >>> I put Shorewall into a slackware package that has /etc/rc.d/rc.firewall >>> and rc.shorewall so shorewall starts up when my system boots and is always >>> running from the beginning. >>> >>> >>> Yep -- and I suspect that someone at Slackware finally came to their >>> senses and invoke that script *before* starting OpenVPN. >>> >>> >>> b) Something is *really* wrong with Netfilter on this system. >>> >>> Like any distro, if someone hasn''t touched anything, then what could be >>> wrong and how could there be something wrong? I thought netfilter on all >>> distros works out the box… >>> >>> >>> All distros are not the same. >>> >>> >>> As I mentioned before, this works also on Arch the same way... >>> >>> I have Slack on a backup image, it only takes me 5mins to install it and >>> everything back up and running, so it''s not a problem and I''m more then >>> willing to install any distro of your choice that you know out the box is >>> going to work and not have any problems with netfilter so that we can rule >>> that out, because I don''t believe it''s this... >>> >>> >>> … Miles of quoted stuff deleted…. >>> >>> It is not my responsibility to police the order in which all >>> distributions (including Arch and Slackware) start services at boot. If you >>> have a problem with that order, I can''t change it -- only the distro can. >>> >>> -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 \________________________________________________ >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Got Input? Slashdot Needs You. >>> Take our quick survey online. Come on, we don''t ask for help often. >>> Plus, you''ll get a chance to win $100 to spend on ThinkGeek. >>> http://p.sf.net/sfu/slashdot-survey >>> _______________________________________________ >>> Shorewall-users mailing list >>> Shorewall-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/shorewall-users >>> >>> >> >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Tue, 2011-07-26 at 18:48 -1000, Das wrote:> By the way I''m not talking about running an OpenVPN server I just run > OpenVPN as a client connecting to a VPN service, I mentioned this > before... > > Because you said; > > Yep -- and I suspect that someone at Slackware finally came to their > senses and invoke that script *before* starting OpenVPN. > > When I read that, looked like you thought the openvpn server...I believe that if you read everything that I wrote in my last two emails, you could hardly imagine that I was under that misapprehension. -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hi, Ok, well saying Netfilter is messed up and without any further explaination makes this hard to understand what you think is messed up. After all netfilter is a kernel framework and I tested this on two different distros and two different versions of Slackware all on the default kernels that ship with that distro, so I''m at a loss to understand how that is possible... THANKS On Wed, Jul 27, 2011 at 3:03 AM, Tom Eastep <teastep@shorewall.net> wrote:> On Tue, 2011-07-26 at 18:48 -1000, Das wrote: > > > By the way I''m not talking about running an OpenVPN server I just run > > OpenVPN as a client connecting to a VPN service, I mentioned this > > before... > > > > Because you said; > > > > Yep -- and I suspect that someone at Slackware finally came to their > > senses and invoke that script *before* starting OpenVPN. > > > > When I read that, looked like you thought the openvpn server... > > I believe that if you read everything that I wrote in my last two > emails, you could hardly imagine that I was under that misapprehension. > > -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 \________________________________________________ > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Jul 27, 2011, at 3:21 PM, Das wrote:> Hi, > > Ok, well saying Netfilter is messed up and without any further explaination makes this hard to understand what you think is messed up. After all netfilter is a kernel framework and I tested this on two different distros and two different versions of Slackware all on the default kernels that ship with that distro, so I''m at a loss to understand how that is possible… >I didn''t say Netfilter messed up -- I''m betting on my solution a) -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Jul 27, 2011, at 4:18 PM, Tom Eastep wrote:> > I didn''t say Netfilter messed up -- I''m betting on my solution a)And to prove it: a) Stop OpenVPN b) Wait 10 Minutes c) Try to start OpenVPN -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hi Tom, Sorry getting lost now, been at this with other Slackware users, so I''ve gotten quite spun around with this for the past few weeks. Let me ask this over, or another way, if I did before and sorry if I''m repeating myself. I only use OpenVPN as a client connecting to a VPN service, so will the 3 files below as you see them work after I''ve connect to OpenVPN? Because when I showed this to another Slackware user that seemed quite experienced with iptables and I showed him the output of iptables-save, he could not see anything wrong with the 3 files below not working for me. So the 3 files below work for me when I''m connected to OpenVPN, of course when I need to connect to the VPN, I have to comment the first line in the Policy and uncomment the second line, so how you see it now, this is after I''ve connected and I''ve restarted shorewall... So for me I do not need a host, tunnels or rules to make the connection work.... Stopping and starting for 10 mins. doesn''t do anything, everything works just fine for me the way you see it below, once I''m on the VPN... THANKS *INTERFACES* ############################################################################### #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,tcpflags,logmartians,nosmurfs net wlan0 detect dhcp,tcpflags,logmartians,nosmurfs # OpenVPN Interface vpn tun0 detect vpn tap0 detect * POLICY* ############################################################################### #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: # LEVEL BURST MASK # # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules* $FW net DROP info* # Allow NET Zone when not on VPN - (Allow all connection requests from the firewall to the Internet)* #$FW net ACCEPT** * # Allow this machine to access the VPN ZONE for everything $FW vpn ACCEPT # Block anything from the NET ZONE to all other zones - (Drop (ignore) all connection requests from the Internet to your firewall) net all DROP info # Block from using another connection net net NONE # # The FOLLOWING POLICY MUST BE LAST # # Block everything else - (Reject all other connection requests (Shorewall requires this catchall policy) all all REJECT info *ZONE* ############################################################################### #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 #vpn ipsec vpn ipv4 On Wed, Jul 27, 2011 at 1:50 PM, Tom Eastep <teastep@shorewall.net> wrote:> > On Jul 27, 2011, at 4:18 PM, Tom Eastep wrote: > > > I didn''t say Netfilter messed up -- I''m betting on my solution a) > > > And to prove it: > > a) Stop OpenVPN > b) Wait 10 Minutes > c) Try to start OpenVPN > > -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 \________________________________________________ > > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hello, you need a rule to allow communication from your firewall to your openvpnserver. /etc/shorewall/rules # # openvpnclient to any openvpnserver # OpenVPN/ACCEPT $FW net or /etc/shorewall/rules # # openvpnclient to one openvpnserver (e.q. 203.0.113.1) # OpenVPN/ACCEPT $FW net:203.0.113.1 Best regards Joerg On Wednesday 27 July 2011 21:51:50 Das wrote:> Hi Tom, > > Sorry getting lost now, been at this with other Slackware users, so I''ve > gotten quite spun around with this for the past few weeks. > > Let me ask this over, or another way, if I did before and sorry if I''m > repeating myself. I only use OpenVPN as a client connecting to a VPN > service, so will the 3 files below as you see them work after I''ve connect > to OpenVPN? Because when I showed this to another Slackware user that seemed > quite experienced with iptables and I showed him the output of > iptables-save, he could not see anything wrong with the 3 files below not > working for me. > > So the 3 files below work for me when I''m connected to OpenVPN, of course > when I need to connect to the VPN, I have to comment the first line in the > Policy and uncomment the second line, so how you see it now, this is after > I''ve connected and I''ve restarted shorewall... > > So for me I do not need a host, tunnels or rules to make the connection > work.... > > Stopping and starting for 10 mins. doesn''t do anything, everything works > just fine for me the way you see it below, once I''m on the VPN... > > > THANKS > > > > *INTERFACES* > ############################################################################ > ### #ZONE INTERFACE BROADCAST OPTIONS > > net eth0 detect dhcp,tcpflags,logmartians,nosmurfs > net wlan0 detect dhcp,tcpflags,logmartians,nosmurfs > > # OpenVPN Interface > vpn tun0 detect > vpn tap0 detect > > * > POLICY* > ############################################################################ > ### #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: > # LEVEL BURST MASK > # > # Block this machine from accessing NET ZONE accept for exceptions in > /etc/shorewall/rules* > $FW net DROP info* > > # Allow NET Zone when not on VPN - (Allow all connection requests from the > firewall to the Internet)* > #$FW net ACCEPT** > * > # Allow this machine to access the VPN ZONE for everything > $FW vpn ACCEPT > > # Block anything from the NET ZONE to all other zones - (Drop (ignore) all > connection requests from the Internet to your firewall) > net all DROP info > > # Block from using another connection > net net NONE > > # > # The FOLLOWING POLICY MUST BE LAST > # > > # Block everything else - (Reject all other connection requests (Shorewall > requires this catchall policy) > all all REJECT info > > > *ZONE* > ############################################################################ > ### #ZONE TYPE OPTIONS IN OUT > # OPTIONS OPTIONS > fw firewall > net ipv4 > #vpn ipsec > vpn ipv4 > > On Wed, Jul 27, 2011 at 1:50 PM, Tom Eastep <teastep@shorewall.net> wrote: > > On Jul 27, 2011, at 4:18 PM, Tom Eastep wrote: > > > > > > I didn''t say Netfilter messed up -- I''m betting on my solution a) > > > > > > And to prove it: > > > > a) Stop OpenVPN > > b) Wait 10 Minutes > > c) Try to start OpenVPN > > > > -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 \________________________________________________ > > > > > > > > > > ------------------------------------------------------------------------ > > ------ Got Input? Slashdot Needs You. > > Take our quick survey online. Come on, we don''t ask for help often. > > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > > http://p.sf.net/sfu/slashdot-survey > > _______________________________________________ > > Shorewall-users mailing list > > Shorewall-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Wed, 2011-07-27 at 21:51 -1000, Das wrote:> Sorry getting lost now, been at this with other Slackware users, soHi > Tom, > > I''ve gotten quite spun around with this for the past few weeks. > > Let me ask this over, or another way, if I did before and sorry if I''m > repeating myself. I only use OpenVPN as a client connecting to a VPN > service, so will the 3 files below as you see them work after I''ve > connect to OpenVPN? Because when I showed this to another Slackware > user that seemed quite experienced with iptables and I showed him the > output of iptables-save, he could not see anything wrong with the 3 > files below not working for me. > > So the 3 files below work for me when I''m connected to OpenVPN, of > course when I need to connect to the VPN, I have to comment the first > line in the Policy and uncomment the second line, so how you see it > now, this is after I''ve connected and I''ve restarted shorewall... > > So for me I do not need a host, tunnels or rules to make the > connection work....Of course you don''t - you could even: - shorewall clear - /etc/init.d/openvpn start - shorewall start But why? Why not set up the Shorewall configuration so that you don''t have to fiddle with the policies if your current init scripts happen to start OpenVPN after they start Shorewall, or if you need to restart OpenVPN? -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hi, This is what I''ve been trying to explain, with just the interface, policy and zones I can make this work on any distro, I don''t need rules to connect to OpenVPN or stay online with it... It seems like to me for OpenVPN as long as you have an interface, vpn running on tun0, defined in the policy to allow this connection, with the zone vpn ipv4, you can connect to an OpenVPN server as a client and then make the changes in the Policy as I explained before once you''ve connected, restart Shorewall and have the connection routed over the tunnel... THANKS On Thu, Jul 28, 2011 at 12:21 AM, Joerg Gollnick < code4shorewall+list@wurzelbenutzer.de> wrote:> Hello, > you need a rule to allow communication from your firewall to your > openvpnserver. > > /etc/shorewall/rules > # > # openvpnclient to any openvpnserver > # > OpenVPN/ACCEPT $FW net > or > > /etc/shorewall/rules > # > # openvpnclient to one openvpnserver (e.q. 203.0.113.1) > # > OpenVPN/ACCEPT $FW net:203.0.113.1 > > Best regards Joerg > > On Wednesday 27 July 2011 21:51:50 Das wrote: > > Hi Tom, > > > > Sorry getting lost now, been at this with other Slackware users, so I''ve > > gotten quite spun around with this for the past few weeks. > > > > Let me ask this over, or another way, if I did before and sorry if I''m > > repeating myself. I only use OpenVPN as a client connecting to a VPN > > service, so will the 3 files below as you see them work after I''ve > connect > > to OpenVPN? Because when I showed this to another Slackware user that > seemed > > quite experienced with iptables and I showed him the output of > > iptables-save, he could not see anything wrong with the 3 files below not > > working for me. > > > > So the 3 files below work for me when I''m connected to OpenVPN, of course > > when I need to connect to the VPN, I have to comment the first line in > the > > Policy and uncomment the second line, so how you see it now, this is > after > > I''ve connected and I''ve restarted shorewall... > > > > So for me I do not need a host, tunnels or rules to make the connection > > work.... > > > > Stopping and starting for 10 mins. doesn''t do anything, everything works > > just fine for me the way you see it below, once I''m on the VPN... > > > > > > THANKS > > > > > > > > *INTERFACES* > > > ############################################################################ > > ### #ZONE INTERFACE BROADCAST OPTIONS > > > > net eth0 detect > dhcp,tcpflags,logmartians,nosmurfs > > net wlan0 detect > dhcp,tcpflags,logmartians,nosmurfs > > > > # OpenVPN Interface > > vpn tun0 detect > > vpn tap0 detect > > > > * > > POLICY* > > > ############################################################################ > > ### #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: > > # LEVEL BURST MASK > > # > > # Block this machine from accessing NET ZONE accept for exceptions in > > /etc/shorewall/rules* > > $FW net DROP info* > > > > # Allow NET Zone when not on VPN - (Allow all connection requests from > the > > firewall to the Internet)* > > #$FW net ACCEPT** > > * > > # Allow this machine to access the VPN ZONE for everything > > $FW vpn ACCEPT > > > > # Block anything from the NET ZONE to all other zones - (Drop (ignore) > all > > connection requests from the Internet to your firewall) > > net all DROP info > > > > # Block from using another connection > > net net NONE > > > > # > > # The FOLLOWING POLICY MUST BE LAST > > # > > > > # Block everything else - (Reject all other connection requests > (Shorewall > > requires this catchall policy) > > all all REJECT info > > > > > > *ZONE* > > > ############################################################################ > > ### #ZONE TYPE OPTIONS IN OUT > > # OPTIONS OPTIONS > > fw firewall > > net ipv4 > > #vpn ipsec > > vpn ipv4 > > > > On Wed, Jul 27, 2011 at 1:50 PM, Tom Eastep <teastep@shorewall.net> > wrote: > > > On Jul 27, 2011, at 4:18 PM, Tom Eastep wrote: > > > > > > > > > I didn''t say Netfilter messed up -- I''m betting on my solution a) > > > > > > > > > And to prove it: > > > > > > a) Stop OpenVPN > > > b) Wait 10 Minutes > > > c) Try to start OpenVPN > > > > > > -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 \________________________________________________ > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > ------ Got Input? Slashdot Needs You. > > > Take our quick survey online. Come on, we don''t ask for help often. > > > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > > > http://p.sf.net/sfu/slashdot-survey > > > _______________________________________________ > > > Shorewall-users mailing list > > > Shorewall-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hi, After making the OpenVPN you should have your connection only allowed through the VPN tunnel, for various reasons, most security related... If I make a rule it seems to complicate this process, where as if I just use the interfaces, policy an zones it''s just a simple matter of commenting and uncommenting 2 lines in the policy... *This is a regular internet connection, no VPN, you need the policy like this to first establish the VPN, or to just have regular internet connectivity;* # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules #$FW net DROP ULOG # Allow NET Zone when not on VPN - (Allow all connection requests from the firewall to the Internet) $FW net ACCEPT # Allow this machine to access the VPN ZONE for everything $FW vpn ACCEPT *This is now the change in the policy once the VPN connection has been established and all traffic is routed on the VPN, we drop the net and only accept on the vpn; *# Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules $FW net DROP ULOG # Allow NET Zone when not on VPN - (Allow all connection requests from the firewall to the Internet) #$FW net ACCEPT # Allow this machine to access the VPN ZONE for everything $FW vpn ACCEPT So for me, changing the policy like this doesn''t seem complicated, seems actually the simplest method here I can see. Because no matter what you do there is going to be a leak to the Net unless you drop it somewhere once connected to the VPN, so this is why I do it this way, because I don''t understand how it can be done any simpler... So if anyone can show me a simpler way, if there is, that would be great! :) THANKS On Thu, Jul 28, 2011 at 2:51 AM, Tom Eastep <teastep@shorewall.net> wrote:> On Wed, 2011-07-27 at 21:51 -1000, Das wrote: > > > Sorry getting lost now, been at this with other Slackware users, soHi > > Tom, > > > > I''ve gotten quite spun around with this for the past few weeks. > > > > Let me ask this over, or another way, if I did before and sorry if I''m > > repeating myself. I only use OpenVPN as a client connecting to a VPN > > service, so will the 3 files below as you see them work after I''ve > > connect to OpenVPN? Because when I showed this to another Slackware > > user that seemed quite experienced with iptables and I showed him the > > output of iptables-save, he could not see anything wrong with the 3 > > files below not working for me. > > > > So the 3 files below work for me when I''m connected to OpenVPN, of > > course when I need to connect to the VPN, I have to comment the first > > line in the Policy and uncomment the second line, so how you see it > > now, this is after I''ve connected and I''ve restarted shorewall... > > > > So for me I do not need a host, tunnels or rules to make the > > connection work.... > > Of course you don''t - you could even: > > - shorewall clear > - /etc/init.d/openvpn start > - shorewall start > > But why? > > Why not set up the Shorewall configuration so that you don''t have to > fiddle with the policies if your current init scripts happen to start > OpenVPN after they start Shorewall, or if you need to restart OpenVPN? > > -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 \________________________________________________ > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Thu, 2011-07-28 at 12:28 -1000, Das wrote:> This is what I''ve been trying to explain, with just the interface, > policy and zones I can make this work on any distro, I don''t need > rules to connect to OpenVPN or stay online with it...And we''ve been trying to explain that if you add an entry to the tunnels file, then it will work on any distro and you won''t have to screw around with changing to policy file at all. But it is, of course, up to you. -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hi Tom, Ok I''m sorry, I truly apologize here about this... YES I''m all ears you certainly know better then me... Can you please show me how I should write the tunnels? And then what would I change in the policy since I don''t need to mess with it, would I then remove the first line? # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules *#$FW net DROP info* # Allow NET Zone when not on VPN - (Allow all connection requests from the firewall to the Internet) *$FW net ACCEPT * # Allow this machine to access the VPN ZONE for everything $FW vpn ACCEPT THANKS On Thu, Jul 28, 2011 at 12:44 PM, Tom Eastep <teastep@shorewall.net> wrote:> On Thu, 2011-07-28 at 12:28 -1000, Das wrote: > > > This is what I''ve been trying to explain, with just the interface, > > policy and zones I can make this work on any distro, I don''t need > > rules to connect to OpenVPN or stay online with it... > > And we''ve been trying to explain that if you add an entry to the tunnels > file, then it will work on any distro and you won''t have to screw around > with changing to policy file at all. But it is, of course, up to you. > > -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 \________________________________________________ > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Jul 28, 2011, at 5:05 PM, Das wrote:> > Can you please show me how I should write the tunnels? > >Keep this line> # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules > $FW net DROP info > > # Allow this machine to access the VPN ZONE for everything > $FW vpn ACCEPT >And add this line to /etc/shorewall/tunnels openvpnclient net <remote endpoints> The <remote endpoints> can be a network or list of servers that you connect to. -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hi, Ok so this? openvpnclient net <actual IP I connect to?> So if I make the tunnels like above, to the actual IP and then I make the policy like below: # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules $FW net DROP ULOG # Allow this machine to access the VPN ZONE for everything $FW vpn ACCEPT This isn''t doing anything... Am I understanding this correct that those two lines with the tunnels is all I need now in the policy, if so, then how is someone suppose to connect to the internet over eth0 or wlan0 net if it''s not being accepted first? I''m using a computer that I want to have normal internet connectivity and I do not see how that is possible with only those 2 lines above, also like that you can''t connect to the VPN, you have to accept the net first then drop it later once connected to the vpn, so I still do not see what the tunnels is doing... 1. I use a broadband internet connection for a desktop/laptop. 2. Besides normal internet activities I also use OpenVPN. 3. When using OpenVPN I want to protect the computer from being able to get back online if the VPN connection drops, this is the objective here and that is why I have the policy like that, because as you can see, once I am connected to the vpn I then drop the net and no longer accept it and like that, if the vpn connection goes down, I can''t get back online and that is what I want, the VPN is for protection, so of course I don''t want to be online without it... Because of 1-3 this is why I make the policy like this, I see no other way around this, or I''m very lost here, or I''m not explaining this very well for others to understand what I''m trying to do... THANKS On Thu, Jul 28, 2011 at 2:59 PM, Tom Eastep <teastep@shorewall.net> wrote:> > On Jul 28, 2011, at 5:05 PM, Das wrote: > > > Can you please show me how I should write the tunnels? > > > > Keep this line > > # Block this machine from accessing NET ZONE accept for exceptions in > /etc/shorewall/rules > *$FW net DROP info** > * > # Allow this machine to access the VPN ZONE for everything > $FW vpn ACCEPT > > > And add this line to /etc/shorewall/tunnels > > openvpnclient net <remote endpoints> > > The <remote endpoints> can be a network or list of servers that you connect > to. > > -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 \________________________________________________ > > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Jul 28, 2011, at 6:38 PM, Das wrote:> Hi, > > Ok so this? > > openvpnclient net <actual IP I connect to?> > > So if I make the tunnels like above, to the actual IP and then I make the policy like below: > > # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules > $FW net DROP ULOG > > # Allow this machine to access the VPN ZONE for everything > $FW vpn ACCEPT > > This isn''t doing anything... > > Am I understanding this correct that those two lines with the tunnels is all I need now in the policy, if so, then how is someone suppose to connect to the internet over eth0 or wlan0 net if it''s not being accepted first? > > I''m using a computer that I want to have normal internet connectivity and I do not see how that is possible with only those 2 lines above, also like that you can''t connect to the VPN, you have to accept the net first then drop it later once connected to the vpn, so I still do not see what the tunnels is doing... > > > 1. I use a broadband internet connection for a desktop/laptop. > 2. Besides normal internet activities I also use OpenVPN. > 3. When using OpenVPN I want to protect the computer from being able to get back online if the VPN connection drops, this is the objective here and that is why I have the policy like that, because as you can see, once I am connected to the vpn I then drop the net and no longer accept it and like that, if the vpn connection goes down, I can''t get back online and that is what I want, the VPN is for protection, so of course I don''t want to be online without it... > > Because of 1-3 this is why I make the policy like this, I see no other way around this, or I''m very lost here, or I''m not explaining this very well for others to understand what I''m trying to do...I''m done with this. Maybe someone else on the list has the patience to carry on. -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 \________________________________________________ ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Well that''s just great... What about my patience as a user that no one really seems to be paying attention to what I''m asking? Please go back and show me in one reply where you have responded to what I''m trying to accomplish, because you haven''t and then you blame me for the run around... In my 6th reply I said I just chalked it up to some bug somewhere and just reinstalled my image and got it all working the way I liked... To be honest, I don''t even think you know what I''m doing or have been asking, because all someone has to do is simply look at someone''s files to answer this... Now that I''m starting to see some of this, I see it''s not so complicated, but I don''t take claim to fame that I know everything either, this is why I''m asking... Please don''t complain about patience when you, yourself are not paying attention and then you on top of it as the developer should try to be patient especially when you are not paying attention... I come to your IRC channel in good spirit, chat, I''m being friendly and there you also badger me and harp on me there, you and padtwk and you didn''t even get it there in the IRC channel, so I listened to you, joined the mailing list and now you can''t even handle one week of questions? I''m sorry you''re the developer and you seem to be the only one around here answering questions, but please don''t blame me for that. Your not a kid, you''re an older man that should be patient and helpful and friendly, you''re a Linux developer that people look up to and use your product, so no I don''t expect to be always getting help from the developer, but at least since you are, the least you could do is be considerate and show some respect as I''ve shown towards you... So many times I said THANKS Tom, Thank you Tom for all your help, over and over showing you respect and how you are appreciated and now this... :( You know I could really understand throwing up your arms in disgust and giving up when someone has treated you badly, or been rude and disrespectful in anyway, but I have never once done so. So here I am the hard working student trying my hardest and you loose patience... The truth is, the Policy seems to override everything as I''ve tried to explain that no one seems to be getting... On Thu, Jul 28, 2011 at 5:07 PM, Tom Eastep <teastep@shorewall.net> wrote:> > On Jul 28, 2011, at 6:38 PM, Das wrote: > > Hi, > > Ok so this? > > openvpnclient net <actual IP I connect to?> > > So if I make the tunnels like above, to the actual IP and then I make the > policy like below: > > # Block this machine from accessing NET ZONE accept for exceptions in > /etc/shorewall/rules > $FW net DROP ULOG > > # Allow this machine to access the VPN ZONE for everything > $FW vpn ACCEPT > > This isn''t doing anything... > > Am I understanding this correct that those two lines with the tunnels is > all I need now in the policy, if so, then how is someone suppose to connect > to the internet over eth0 or wlan0 net if it''s not being accepted first? > > I''m using a computer that I want to have normal internet connectivity and I > do not see how that is possible with only those 2 lines above, also like > that you can''t connect to the VPN, you have to accept the net first then > drop it later once connected to the vpn, so I still do not see what the > tunnels is doing... > > > 1. I use a broadband internet connection for a desktop/laptop. > 2. Besides normal internet activities I also use OpenVPN. > 3. When using OpenVPN I want to protect the computer from being able to get > back online if the VPN connection drops, this is the objective here and that > is why I have the policy like that, because as you can see, once I am > connected to the vpn I then drop the net and no longer accept it and like > that, if the vpn connection goes down, I can''t get back online and that is > what I want, the VPN is for protection, so of course I don''t want to be > online without it... > > Because of 1-3 this is why I make the policy like this, I see no other way > around this, or I''m very lost here, or I''m not explaining this very well for > others to understand what I''m trying to do... > > > I''m done with this. > > Maybe someone else on the list has the patience to carry on. > > -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 \________________________________________________ > > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Tom. You are the man. I just joined this list a couple of weeks and have been following everything. Thanks for your help to the world. Das, you are the man. Don''t give up. I think you are right, you keep just those policies with the tunnel config. You take away the access to the net via the policy, but, correct me if I''m wrong (someone who isn''t Tom so he can chill,) you do the tunnel config because that opens up access to going out and connecting to the VPN server. What does your routing table say? Do we want the default route to be that of the OpenVPN server so accessing the net goes through it? Or will that blow stuff up? Rj On 7/28/2011 6:38 PM, Das wrote:> Hi, > > Ok so this? > > openvpnclientnet<actual IP I connect to?> > > So if I make the tunnels like above, to the actual IP and then I make > the policy like below: > > # Block this machine from accessing NET ZONE accept for exceptions in > /etc/shorewall/rules > $FW net DROP ULOG > > # Allow this machine to access the VPN ZONE for everything > $FW vpn ACCEPT > > This isn''t doing anything... > > Am I understanding this correct that those two lines with the tunnels > is all I need now in the policy, if so, then how is someone suppose to > connect to the internet over eth0 or wlan0 net if it''s not being > accepted first? > > I''m using a computer that I want to have normal internet connectivity > and I do not see how that is possible with only those 2 lines above, > also like that you can''t connect to the VPN, you have to accept the > net first then drop it later once connected to the vpn, so I still do > not see what the tunnels is doing... > > > 1. I use a broadband internet connection for a desktop/laptop. > 2. Besides normal internet activities I also use OpenVPN. > 3. When using OpenVPN I want to protect the computer from being able > to get back online if the VPN connection drops, this is the objective > here and that is why I have the policy like that, because as you can > see, once I am connected to the vpn I then drop the net and no longer > accept it and like that, if the vpn connection goes down, I can''t get > back online and that is what I want, the VPN is for protection, so of > course I don''t want to be online without it... > > Because of 1-3 this is why I make the policy like this, I see no other > way around this, or I''m very lost here, or I''m not explaining this > very well for others to understand what I''m trying to do... > > > THANKS > > > On Thu, Jul 28, 2011 at 2:59 PM, Tom Eastep <teastep@shorewall.net > <mailto:teastep@shorewall.net>> wrote: > > > On Jul 28, 2011, at 5:05 PM, Das wrote: >> >> Can you please show me how I should write the tunnels? >> >> > > Keep this line > >> # Block this machine from accessing NET ZONE accept for >> exceptions in /etc/shorewall/rules >> *$FW net DROP info** >> * >> # Allow this machine to access the VPN ZONE for everything >> $FW vpn ACCEPT >> > > And add this line to /etc/shorewall/tunnels > > openvpnclientnet<remote endpoints> > > The <remote endpoints> can be a network or list of servers that > you connect to. > > -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 \________________________________________________ > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > <mailto:Shorewall-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Oh yeah, it is actual IP you connect to. openvpnclient net 68.123.45.213 (I just made that ip up. :) ) On 7/28/2011 6:38 PM, Das wrote:> Hi, > > Ok so this? > > openvpnclientnet<actual IP I connect to?> > > So if I make the tunnels like above, to the actual IP and then I make > the policy like below: > > # Block this machine from accessing NET ZONE accept for exceptions in > /etc/shorewall/rules > $FW net DROP ULOG > > # Allow this machine to access the VPN ZONE for everything > $FW vpn ACCEPT > > This isn''t doing anything... > > Am I understanding this correct that those two lines with the tunnels > is all I need now in the policy, if so, then how is someone suppose to > connect to the internet over eth0 or wlan0 net if it''s not being > accepted first? > > I''m using a computer that I want to have normal internet connectivity > and I do not see how that is possible with only those 2 lines above, > also like that you can''t connect to the VPN, you have to accept the > net first then drop it later once connected to the vpn, so I still do > not see what the tunnels is doing... > > > 1. I use a broadband internet connection for a desktop/laptop. > 2. Besides normal internet activities I also use OpenVPN. > 3. When using OpenVPN I want to protect the computer from being able > to get back online if the VPN connection drops, this is the objective > here and that is why I have the policy like that, because as you can > see, once I am connected to the vpn I then drop the net and no longer > accept it and like that, if the vpn connection goes down, I can''t get > back online and that is what I want, the VPN is for protection, so of > course I don''t want to be online without it... > > Because of 1-3 this is why I make the policy like this, I see no other > way around this, or I''m very lost here, or I''m not explaining this > very well for others to understand what I''m trying to do... > > > THANKS > > > On Thu, Jul 28, 2011 at 2:59 PM, Tom Eastep <teastep@shorewall.net > <mailto:teastep@shorewall.net>> wrote: > > > On Jul 28, 2011, at 5:05 PM, Das wrote: >> >> Can you please show me how I should write the tunnels? >> >> > > Keep this line > >> # Block this machine from accessing NET ZONE accept for >> exceptions in /etc/shorewall/rules >> *$FW net DROP info** >> * >> # Allow this machine to access the VPN ZONE for everything >> $FW vpn ACCEPT >> > > And add this line to /etc/shorewall/tunnels > > openvpnclientnet<remote endpoints> > > The <remote endpoints> can be a network or list of servers that > you connect to. > > -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 \________________________________________________ > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > <mailto:Shorewall-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Let me show this over and say what I''m doing. With the 3 files below that is how I connect to the internet and go online via eth0 or wlan0 it''s also how I need the files so I can connect to OpenVPN. *INTERFACES* ############################################################################# #ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,tcpflags,logmartians,nosmurfs net wlan0 detect dhcp,tcpflags,logmartians,nosmurfs # OpenVPN Interface vpn tun0 detect vpn tap0 detect * POLICY* ############################################################################### #SOURCE DEST POLICY LOG LIMIT: CONNLIMIT: # LEVEL BURST MASK # # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules *#$FW net DROP info* # Allow NET Zone when not on VPN - (Allow all connection requests from the firewall to the Internet) *$FW net ACCEPT * # Allow this machine to access the VPN ZONE for everything $FW vpn ACCEPT # Block anything from the NET ZONE to all other zones - (Drop (ignore) all connection requests from the Internet to your firewall) net all DROP info # Block from using another connection net net NONE # # The FOLLOWING POLICY MUST BE LAST # # Block everything else - (Reject all other connection requests (Shorewall requires this catchall policy) all all REJECT info *ZONE* ############################################################################### #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 #vpn ipsec vpn ipv4 Now once I''m connected to OpenVPN I comment line 2 in the policy and uncomment line 1 like below (and restart shorewall) # Block this machine from accessing NET ZONE accept for exceptions in /etc/shorewall/rules *$FW net DROP info* # Allow NET Zone when not on VPN - (Allow all connection requests from the firewall to the Internet) *#$FW net ACCEPT* Now if the VPN connection drops I''m not able to get online which is what I want because I use OpenVPN for security. So for me this is working just fine. Now to connect back to the VPN I have to comment line 1 and uncomment line 2 and restart shorewall. This is all I want to know if it''s ok to do things this way for OpenVPN because it works for me without any hosts rules and tunnels... THANKS On Thu, Jul 28, 2011 at 5:53 PM, Ryan Joiner <ryan@joinerlink.com> wrote:> ** > Tom. You are the man. I just joined this list a couple of weeks and have > been following everything. Thanks for your help to the world. > > Das, you are the man. Don''t give up. I think you are right, you keep just > those policies with the tunnel config. You take away the access to the net > via the policy, but, correct me if I''m wrong (someone who isn''t Tom so he > can chill,) you do the tunnel config because that opens up access to going > out and connecting to the VPN server. > > What does your routing table say? Do we want the default route to be that > of the OpenVPN server so accessing the net goes through it? Or will that > blow stuff up? > > Rj > > > On 7/28/2011 6:38 PM, Das wrote: > > Hi, > > Ok so this? > > openvpnclient net <actual IP I connect to?> > > So if I make the tunnels like above, to the actual IP and then I make the > policy like below: > > # Block this machine from accessing NET ZONE accept for exceptions in > /etc/shorewall/rules > $FW net DROP ULOG > > # Allow this machine to access the VPN ZONE for everything > $FW vpn ACCEPT > > This isn''t doing anything... > > Am I understanding this correct that those two lines with the tunnels is > all I need now in the policy, if so, then how is someone suppose to connect > to the internet over eth0 or wlan0 net if it''s not being accepted first? > > I''m using a computer that I want to have normal internet connectivity and I > do not see how that is possible with only those 2 lines above, also like > that you can''t connect to the VPN, you have to accept the net first then > drop it later once connected to the vpn, so I still do not see what the > tunnels is doing... > > > 1. I use a broadband internet connection for a desktop/laptop. > 2. Besides normal internet activities I also use OpenVPN. > 3. When using OpenVPN I want to protect the computer from being able to get > back online if the VPN connection drops, this is the objective here and that > is why I have the policy like that, because as you can see, once I am > connected to the vpn I then drop the net and no longer accept it and like > that, if the vpn connection goes down, I can''t get back online and that is > what I want, the VPN is for protection, so of course I don''t want to be > online without it... > > Because of 1-3 this is why I make the policy like this, I see no other way > around this, or I''m very lost here, or I''m not explaining this very well for > others to understand what I''m trying to do... > > > THANKS > > > On Thu, Jul 28, 2011 at 2:59 PM, Tom Eastep <teastep@shorewall.net> wrote: > >> >> On Jul 28, 2011, at 5:05 PM, Das wrote: >> >> >> Can you please show me how I should write the tunnels? >> >> >> >> Keep this line >> >> # Block this machine from accessing NET ZONE accept for exceptions in >> /etc/shorewall/rules >> *$FW net DROP info** >> * >> # Allow this machine to access the VPN ZONE for everything >> $FW vpn ACCEPT >> >> >> And add this line to /etc/shorewall/tunnels >> >> openvpnclient net <remote endpoints> >> >> The <remote endpoints> can be a network or list of servers that you >> connect to. >> >> -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 \________________________________________________ >> >> >> >> >> ------------------------------------------------------------------------------ >> Got Input? Slashdot Needs You. >> Take our quick survey online. Come on, we don''t ask for help often. >> Plus, you''ll get a chance to win $100 to spend on ThinkGeek. >> http://p.sf.net/sfu/slashdot-survey >> _______________________________________________ >> Shorewall-users mailing list >> Shorewall-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/shorewall-users >> >> > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek.http://p.sf.net/sfu/slashdot-survey > > > _______________________________________________ > Shorewall-users mailing listShorewall-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/shorewall-users > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On Thu, 28 Jul 2011 20:58:13 -0700, Ryan Joiner wrote: just a note that thunderbird makes multiple reference headers :/ try update to 5.x this bug breaks threaded folder lists ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Hello Das, From: Das <dasfox@gmail.com> Date: Thu, 28 Jul 2011 15:38:50 -1000> Hi,<br> > <br> > Ok so this?<br> > <br> > openvpnclient<span style=3D"white-space:pre-wrap"> </span>net<span style=3D> "white-space:pre-wrap"> </span><actual IP I connect to?><br> > ...I don''t want to seem obnoxious or ridiculing but wonder why you are still top-posting and sending HTML. Top-posting is easily avoided just by editing your reply. Emission of HTML should be optional in any mailer. Regards, ... Peter E. -- Telephone 1 360 450 2132. bcc: peasthope at shaw.ca Shop pages http://carnot.yi.org/ accessible as long as the old drives survive. Personal pages http://members.shaw.ca/peasthope/ . ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
Ok my bad thanks... On Fri, Jul 29, 2011 at 6:37 AM, <peasthope@shaw.ca> wrote:> > Hello Das, > > From: Das <dasfox@gmail.com> > Date: Thu, 28 Jul 2011 15:38:50 -1000 > > Hi,<br> > > <br> > > Ok so this?<br> > > <br> > > openvpnclient<span style=3D"white-space:pre-wrap"> </span>net<span style=3D> > "white-space:pre-wrap"> </span><actual IP I connect to?><br> > > ... > > I don''t want to seem obnoxious or ridiculing but wonder why you are > still top-posting and sending HTML. Top-posting is easily avoided just > by editing your reply. Emission of HTML should be optional in any mailer. > > Regards, ... Peter E. > > -- > Telephone 1 360 450 2132. bcc: peasthope at shaw.ca > Shop pages http://carnot.yi.org/ accessible as long as the old drives survive. > Personal pages http://members.shaw.ca/peasthope/ . > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
This thread on OpenVPN has made me wonder if I have this setup correctly. (I''m not exactly a shorewall-noobie, but I find much of the shorewall talk difficult to follow.) I have a VPN zone: ---------------------------------- vpn ipv4 ---------------------------------- and a VPN interface ---------------------------------- vpn tun0 detect ---------------------------------- and the following VPN rules ---------------------------------- ACCEPT vpn loc udp 1194 # OpenVPN ACCEPT loc vpn udp 1194 # OpenVPN ACCEPT vpn $FW udp 1194 # OpenVPN ---------------------------------- This seems to work OK. But is it the correct/best way to set it up? -- Timothy Murphy e-mail: gayleard /at/ eircom.net tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
> > This thread on OpenVPN has made me wonder if I have this setup correctly. > (I''m not exactly a shorewall-noobie, > but I find much of the shorewall talk difficult to follow.) > > I have a VPN zone: > ---------------------------------- > vpn ipv4 > ---------------------------------- > and a VPN interface > ---------------------------------- > vpn tun0 detect > ---------------------------------- > and the following VPN rules > ---------------------------------- > ACCEPT vpn loc udp 1194 # OpenVPN > ACCEPT loc vpn udp 1194 # OpenVPN > ACCEPT vpn $FW udp 1194 # OpenVPN > ---------------------------------- > > This seems to work OK. > But is it the correct/best way to set it up? >I''m not exactly sure what you are asking but did you read this? http://www.shorewall.net/OPENVPN.html Simon ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey
On 7/30/2011 5:01 AM, Simon Matter wrote:>> >> This thread on OpenVPN has made me wonder if I have this setup correctly. >> (I''m not exactly a shorewall-noobie, >> but I find much of the shorewall talk difficult to follow.) >> >> I have a VPN zone: >> ---------------------------------- >> vpn ipv4 >> ---------------------------------- >> and a VPN interface >> ---------------------------------- >> vpn tun0 detect >> ---------------------------------- >> and the following VPN rules >> ---------------------------------- >> ACCEPT vpn loc udp 1194 # OpenVPN >> ACCEPT loc vpn udp 1194 # OpenVPN >> ACCEPT vpn $FW udp 1194 # OpenVPN >> ---------------------------------- >> >> This seems to work OK. >> But is it the correct/best way to set it up? >> > > I''m not exactly sure what you are asking but did you read this? > > http://www.shorewall.net/OPENVPN.html > > Simon > > > > ------------------------------------------------------------------------------ > Got Input? Slashdot Needs You. > Take our quick survey online. Come on, we don''t ask for help often. > Plus, you''ll get a chance to win $100 to spend on ThinkGeek. > http://p.sf.net/sfu/slashdot-survey > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-usersI was going to ask about this too, but thought it might have not been the best timing ;). Right now we have 40 or 50 different places running openVPN, some of them where they are bridges over the internet to connect multiple networks together, others are just for client connectivity to their office network. Basically forever we have been doing it exactly as you described above. Where I didn''t put anything in tunnels at all (like the documentation says) but just used the rules instead (like how you have been doing it) Recently I upgraded to the latest version of shorewall and all routing between the the networks completely died, whether it was to networks not being able to talk together or the client connecting in and communicating with the servers in their office. So, I looked at the documentation, added the lines needed in tunnels, completly removed the rule to open up the vpn port (1194) and everything now works perfectly. The version I was on was shorewall-4.4.0-3.noarch.rpm which worked with the rules. The version that i had to create the info in tunnels (according to the documentation) when upgrading was shorewall-4.4.21-1.el5.noarch.rpm. That 4.4.0-3 was from 2009 i believe. I know a lot has changed since then. Thanks to all for contributing and thanks for such a great thing that has been created. Rj ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don''t ask for help often. Plus, you''ll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey