Am 15.08.2014 um 01:17 schrieb Michael Kress:
>
> Uhm, one case has added to my config and I cannot make it work.
>
> One host in the DMZ zone (192.168.0.15) which is connected over eth0
> (192.168.0.1) should go out over tun1 (vpn) masqueraded as x.x.x.245,
> with all protoco
Am 01.06.2014 um 23:08 schrieb Michael Kress:
>
> OK, all things solved, thanks for pointing me to the right docs.
>
Uhm, one case has added to my config and I cannot make it work.
One host in the DMZ zone (192.168.0.15) which is connected over eth0
(192.168.0.1) should go out over
Am 01.06.2014 18:40, schrieb Tom Eastep:
>
> You also need a masq rule -- see Shorewall FAQ 2.
>
it worked out so well ... just one line in masq does the magic:
eth2 192.168.5.0/24
And I agree with your comment in the FAQ - having the "proper" source
address is a bit nicer, which is why I have
Am 10.05.2014 16:07, schrieb Tom Eastep:
> On 5/9/2014 4:56 PM, Michael Kress wrote:
>> Hi again, sorry, but I'm still having issues with my setup as described
>> in my previous posts (multi-isp setup with openvpn and dsl router).
>> The problem is that if I try to conne
Hi again, sorry, but I'm still having issues with my setup as described
in my previous posts (multi-isp setup with openvpn and dsl router).
The problem is that if I try to connect from LAN (192.168.5.181) to the
VPN ip (x.x.x.245) via a DNAT rule, the request gets forwarded, but the
reply doesn'
Am 03.05.2014 00:03, schrieb Tom Eastep:
> If that is the case, then there is no point in making tun1 a provider
> interface (you never need the default route out of it). Simply configure
> OpenVPN to add a route to x.x.x.245/28 out of tun1 when the VPN is
> brought up.
>
>
Hi Tom, it took me a wh
Am 02.05.2014 16:47, schrieb Tom Eastep:
Is there any case that you want traffic to go out of tun1 other than
traffic destined for x.x.x.245/28?
Hi, no, I do not need any traffic going out tun1 except for the replies
on queries that come in via tun1 and of course test pings from the
firewa
Hi, I'm still having trouble with my setup (multi-isp/openvpn) and it
seems to be a routing problem, the subnets from the DMZ and LAN can't
connect to the outside ... worse: some sites are reachable, some not,
although I have flushed the routing tables. I see no drops or refejcts.
setup:
--
Hi, just curious about a little thing ... sometimes I saw $FW in rules files,
sometimes fw. When using $FW - does it have to be declared in params as FW=fw
?
What is the preferred way? fw or $FW?
TIA
Michael
--
"Accelerate
Am 27.04.2014 22:38, schrieb Michael Kress:
>
> Remaining issue:
> Hosts from 192.168.0.0/24 LAN cannot ping outbound or do anything
> outbound. There's no drop, no reject, the packets arrive on eth0
> (192.168.0.1) of shorewall and won't get forwarded to the gateway
>
Am 27.04.2014 15:01, schrieb Michael Kress:
>
> Once the connection is up, it's fine with the above effect (martian).
> After a while, the connection drops and cannot reconnect.
> From that moment, the two counters "TX dropped" and "Tx bytes" go up.
Am 27.04.2014 00:12, schrieb Michael Kress:
>
> After boot up (i.e. starting up S24openvpn and S28shorewall) it doesn't
> work right away.
> The first pings get dropped, but with no logging. (DROP counter on tun1
> goes up though).
>
> Then comes the fun part:
> I res
Am 26.04.2014 05:01, schrieb Tom Eastep:
> If you are going to do policy routing with Shorewall, then please do
> it the Shorewall way with /etc/shorewall/providers. Make tun1 an
> optional interface and make it a provider. And I recommend
> USE_DEFAULT_RT=Yes in shorewall.conf. -Tom
ok, I've f
Am 26.04.2014 04:09, schrieb Tom Eastep:
>> setup:
>> ==
>> test machine outside my LAN: x.x.x.18
>>
>> router in my LAN: 192.168.2.1
>>
>> Shorewall machine in my LAN:
>> tun1 x.x.x.245
>> eth0 192.168.0.1
>> eth1 192.168.2.151 with gw 192.168.2.1
>>
>> VM in my LAN:
>> eth0 192.168.0.11 with
, schrieb Michael Kress:
> Hi, I have an openvpn interface tun1 which provides me a fixed IP from
> the outside. I'm planning to forward certain ports and protocols to
> certain VMs in the local LAN.
>
> setup:
> ==
> test machine outside my LAN: x.x.x.18
>
&g
Hi, I have an openvpn interface tun1 which provides me a fixed IP from
the outside. I'm planning to forward certain ports and protocols to
certain VMs in the local LAN.
setup:
==
test machine outside my LAN: x.x.x.18
router in my LAN: 192.168.2.1
Shorewall machine in my LAN:
tun1 x.x.x.245
Hi, I have large static black lists (wizcraft and other country black
lists) and I get a segfault while loading the blacklist:
23:20:40 Applying Policies...
23:20:40 Activating Rules...
23:20:40 IP Forwarding Enabled
23:20:40 Loading Black List...
Segmentation fault
Is there any reason which I co
On 30.01.2012 22:29, Michael Kress wrote:
> I have for sure equipped all external interfaces with the blacklist option:
> net ppp0-blacklist
> net ppp1-blacklist
> net ippp1 -blacklist
> net ippp0 -black
On 31.01.2012 01:39, Michael Kress wrote:
> On 30.01.2012 22:29, Michael Kress wrote:
>> loc eth0detect
>> loc eth1detect
>> loc eth2detect
>>
>>
>
> ok, I think I've found the configuration fault ... the requests
> obviously
On 30.01.2012 22:55, Tom Eastep wrote:
> On Jan 30, 2012, at 1:29 PM, Michael Kress wrote:
>
>>
>> But I have one rule that doesn't block requests:
>> 58.208.0.0/12
>>
>> I have for sure restarted shorewall (using Shorewall-4.4.11.2), but I
>&
Hi,
I've recently blocked a bunch of IP addresses from a country with a red
flag, one big golden star in the top left corner and 4 smaller stars
next to it, building the shape of a semi circle.
Many rules in /etc/shorewall/blacklist are valid and effective, like e.g.
208.115.192.0/18
216.245.192
Tom Eastep wrote:
> Michael Kress wrote:
>
>> How can I establish accounting for my case in order to see traffic
>> separated by vnet0/vnet1/...?
>>
>
> You must qualify dmz0 with an IP address. Or simply use IP addresses
> without specifying dmz0. If
Hello,
so my setup with kvm is perfect, thank you very Tom for your help so far!
I've got another question about accouting.
I've got a bridge:
brctl show
bridge name bridge id STP enabled interfaces
dmz08000.00ff10c5b9a5 yes vnet0
Tom Eastep wrote:
> There actually *is* a way.
>
> Change your interfaces file to look like this:
>
> world br0 detect bridge,routeback
> - br0:eth0detect
> loc br0:vnet0 detect
>
> And add a hosts file as follows:
>
> net eth0:0.0.0.0/0 blacklist
y discard it if it
isn't being done automatically).
Tom Eastep wrote:
> > Michael Kress wrote:
> >
>
>> >> So how could I block individuals with my setup as posted before?
>> >>
>>
> >
> > In Shorewall 4.2.7, you wil
Tom Eastep wrote:
> Nothing -- There is no way currently to apply blacklisting to a bridge port.
>
So how could I block individuals with my setup as posted before?
Thx
Greetings
Michael
--
Open Source Business Confere
Hello list, Hello Tom, I'm trying to set up shorewall for the following
situation:
A server linked to the outside world via a static ip (currently
192.168.* but later it will have a "real" one, but fixed/static).
Some virtual machines, all done with kvm, they'll all have their
fixed/static ip adres
27 matches
Mail list logo
