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 <[email protected]> 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
> [email protected]
> 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/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
