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 <[email protected]> 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 <[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

Reply via email to