Re: [Shorewall-users] IP address change not surviving reboot

[Philip Le Riche via Shorewall-users]

Not getting very far with this on the Linux Mint forums - it seems like 
an IP address change most certainly should survive a reboot, and it 
seems implausible that such a blatant bug would go unnoticed on a 
standard set-up.


But Shorewall isn't a standard set-up (quite). A germ of an idea is forming.

I'm using rules in /etc/shorewall/nat to do 2-way natting between 
Raspberry Pi local addresses and external addresses on the school 
network, and I setADD_IP_ALIASES=Yes in shorewall.conf.


I suspect what's happening is that I'm getting into a situation where 
enp2s0 has an IP address on one subnet and enps20:0-16 created by 
Shorewall are on a different subnet, and that the confusion is causing a 
new enp2s0 to be created on rebooting.


The solution would seem to be to turn off the start-on-boot option in 
shorewall.conf, reboot, do everything needful with the IP configuration, 
reboot to make sure it sticks, and only then allow Shorewall to start.


I won't be able to try it until Monday at the earliest, but it sounds 
like there's a subtle mantrap here that could perhaps be highlighted in 
the docs.


But why does it seem to take 25 seconds to create the NAT aliases? Is 
this to be expected?




On 15/08/2023 22:02, Philip Le Riche wrote:

Thaks Matt -

On 15/08/2023 15:56, Matt Darfeuille wrote:

On 8/15/23 15:44, Philip Le Riche via Shorewall-users wrote:
We have a Shorewall firewall at the school where I volunteer, 
protecting the school network from a Raspberry 

snip...
by Shorewall for NAT rules. Meanwhile, a new enp2s0 has appeared 
with an IP address I didn't recognise.


This is a wild guess, to me you have a static network at home and a 
DHCP set up at school. :)
But that wouldn't be representative of the school environment, and I'm 
not sure how the NAT addresses could be made dynamic. You only need to 
be clever enough to avoid the DHCP pool to allocate a static address. 
And I was fortunate that I could use the same 4th octet in both 
environments and hence capture the Shorewall dependencies in my params 
file.




ifconfig shows the base enp2s0 with no IP address, plus the 16 expected 


With a new set up, I would familierize myself with the iptools PKG! ;^)
ifconfig has served me well since SysV. Hey ho. Maybe I have to move 
with the times.


shorewall stop and shorewall clear before reapplying the config made 
no improvement.




Most likely because it has nothing to do with SW!

Most likely.


Maybe I should be using the CUI commands, but I'll need to read a 
man page or two first, and I'm not sure whether the GUI tool 
maintains any of its own data. Anyway, a bit of insight from round 
here would be appreciated.




To me , headless mode is the way to go (Webmin comes to mind).

For a server shut away in the basement that sounds like a good option. 
Must check it out. Except that I'd have had to successfully change the 
IP address before I could access Webmin (to change the IP address). 
And for a firewall, it'd add significantly to the attack surface. A 
quick search for "webmin cve" listed 81 vulnerabilities.
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] IP address change not surviving reboot

[Philip Le Riche via Shorewall-users]

This may be an underlying Linux problem but I first of all need to run 
it past you guys and gals here as few people on Linux forums will be 
familiar with Shorewall.


We have a Shorewall firewall at the school where I volunteer, protecting 
the school network from a Raspberry Pi farm on which students 
necessarily have root privileges. I rebuilt it at home on newer hardware 
with the outside interface IP address reflecting my home 192.168 network 
instead of the school 172. network. I took it in to school today and 
attempted to reconfigure the outside interface IP.


Using the GUI (Linux Mint XFCE), I changed the outside NIC IP address, 
netmask, def g/w and DNS server. In the GUI, the outside NIC (enp2s0) 
has the label SchlNet. Shorewall IP address dependencies are 
encapsulated in /etc/shorewall/params, and I changed those.


After a reboot, the GUI shows SchlNet has lost its configured IP address 
but gained 16 alias addresses added by Shorewall for NAT rules. 
Meanwhile, a new enp2s0 has appeared with an IP address I didn't recognise.


ifconfig shows the base enp2s0 with no IP address, plus the 16 expected 
NAT addresses on enp2s0:0:15 (or 1-16 - I forget).


I tried deleting the spurious enp2s0 and reapplying the IP config to 
SchlNet, but the same happed after a reboot.


I also tried deleting SchlNet, configuring the new enp2s0 and renaming 
it SchlNet, with exactly the same result after a reboot.


shorewall stop and shorewall clear before reapplying the config made no 
improvement.


Maybe I should be using the CUI commands, but I'll need to read a man 
page or two first, and I'm not sure whether the GUI tool maintains any 
of its own data. Anyway, a bit of insight from round here would be 
appreciated.


Regards - Philip


___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting

[Philip Le Riche via Shorewall-users]

Many thanks Justin - systemctl enable shorewall fixed it. Nice to have 
such a simple solution!


Thanks also Matt. At a glance I might be able to use [1] to get sshd and 
apache2 to start, but that's for tomorrow.
(Yes, should have been /var/log/shorewall-init.log. Nothing added on 
booting until shorewall started manually, until which shorewall status 
said stopped.)


On 29/07/2023 19:18, Justin Pryzby wrote:

On Sat, Jul 29, 2023 at 02:25:05PM +0100, Philip Le Riche via Shorewall-users 
wrote:

As before, this is running under Linux Mint (Ubuntu-based), and this time I
installed Shorewall from the standard repository for the distro (perhaps
that was my mistake?) It's failing to start on boot even though I have
STARTUP_ENABLED=Yes in my shorewall.conf.

You should determine if shorewall is *trying* to start and failing, or
if systemd is not configured to start it.

$ sudo systemctl status shorewall
Loaded: loaded (/lib/systemd/system/shorewall.service; enabled; vendor preset: 
enabled)


Also, I was surprised to find that /etc/systemd/system/shorewall.service
didn't exist.

Maybe you need to run:
systemctl enable shorewall

https://shorewall.org/FAQ.htm#idm1200





___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Shorewall not starting

[Philip Le Riche via Shorewall-users]

Prompted by ending of 32 bit Linux support, I'm reimplementing a 
firewall I set up in around 2014 to protect a school network from 
arbitrary root-privilege actions by students on a bunch of Raspberry Pis.


As before, this is running under Linux Mint (Ubuntu-based), and this 
time I installed Shorewall from the standard repository for the distro 
(perhaps that was my mistake?) It's failing to start on boot even though 
I have STARTUP_ENABLED=Yes in my shorewall.conf.


I thought it was related to the fact that sshd and apache2 are also 
failing to start. This is because not all interfaces aren't up by the 
time their startup scripts run. This, in turn, seems to be because the 
16 IP address aliases on the school net NIC (NATted to local IPs of the 
Raspberry Pis) are apparently taking around 25 seconds to initialise. 
(Originally, I set these up manually but I'm now letting Shorewall do it 
by setting ADD_IP_ALIASES=Yes, now Shorewall is taking 25 seconds to start.)


However, I now think that's a separate problem (perhaps I could add 
/usr/share/shorewall/wait4ifup to their startup scripts) since nothing 
appears in /var/log/shorewall.init until I manually start Shorewall.


Also, I was surprised to find that /etc/systemd/system/shorewall.service 
didn't exist.


Are there any more diagnostics or fixes I can try before I try 
uninstalling shorewall as installed from the repository and reinstalling 
it using the tarball from shorewall.net? And should I include 
shorewall-init? (The network switch to which the Pis re connected might 
be switched off at the time the firewall is booted.)


Many thanks - Philip



___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Does DNAT do ARP?

[Philip Le Riche]

Does the mere existence of a DNAT rule cause the system to respond to
ARP requests for the translated IP address?

When I originally set up the system I assumed I had to add additional IP
addresses to the external interface for each of my DNAT rules, but
reading random docs I suddenly thought maybe I needn't have - I can't
now see anything that tells me I had to. A quick experiment on my home
system was inconclusive - probably a bug in my rules.

(I've long suspected that the 16 extra IP addresses on my external NIC
is what is causing slow network initialisation and hence failure of sshd
and apache to bind to their ports on boot.)

Regards - Philip

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Documentation error?

[Philip Le Riche]

On 09/08/2017 23:41, Tom Eastep wrote:
...
The tcrules file DID have a MARK column. -Tom
...

As I thought - thanks Tom & Vieri. (Was deep in 5 docs at the time.)

Regards - Philip

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Documentation error?

[Philip Le Riche]

Trying to set up a transparent proxy I'm slightly confused by the
following towards the end of
http://shorewall.net/Shorewall_Squid_Usage.html :

|/etc/shorewall/mangle| (assume loc interface is eth1 and net interface
is eth0):

#ACTION SOURCE  DESTPROTO  DPORT   SPORT
DIVERT  eth00.0.0.0/0   tcp-   80
TPROXY(3129)eth10.0.0.0/0   tcp80

Corresponding |/etc/shorewall/mangle| are:

#MARK   SOURCE  DESTPROTO  DPORT   SPORT
DIVERT  eth00.0.0.0/0   tcp-   80
TPROXY(3129)eth10.0.0.0/0   tcp80

I presume "Corresponding..." down to the end of the quote is an unintentional
duplicate. If not, I'm even more confused as mangle doesn't have a MARK column.

Regards - Philip


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Shorewall not starting: Linux Mint 18.2 bug

[Philip Le Riche]

Sorted, after months of frustration.

Installing Shorewall from the repository on Mint 18.2 fails to enable
the systemd shorewall service. Fixed by typing:
systemctl enable shorewall.service

This may also apply to Ubuntu and Debian as Mint uses the Ubuntu
repositories.

Regards - Philip

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Firewall hangs

[Philip Le Riche]

Solved - or rather, workaround found.

For the record, the problem seems to be a regression in the e1000e
driver or firmware between Mint 17 and 18, or a difference between the
32 and 64 bit versions. I had the school network on the motherboard NIC
(this is the one that was causing the trouble) and the Pi network on a
PCI NIC. Having rebuilt the system yet again to no avail, I swapped over
the two interfaces, and lo and behold - problem vanished!

Actually, I've just checked that the driver is the same (v3.2.6-k) but
the firmware has gone from 0.13-4 (works) to 1.8-0 (troublesome), and
I've moved from a 32 bit system (works) to a 64 bit system
(troublesome). The motherboard NIC on the system I have at home, which I
believe is the same or similar, is Intel 82579LM.

Regards - Philip

On 26/07/2017 02:20, Tom Eastep wrote:
> On 07/25/2017 11:52 AM, Philip Le Riche wrote:
>> OK, so I'm still bashing my head against a brick wall with this, and so
>> far the brick wall is holding out better than my head. With school hols
>> started I now have much greater access to the system.
>>
>> The problem is severe in the following situation: running VNC client on
>> a school PC controlling a Pi on the other side of the firewall.  The Pi
>> runs a face follower program which continuously displays image captures
>> from the camera, causing continual screen refreshes to be sent to the
>> VNC client. The firewall NIC on the school network side repeatedly goes
>> DOWN for around 30 secs at a time. ip -s link ls shows it's getting
>> large numbers of dropped packets. In this situation, control of the
>> session from the VNC client is almost impossible.
>>
>> Yesterday I tried 2 things, with interesting results:
>> 1. I completely rebuilt the system from scratch, installing Shorewall 5
>> instead of Shorewall 4, and with kernel 4.8.0-53. The problem remains.
>> 2. I dug out an old hard disk with a version of the system I built last
>> Summer (if not before) and kernel 4.4.0-34. All other hardware was
>> unchanged. The problem disappeared!
>>
>> This seems to indicate software, not hardware. No clues that I can spot
>> in /var/log/messages.
>>
>> Comparing the outputs of sysctl -a on the 2 systems shows various
>> parameters changed, but nearly all increased. (My best guess had been
>> that a kernel buffer needed to be larger.) See
>> blueskylark.org/stuff/sysctl-diffs.txt for an sdiff - old system on the
>> left, new on the right.
>>
>> /etc/shorewall/interfaces is identical between systems (except for
>> commented lines) and the only differences in shorewall.conf are in
>> logging and verbosity.
>>
>> Any suggestions?
>>
> Not really. I know of nothing in a Shorewall configuration that could
> produce these symptoms. One thing I noticed in the diff you posted was
> that the 'new' output showed nothing from net.netfilter, but I don't
> know if that is significant.
>
> -Tom
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Firewall hangs

[Philip Le Riche]

OK, so I'm still bashing my head against a brick wall with this, and so
far the brick wall is holding out better than my head. With school hols
started I now have much greater access to the system.

The problem is severe in the following situation: running VNC client on
a school PC controlling a Pi on the other side of the firewall.  The Pi
runs a face follower program which continuously displays image captures
from the camera, causing continual screen refreshes to be sent to the
VNC client. The firewall NIC on the school network side repeatedly goes
DOWN for around 30 secs at a time. ip -s link ls shows it's getting
large numbers of dropped packets. In this situation, control of the
session from the VNC client is almost impossible.

Yesterday I tried 2 things, with interesting results:
1. I completely rebuilt the system from scratch, installing Shorewall 5
instead of Shorewall 4, and with kernel 4.8.0-53. The problem remains.
2. I dug out an old hard disk with a version of the system I built last
Summer (if not before) and kernel 4.4.0-34. All other hardware was
unchanged. The problem disappeared!

This seems to indicate software, not hardware. No clues that I can spot
in /var/log/messages.

Comparing the outputs of sysctl -a on the 2 systems shows various
parameters changed, but nearly all increased. (My best guess had been
that a kernel buffer needed to be larger.) See
blueskylark.org/stuff/sysctl-diffs.txt for an sdiff - old system on the
left, new on the right.

/etc/shorewall/interfaces is identical between systems (except for
commented lines) and the only differences in shorewall.conf are in
logging and verbosity.

Any suggestions?

Regards - Philip

On 15/06/2017 15:10, Philip Le Riche wrote:
> We have Shorewall 4 protecting the school network from a group of
> Raspberry Pis, which we operate from PCs on the school network using VNC
> running through Shorewall. For some weeks we've had frequent problems
> with VNC sessions hanging for around 30 seconds. I've been trying to
> track it down with increasingly focussed Wireshark captures, and this is
> what seems to be happening on one fairly typical hang:
>
> Two Pis are being controlled from separate PCs. I have ping running from
> the firewall to one of the Pis and also from the firewall to the default
> gateway on the school network.
>
> Hundreds of packets are passing through the firewall from one of the Pis
> to the PC controlling it, containing VNC screen update data. These are
> interspersed every second by a ping/reply to one of the Pis and a
> ping/reply to the default gateway.
>
> Suddenly TCP retransmissions of VNC traffic start appearing. Often at
> this point you see one or two other packets, such as an ntp or a VNC
> from the other Pi, but this may only be because they're no longer being
> hidden amongst a mass of VNC.
>
> More retransmissions from the Pi(s) but nothing on the school network
> NIC, and in particular, no pings to the default gateway.
>
> After around 10 seconds, the Pi network NIC sends ICMP network
> unreachable to both Pis.
>
> Sometimes I've seen ICMP host unreachable, I think from the school
> network NIC back to a Pi. Other times I've seen RST, ACK packets from
> one of the VNC client PCs - I don't see RST, ACK in the standard TCP
> state diagram.
>
> After a total of around 30 seconds, everything seems to recover, and
> pings reappear on the school network, though  VNC generally has to open
> a new TCP connection.
>
> Only fairly recently have we regularly run more than one Pi at the same
> time. Maybe we're just running out of kernel buffers? Or we need a more
> powerful machine to run Shorewall? (It's an unremarkable desktop machine
> maybe 5 years old.) Or maybe I've just got something misconfigured.
> Ideas please?
>
> Regards - Philip
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Firewall hangs

[Philip Le Riche]

On 15/06/2017 21:20, Tom Eastep wrote:
> On 06/15/2017 07:10 AM, Philip Le Riche wrote:
> > We have Shorewall 4 protecting the school network from a group of
> > Raspberry Pis, which we operate from PCs on the school network
> > using VNC running through Shorewall. For some weeks we've had
> > frequent problems with VNC sessions hanging for around 30 seconds.
> > I've been trying to track it down with increasingly focussed
> > Wireshark captures, and this is what seems to be happening on one
> > fairly typical hang:
>
... snip...
>
> Are you monitoring ARP traffic between the Shorewall box and the
> School network?
>
> -Tom
ARP was about the first thing that I filtered out in my capture filter
as there was so much of it on the school network. Is this significant?

Regards - Philip
> >
--
> Check out the vibrant tech community on one of the world's most >
engaging tech sites, Slashdot.org! http://sdm.link/slashdot >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Firewall hangs

[Philip Le Riche]

We have Shorewall 4 protecting the school network from a group of
Raspberry Pis, which we operate from PCs on the school network using VNC
running through Shorewall. For some weeks we've had frequent problems
with VNC sessions hanging for around 30 seconds. I've been trying to
track it down with increasingly focussed Wireshark captures, and this is
what seems to be happening on one fairly typical hang:

Two Pis are being controlled from separate PCs. I have ping running from
the firewall to one of the Pis and also from the firewall to the default
gateway on the school network.

Hundreds of packets are passing through the firewall from one of the Pis
to the PC controlling it, containing VNC screen update data. These are
interspersed every second by a ping/reply to one of the Pis and a
ping/reply to the default gateway.

Suddenly TCP retransmissions of VNC traffic start appearing. Often at
this point you see one or two other packets, such as an ntp or a VNC
from the other Pi, but this may only be because they're no longer being
hidden amongst a mass of VNC.

More retransmissions from the Pi(s) but nothing on the school network
NIC, and in particular, no pings to the default gateway.

After around 10 seconds, the Pi network NIC sends ICMP network
unreachable to both Pis.

Sometimes I've seen ICMP host unreachable, I think from the school
network NIC back to a Pi. Other times I've seen RST, ACK packets from
one of the VNC client PCs - I don't see RST, ACK in the standard TCP
state diagram.

After a total of around 30 seconds, everything seems to recover, and
pings reappear on the school network, though  VNC generally has to open
a new TCP connection.

Only fairly recently have we regularly run more than one Pi at the same
time. Maybe we're just running out of kernel buffers? Or we need a more
powerful machine to run Shorewall? (It's an unremarkable desktop machine
maybe 5 years old.) Or maybe I've just got something misconfigured.
Ideas please?

Regards - Philip

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall as a web proxy

[Philip Le Riche]

Thank you Tom. I'd seen that there were various guides around for using
Squid as an intercepting proxy, but I don't want to crack open the ssl,
and anyway, since I can't find how to make Alexa use a proxy, I'm not
sure it'd be any easier to find its certificate store in order to inject
a squid certificate.

All I want to do is get Shorewall (or something running on the Shorewall
server) to field 443 connections and insert an http CONNECT verb before
relaying all subsequent traffic to the school proxy. If Shorewall
doesn't itself offer such a function I presume I could use it to DNAT
https to localhost and set up a Perl script to listen on localhost:443
then open an onward connection to the school proxy, inserting the
CONNECT verb before the outgoing traffic. Unless I've totally
misunderstood how an https proxy works.

Simply injecting the CONNECT verb before starting the ssl negotiation
must be pretty much what a browser on the school network does since the
school proxy doesn't require the installation of a certificate and
doesn't intercept ssl traffic.

Regards - Philip

On 10/06/2017 17:14, Tom Eastep wrote:
> On 06/09/2017 02:43 PM, Philip Le Riche wrote:
> > A student at school is working on getting Alexa working on a
> > Raspberry Pi. I've done it on one of my Pis and it works at home,
> > but not at school, I think because of the school web proxy. There
> > seems to be a paucity of information about proxy settings for
> > Alexa, and it doesn't appear to respect the system proxy settings
> > in /etc/environment.
>
> > The Pi network is behind a Shorewall firewall to protect the
> > school network. So in a flash of inspiration, I thought I could
> > simply DNAT the http requests hitting Shorewall as default gateway,
> > so automatically redirecting them to the school proxy. That works
> > for http, but not for https.
>
> > After a little bit of digging to find out how a proxy functions
> > for https it became obvious that  a simplistic DNAT couldn't work.
> > It seems that a browser, knowing that it's going through a browser,
> > first sends an unencrypted http CONNECT command before negotiating
> > the ssl tunnel.
>
> > But would it be possible to somehow configure Shorewall, on receipt
> > of a tcp:443 connection request, to inject the CONNECT command into
> > the stream before starting to relay the ssl dialogue, quoting the
> > pre-DNAT destination ip address? How (in outline) could you achieve
> > that?
>
> See
> http://roberts.bplaced.net/index.php/linux-guides/centos-6-guides/proxy-server/squid-transparent-proxy-http-https
>
> -Tom
> >
--
> Check out the vibrant tech community on one of the world's most >
engaging tech sites, Slashdot.org! http://sdm.link/slashdot >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Shorewall as a web proxy

[Philip Le Riche]

A student at school is working on getting Alexa working on a Raspberry
Pi. I've done it on one of my Pis and it works at home, but not at
school, I think because of the school web proxy. There seems to be a
paucity of information about proxy settings for Alexa, and it doesn't
appear to respect the system proxy settings in /etc/environment.

The Pi network is behind a Shorewall firewall to protect the school
network. So in a flash of inspiration, I thought I could simply DNAT the
http requests hitting Shorewall as default gateway, so automatically
redirecting them to the school proxy. That works for http, but not for
https.

After a little bit of digging to find out how a proxy functions for
https it became obvious that  a simplistic DNAT couldn't work. It seems
that a browser, knowing that it's going through a browser, first sends
an unencrypted http CONNECT command before negotiating the ssl tunnel.

But would it be possible to somehow configure Shorewall, on receipt of a
tcp:443 connection request, to inject the CONNECT command into the
stream before starting to relay the ssl dialogue, quoting the pre-DNAT
destination ip address? How (in outline) could you achieve that?

Regards - Philip

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting

[Philip Le Riche]

37:139" 0
Rule "PARAM - - udp 1024: 137" 0
Rule "PARAM - - tcp 135,139,445" 0
..End Macro /usr/share/shorewall/macro.SMB
..Expanding Macro /usr/share/shorewall/macro.DropUPnP...
Rule "PARAM - - udp 1900" 0
..End Macro /usr/share/shorewall/macro.DropUPnP
..Expanding inline action /usr/share/shorewall/action.NotSyn...
..End inline action /usr/share/shorewall/action.NotSyn
..Expanding Macro /usr/share/shorewall/macro.DropDNSrep...
Rule "PARAM - - udp - 53" 0
..End Macro /usr/share/shorewall/macro.DropDNSrep
   Policy DROP from schl to fw using chain schl-fw
   Policy DROP from schl to pinet using chain schl-pinet
   Policy DROP from schl to inet using chain schl-inet
   Policy REJECT from pinet to fw using chain pinet-fw
   Policy DROP from pinet to schl using chain pinet-schl
   Policy DROP from pinet to inet using chain pinet-inet
   Policy DROP from inet to fw using chain inet-fw
   Policy DROP from inet to schl using chain inet-schl
   Policy DROP from inet to pinet using chain inet-pinet
Generating Rule Matrix...
   Handling complex zones...
   Entering main matrix-generation loop...
   Chain eno1_in deleted
   Chain eno1_fwd deleted
   Chain enp2s0_in deleted
   Chain enp2s0_fwd deleted
   Chain ppp0_in deleted
   Chain ppp0_fwd deleted
   Finishing matrix...
Optimizing Ruleset...

  Table raw pass 1, 2 referenced chains, level 4a...

  Table raw pass 2, 2 referenced chains, level 4b...

  Table raw pass 2, 0 referenced user chains, level 8...

  Table raw pass 3, 2 referenced user chains, level 16...
   Table raw Optimized -- Passes =


  Table nat pass 1, 7 referenced chains, level 4a...
   1 references to chain eno1_masq replaced
   Chain eno1_masq deleted

  Table nat pass 2, 6 referenced chains, level 4a...

  Table nat pass 3, 6 referenced chains, level 4a...

  Table nat pass 4, 6 referenced chains, level 4b...

  Table nat pass 5, 1 short chains, level 4b...

  Table nat pass 5, 3 referenced user chains, level 8...

  Table nat pass 6, 6 referenced user chains, level 16...
   Table nat Optimized -- Passes =


  Table mangle pass 1, 11 referenced chains, level 4a...
   Chain tcin deleted
   Chain tcpost deleted
   Empty chain tcfor deleted

  Table mangle pass 2, 8 referenced chains, level 4a...

  Table mangle pass 3, 8 referenced chains, level 4b...

  Table mangle pass 4, 3 short chains, level 4b...

  Table mangle pass 4, 3 referenced user chains, level 8...

  Table mangle pass 5, 8 referenced user chains, level 16...
   Table mangle Optimized -- Passes =


  Table filter pass 1, 30 referenced chains, level 4a...
5 ACCEPT rules deleted from chain fw-pinet

  Table filter pass 2, 30 referenced chains, level 4a...
   1 references to chain fw-pinet replaced
   Chain fw-pinet deleted

  Table filter pass 3, 29 referenced chains, level 4a...

  Table filter pass 4, 29 referenced chains, level 4b...

  Table filter pass 5, 4 short chains, level 4b...

  Table filter pass 5, 26 referenced user chains, level 8...
   Chain inet-schl combined with inet-pinet
   1 references to chain inet-schl replaced
   Chain inet-schl deleted
   Chain inet-pinet renamed to ~comb0

  Table filter pass 6, 25 referenced user chains, level 8...

  Table filter pass 7, 28 referenced user chains, level 16...
   Table filter Optimized -- Passes =

Creating iptables-restore input...
Shorewall configuration compiled to /var/lib/shorewall/.start
Configuration uses these capabilities ('*' denotes required):
   ADDRTYPE
   AMANDA_HELPER*
   COMMENTS
   CONNMARK*
   CONNMARK_MATCH*
   CONNTRACK_MATCH
   CT_TARGET
   ENHANCED_REJECT
   EXMARK
   FTP_HELPER*
   FWMARK_RT_MASK
   GOTO_TARGET
   H323_HELPER*
   IPTABLES_S
   IRC_HELPER*
   LOG_TARGET*
   MANGLE_ENABLED
   MANGLE_FORWARD
   MARK
   MULTIPORT*
   NAT_ENABLED
   NETBIOS_NS_HELPER
   NEW_CONNTRACK_MATCH
   PPTP_HELPER*
   RAW_TABLE
   RECENT_MATCH
   SANE_HELPER*
   SIP_HELPER*
   SNMP_HELPER*
   TCPMSS_TARGET*
   TFTP_HELPER*
   WAIT_OPTION
   XMULTIPORT*
Starting Shorewall
Device "ppp0" does not exist.
Initializing...
Setting up Route Filtering...
Setting up Martian Logging...
Setting up Accept Source Routing...
Setting up log backend
Log Backend set to nf_log_ipv4
Disabling Kernel Automatic Helper Association
Shorewall-generated routing tables and routing rules removed
Adding Providers...
   WARNING: Interface ppp0 is not usable -- Provider raw (1) not Started
Provider school (2) Started
Default route 'nexthop via 172.16.135.254 dev eno1 weight 1' Added
Preparing iptables-restore input...
Running /sbin/iptables-restore ...
IPv4 Forwarding Enabled
done.



On 25/01/2017 21:22, Philip Le Riche wrote:
> Thanks Matt and Roberto - I'll try the systemctl commands next time I go
> into school (not until next week now). And it looks like I somehow
> didn't install shorewall-init at home - not sure why.
>
> Regards - Philip
>
> On 25/01/2017 17:30, Matt Darfeuille wrote:
>> On 1/25/2017 6:06 PM, Philip Le Riche wrote:
>>> I've checked that STARTUP_ENABLED=Yes is still in my shorewall.conf, and
>>> though I'm not familiar with systemd, I've checked that
>>> shorewall.service in /lib/systemd/system is the same between home and
>>> school setups. However, at school I also seem to have a
>>> shorewall-init.service, not present at home (where Shorewall starts as
>>> it should).
>> See for shorewall-init.service:
>> http://shorewall.org/Shorewall-init.html
>> http://shorewall.org/manpages/shorewall-init.html
>>
>> -Matt
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting

[Philip Le Riche]

Thanks Matt and Roberto - I'll try the systemctl commands next time I go
into school (not until next week now). And it looks like I somehow
didn't install shorewall-init at home - not sure why.

Regards - Philip

On 25/01/2017 17:30, Matt Darfeuille wrote:
> On 1/25/2017 6:06 PM, Philip Le Riche wrote:
>> I've checked that STARTUP_ENABLED=Yes is still in my shorewall.conf, and
>> though I'm not familiar with systemd, I've checked that
>> shorewall.service in /lib/systemd/system is the same between home and
>> school setups. However, at school I also seem to have a
>> shorewall-init.service, not present at home (where Shorewall starts as
>> it should).
> See for shorewall-init.service:
> http://shorewall.org/Shorewall-init.html
> http://shorewall.org/manpages/shorewall-init.html
>
> -Matt


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Shorewall not starting

[Philip Le Riche]

I got my Shorewall installation (defending a school network from  a
Raspberry Pi farm, with 3rd unfiltered Internet connection) working  at
home on an equivalent network though with different network addresses,
and transferred the config files to school. After correcting a couple of
really stoopid misteaks in resetting network and host addresses to
school values it sort of works, but for some reason, Shorewall no longer
starts on boot.

After boot, shorewall status says it's stopped, and gives the time it
was last started, prior to the most recent reboot. No clues in
/var/log/messages.

I've checked that STARTUP_ENABLED=Yes is still in my shorewall.conf, and
though I'm not familiar with systemd, I've checked that
shorewall.service in /lib/systemd/system is the same between home and
school setups. However, at school I also seem to have a
shorewall-init.service, not present at home (where Shorewall starts as
it should).

I suppose I could just preserve the config files and then reinstall
Shorewall, but not knowing what's gone wrong and why, I wouldn't know
whether it might go wrong again at an inconvenient time. I'm not sure
where to go from here. For what it's worth, I'll append the output from
an apparently successful shorewall start - much more verbose than it
used to be - maybe I turned logging up a bit.

Regards - Philip

PiWall ~ # shorewall start
Compiling using Shorewall 5.0.4...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Compiling /etc/shorewall/zones...
Compiling /etc/shorewall/interfaces...
   Interface "schl eno1 tcpflags,nosmurfs,logmartians,sourceroute=0"
Validated
   Interface "pinet enp2s0 tcpflags,nosmurfs,routefilter,logmartians"
Validated
   Interface "inet ppp0
tcpflags,nosmurfs,logmartians,sourceroute=0,optional" Validated
Determining Hosts in Zones...
   fw (firewall)
   schl (ipv4)
  eno1:0.0.0.0/0
   pinet (ipv4)
  enp2s0:0.0.0.0/0
   inet (ipv4)
  ppp0:0.0.0.0/0
Locating Action Files...
Compiling /etc/shorewall/policy...
   Policy for pinet to schl is DROP using chain pinet-schl
   Policy for pinet to inet is DROP using chain pinet-inet
   Policy for schl to fw is DROP using chain schl-all
   Policy for schl to pinet is DROP using chain schl-all
   Policy for schl to inet is DROP using chain schl-all
   Policy for inet to fw is DROP using chain inet-all
   Policy for inet to schl is DROP using chain inet-all
   Policy for inet to pinet is DROP using chain inet-all
   Policy for fw to schl is REJECT using chain all-all
   Policy for fw to pinet is REJECT using chain all-all
   Policy for fw to inet is REJECT using chain all-all
   Policy for schl to fw is REJECT using chain all-all
   Policy for schl to pinet is REJECT using chain all-all
   Policy for schl to inet is REJECT using chain all-all
   Policy for pinet to fw is REJECT using chain all-all
   Policy for pinet to schl is REJECT using chain all-all
   Policy for pinet to inet is REJECT using chain all-all
   Policy for inet to fw is REJECT using chain all-all
   Policy for inet to schl is REJECT using chain all-all
   Policy for inet to pinet is REJECT using chain all-all
Adding Anti-smurf Rules
Compiling TCP Flags filtering...
Compiling Kernel Route Filtering...
Compiling Martian Logging...
Compiling Accept Source Routing...
Compiling /etc/shorewall/providers...
Provider "raw 1 1 - ppp0 - fallback" Compiled
Provider "school 2 - - eno1 172.16.135.254 primary" Compiled
Compiling /etc/shorewall/rtrules...
Routing rule "enp2s0 - raw 11000 1" Compiled
Routing rule "lo - raw 11000 1" Compiled
Compiling /etc/shorewall/mangle...
   Mangle Rule "MARK(1) enp2s0 - udp 33434:33523 - - -" 0
   Mangle Rule "MARK(1) enp2s0 - 253 - - - -" 0
   Mangle Rule "MARK(1) fw - udp 33434:33523 - - -" 0
   Mangle Rule "MARK(1) fw - 253 - - - -" 0
Compiling /etc/shorewall/masq...
Masq record "eno1 192.168.1.0/24 172.16.135.160" 0
Masq record "ppp0 192.168.1.0/24 detect" 0
Compiling MAC Filtration -- Phase 1...
   Chain eno1_iop deleted
   Chain eno1_fop deleted
   Chain enp2s0_iop deleted
   Chain enp2s0_fop deleted
   Chain ppp0_iop deleted
   Chain ppp0_fop deleted
Compiling /etc/shorewall/rules...
..Expanding Macro /usr/share/shorewall/macro.Web...
Rule "PARAM - - tcp 80" 0
Rule "PARAM - - tcp 443" 0
..End Macro /usr/share/shorewall/macro.Web
Rule "Web(ACCEPT) pinet schl" 0
Rule "ACCEPT pinet schl udp ntp" 0
Rule "DNAT pinet schl:172.16.133.248 udp 53 - 192.168.1.254" 0
Rule "DNAT pinet schl:172.16.133.248 tcp 53 - 192.168.1.254" 0
..Expanding Macro /usr/share/shorewall/macro.SMBBI...
Rule "PARAM - - udp 135,445" 0
Rule " PARAM - - udp 137:139" 0
Rule "PARAM - - udp 1024: 137" 0
Rule "PARAM - - tcp 135,139,445" 0
Rule "PARAM DEST SOURCE udp 135,445" 0
Rule " PARAM DEST SOURCE udp 137:139" 0
Rule "PARAM DEST SOURCE udp 1024: 137" 0
Rule "PARAM DEST SOURCE tcp 135,139,445" 0
..End Macro 

Re: [Shorewall-users] Routing traceroute through an unfiltered Internet connection

[Philip Le Riche]

Slightly off-topic, but in case anyone picked up on my problem with the
mobile data dongle, if it doesn't connect by itself the trick seems to
be to eject the CDROM that it throws at you. It then presents the GSM
modem and connects. Whether or not shorewall is started, stopped or
clear is irrelevant but it needs to be restarted after ppp0 has come up.

Regards - Philip

On 11/01/2017 22:53, Tom Eastep wrote:
> On 01/11/2017 01:31 PM, Philip Le Riche wrote:
> > Great - thanks Tom! Removing routefilter from the 2 outbound
> > interfaces did the trick. I can now do both traceroute and http
> > from the Pi, and the -i option fixed traceroute on the firewall
> > itself. I would have given up long before stumbling across
> > routefilter.
>
> > I haven't seen the dhcpd startup problem again so I assume that's
> > gone away. However the mobile dongle startup seems to be getting
> > more unreliable but that seems to be USB problem not a shorewall
> > one assuming the kernel USB and networking stacks are completely
> > disjoint. (/var/log/messages shows it sometimes recognising the
> > mass storeage device and/or the CDROM on the dongle but not the GSM
> > modem, or detecting it as a serial device but not doing anything
> > with it).
>
> > Thanks again for excellent support.
>
> Glad to hear that it is working.
>
> -Tom
> >
--
> Developer Access Program for Intel Xeon Phi Processors > Access to
Intel Xeon Phi processor-based developer platforms. > With one year of
Intel Parallel Studio XE. > Training and support from Colfax. > Order
your platform today. http://sdm.link/xeonphi >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Routing traceroute through an unfiltered Internet connection

[Philip Le Riche]

Great - thanks Tom! Removing routefilter from the 2 outbound interfaces
did the trick. I can now do both traceroute and http from the Pi, and
the -i option fixed traceroute on the firewall itself. I would have
given up long before stumbling across routefilter.

I haven't seen the dhcpd startup problem again so I assume that's gone
away. However the mobile dongle startup seems to be getting more
unreliable but that seems to be USB problem not a shorewall one assuming
the kernel USB and networking stacks are completely disjoint.
(/var/log/messages shows it sometimes recognising the mass storeage
device and/or the CDROM on the dongle but not the GSM modem, or
detecting it as a serial device but not doing anything with it).

Thanks again for excellent support.

Best regards - Philip

On 11/01/2017 19:46, Tom Eastep wrote:
> On 01/11/2017 03:21 AM, Philip Le Riche wrote:
> > Hi Tom -
>
> > Several other problems which may or may not be related: 1.
> > traceroute getting send: operation not permitted when run from the
> > firewall itself.
>
> As pointed out in http://www.shorewall.org/MultiISP.html, packet
> marking is unreliable when applied to connections originating from the
> firewall. Try using the '-i' option of traceroute from the firewall.
>
> > 2. Mobile data dongle not starting with shorewall running -
> > possibly the same problem as 1.
>
> No clue -- are there any 'Shorewall' messages logged when this occurs?
>
> > 3. dhcpd not starting reliably - possibly a startup sequence
> > problem - it's worked the last twice and I didn't record the
> > message but was something about no available NICs to serve on.
>
> Sounds like a startup sequencing issue. Can't tell without seeing the
> messages.
>
> -Tom
> >
--
> Developer Access Program for Intel Xeon Phi Processors > Access to
Intel Xeon Phi processor-based developer platforms. > With one year of
Intel Parallel Studio XE. > Training and support from Colfax. > Order
your platform today. http://sdm.link/xeonphi >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Routing traceroute through an unfiltered Internet connection

[Philip Le Riche]

Hi Tom -

Here are a couple of pcaps on ppp0 from wireshark, one with ppp0 as
fallback (traceroute from the Pi doesn't work but web does) and with
ppp0 with no options (traceroute works but web doesn't).

In both cases you can see the udp packets going out and icmp timeouts
coming back but with fallback they don't seem to make it back to the Pi.
It looks like shorewall isn't opening the reverse path. Hopefully the
inconsistent web behaviour is another consequence of the same problem.

Several other problems which may or may not be related:
1. traceroute getting send: operation not permitted when run from the
firewall itself.
2. Mobile data dongle not starting with shorewall running - possibly the
same problem as 1.
3. dhcpd not starting reliably - possibly a startup sequence problem -
it's worked the last twice and I didn't record the message but was
something about no available NICs to serve on.

Thanks again - Philip


On 11/01/2017 00:38, Tom Eastep wrote:
> On 01/10/2017 01:55 PM, Philip Le Riche wrote:
> > Hi Tom -
>
> > Thanks for the greased-lightning response again, and here's the
> > dump.
>
>
> It looks to me like the traceroute packets are going out of ppp0 but
> that there are no responses. Can you confirm that using tcpdump?
>
> Thanks,
> -Tom
> >
--
> Developer Access Program for Intel Xeon Phi Processors > Access to
Intel Xeon Phi processor-based developer platforms. > With one year of
Intel Parallel Studio XE. > Training and support from Colfax. > Order
your platform today. http://sdm.link/xeonphi >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >




ppp0-fallback.pcapng
Description: Binary data


ppp0-nofallback.pcapng
Description: Binary data
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Routing traceroute through an unfiltered Internet connection

[Philip Le Riche]

Hi Tom -

Thanks for the greased-lightning response again, and here's the dump.

Many thanks - Philip

On 10/01/2017 21:05, Tom Eastep wrote:
> On 01/10/2017 12:50 PM, Philip Le Riche wrote:
> > I'm afraid I'm still struggling with this, though I made a minor
> > breakthrough when I realised I hadn't added a masq rule for the
> > raw interface, and the ppp0 not useable problem has gone away. (It
> > seems I have to connect it with shorewall clear then start
> > shorewall.) Anyway, my home test setup now seems to be working like
> > the school firewall.
>
> > (To recap, Raspberry Pis on zone pinet are accessed by PCs in zone
> > schl using ssh and vnc, and access the Internet via schl and the
> > school gateway. Traceroute traffic (only) from Pis and the firewall
> > is to be routed to a 3rd zone containing a mobile data dongle to
> > give unfiltered Internet access.)
>
> > Traceroute is now routed correctly from the Pis, but on the
> > firewall traceroute reports Send: Operation not permitted. (I have
> > the same rules with pinet and $FW as source to allow traceroute.)
> > Also, web access from both the Pis and the firewall is now broken.
> > However a PC on schl can still access a Pi.
>
> > My providers file is now: #NAMENUMBERMARKDUPLICATE
> > INTERFACEGATEWAYOPTIONS raw11-ppp0
> > - school2--eno1192.168.1.1 primary
>
> > If I add option fallback to provider raw, that fixes web from both
> > the Pis and the firewall but breaks traceroute. (I didn't think it
> > was a good idea but tried it anyway.)
>
> > I've read providers(5) and Multiple Internet Connections several
> > times and spent a good few hours trying to get it to work but there
> > seems to be something that I still haven't correctly understood.
> > Any help would be greatly appreciated.
>
> > For reference, my other relevant shorewall files are: mangle:
> > #ACTIONSOURCEDESTPROTOPORT(S)SOURCEUSER
> > TEST #PORT(S) MARK(1)enx00e04c534458-
> > udp33434:33523--- MARK(1) enx00e04c534458-
> > 253---- MARK(1)$FW-udp33434:33523
> > --- MARK(1) $FW-253----
>
> > rtrules: #SOURCEDESTPROVIDERPRIORITYMARK
> > enx00e04c534458-raw110001 lo-raw
> > 110001
>
> > zones: fwfirewall schlipv4 pinetipv4 inetipv4
>
> > interfaces: schleno1
> > tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0 pinet
> > enx00e04c534458 tcpflags,nosmurfs,routefilter,logmartians inet
> > ppp0
> > tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0,optional
>
> Philip,
>
> Please:
>
> a) Set fallback on the raw provider.
> b) Shorewall reload
> c) Try a traceroute from a Pi
> d) 'shorewall dump > dump'
> e) Send me the 'dump' file.
>
> Thanks,
> -Tom
>
> >
--
> Developer Access Program for Intel Xeon Phi Processors > Access to
Intel Xeon Phi processor-based developer platforms. > With one year of
Intel Parallel Studio XE. > Training and support from Colfax. > Order
your platform today. http://sdm.link/xeonphi >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >


Shorewall 5.0.4 Dump at Philip-Desktop - Tue 10 Jan 21:48:24 GMT 2017

Shorewall is running
State:Started (Tue 10 Jan 21:47:05 GMT 2017) from /etc/shorewall/ 
(/var/lib/shorewall/firewall compiled by Shorewall version 5.0.4)

Counters reset Tue 10 Jan 21:47:05 GMT 2017

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt in out source   destination 

   65  4500 schl-fwall  --  eno1   *   0.0.0.0/00.0.0.0/0   

   36  3680 pinet-fw   all  --  enx00e04c534458 *   0.0.0.0/0
0.0.0.0/0   
0 0 inet-fwall  --  ppp0   *   0.0.0.0/00.0.0.0/0   

5   404 ACCEPT all  --  lo *   0.0.0.0/00.0.0.0/0   

0 0 Reject all  --  *  *   0.0.0.0/00.0.0.0/0   

0 0 LOGall  --  *  *   0.0.0.0/00.0.0.0/0   
 LOG flags 0 level 6 prefix "Shorewall:INPUT:REJECT:"
0 0 reject all  --  *  *   0.0.0.0/00.0.0.0/0   
[goto] 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target prot opt 

Re: [Shorewall-users] Routing traceroute through an unfiltered Internet connection

[Philip Le Riche]

I'm afraid I'm still struggling with this, though I made a minor
breakthrough when I realised I hadn't added a masq rule for the raw
interface, and the ppp0 not useable problem has gone away. (It seems I
have to connect it with shorewall clear then start shorewall.) Anyway,
my home test setup now seems to be working like the school firewall.

(To recap, Raspberry Pis on zone pinet are accessed by PCs in zone schl
using ssh and vnc, and access the Internet via schl and the school
gateway. Traceroute traffic (only) from Pis and the firewall is to be
routed to a 3rd zone containing a mobile data dongle to give unfiltered
Internet access.)

Traceroute is now routed correctly from the Pis, but on the firewall
traceroute reports Send: Operation not permitted. (I have the same rules
with pinet and $FW as source to allow traceroute.) Also, web access from
both the Pis and the firewall is now broken. However a PC on schl can
still access a Pi.

My providers file is now:
#NAMENUMBERMARKDUPLICATEINTERFACEGATEWAYOPTIONS
raw11-ppp0-
school2--eno1192.168.1.1 primary

If I add option fallback to provider raw, that fixes web from both the
Pis and the firewall but breaks traceroute. (I didn't think it was a
good idea but tried it anyway.)

I've read providers(5) and Multiple Internet Connections several times
and spent a good few hours trying to get it to work but there seems to
be something that I still haven't correctly understood. Any help would
be greatly appreciated.

For reference, my other relevant shorewall files are:
mangle:
#ACTIONSOURCEDESTPROTOPORT(S)SOURCEUSERTEST
#PORT(S)
MARK(1)enx00e04c534458-udp33434:33523---
MARK(1) enx00e04c534458-253----
MARK(1)$FW-udp33434:33523---
MARK(1) $FW-253----

rtrules:
#SOURCEDESTPROVIDERPRIORITYMARK
enx00e04c534458-raw110001
lo-raw110001

zones:
fwfirewall
schlipv4
pinetipv4
inetipv4

interfaces:
schleno1   
tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0
pinet   enx00e04c534458 tcpflags,nosmurfs,routefilter,logmartians
inetppp0   
tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0,optional

Regards - Philip

On 06/01/2017 11:52, Philip Le Riche wrote:
> Thanks, Tom, for the rapid response.
>
> I don't have easy access to the firewall in question so I've set up an
> equivalent network at home. In the providers file I've added the
> primary option to the school network and fallback to the mobile data,
> though I don't actually want it to fall back.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Routing through a firewall/router

[Philip Le Riche]

Try the command shorewall clear at a root shell to set the firewall temporarily 
open, and see if you can then route as you expect. If you still can't it would 
seem to be a routing problem rather than a shorewall problem.

Regards - Philip

Sent from my iPhone

> On 6 Jan 2017, at 21:37, Johannes Graumann  
> wrote:
> 
> Hello,
> 
> I'm running a 4 NIC firewall to route/organize my home network using 
> shorewall/
> dnsmasq and am at a loss why I can't connect (or ping) between subnets that 
> hang on different nets. Access to the net (eth0) is working beautifully) and 
> the subnets are able to ping the IP associated with the NICs on the FW, but 
> not into the subnets beyond. I'm running in circles and are unclear where the 
> problem is. Any advise is highly appreciated.
> 
> /sbin/shorewall version
> 4.6.4.3
> 
> ip addr show
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
> default
>   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>   inet 127.0.0.1/8 scope host lo
>  valid_lft forever preferred_lft forever
>   inet6 ::1/128 scope host
>  valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> group default qlen 1000
>   link/ether 00:00:24:d0:62:dc brd ff:ff:ff:ff:ff:ff
>   inet 192.168.2.100/24 brd 192.168.2.255 scope global eth0
>  valid_lft forever preferred_lft forever
>   inet6 fe80::200:24ff:fed0:62dc/64 scope link
>  valid_lft forever preferred_lft forever
> 3: can0:  mtu 16 qdisc noop state DOWN group default qlen 10
>   link/can
> 4: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> group default qlen 1000
>   link/ether 00:00:24:d0:62:dd brd ff:ff:ff:ff:ff:ff
>   inet 10.10.1.1/24 brd 10.10.1.255 scope global eth1
>  valid_lft forever preferred_lft forever
>   inet6 fe80::200:24ff:fed0:62dd/64 scope link
>  valid_lft forever preferred_lft forever
> 5: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> group default qlen 1000
>   link/ether 00:00:24:d0:62:de brd ff:ff:ff:ff:ff:ff
>   inet 10.10.4.1/24 brd 10.10.4.255 scope global eth2
>  valid_lft forever preferred_lft forever
>   inet6 fe80::200:24ff:fed0:62de/64 scope link
>  valid_lft forever preferred_lft forever
> 6: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> group default qlen 1000
>   link/ether 00:00:24:d0:62:df brd ff:ff:ff:ff:ff:ff
>   inet 10.10.5.1/24 brd 10.10.5.255 scope global eth3
>  valid_lft forever preferred_lft forever
>   inet6 fe80::200:24ff:fed0:62df/64 scope link
>  valid_lft forever preferred_lft forever
> 
> ip route show
> default via 192.168.2.1 dev eth0
> 10.10.1.0/24 dev eth1  proto kernel  scope link  src 10.10.1.1
> 10.10.4.0/24 dev eth2  proto kernel  scope link  src 10.10.4.1
> 10.10.5.0/24 dev eth3  proto kernel  scope link  src 10.10.5.1
> 192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.100
> 
> Reuslt of shorewall dump is attached.
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Routing traceroute through an unfiltered Internet connection

[Philip Le Riche]

Thanks, Tom, for the rapid response.

I don't have easy access to the firewall in question so I've set up an
equivalent network at home. In the providers file I've added the primary
option to the school network and fallback to the mobile data, though I
don't actually want it to fall back.

Now, on starting Shorewall, I get WARNING: interface ppp0 is not useable.

Is ther a log file which will shed a little more light on that?

In fact Linux won't start the ppp0 session unless I do shorewall clear
before plugging the dongle in - I'm not sure I got that at school, but
with shorewall clear and if I set eno1 down (the "school" network) I can
browse the net through the dongle.

I now have interfaces:
schleno1   
tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0
pinet   enx00e04c534458 tcpflags,nosmurfs,routefilter,logmartians
inetppp0   
tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0,optional

providers:
#NAMENUMBERMARKDUPLICATEINTERFACEGATEWAYOPTIONS
raw11-ppp0detectfallback
school2--eno1192.168.1.1 primary

mangle:
#ACTIONSOURCEDESTPROTOPORT(S)SOURCEUSERTEST
#PORT(S)
MARK(1)enx00e04c534458-udp33434:33523---
MARK(1) enx00e04c534458-253----
MARK(1)lo-udp33434:33523---
MARK(1) lo-253----

rtrules:
#SOURCEDESTPROVIDERPRIORITYMARK
enx00e04c534458-raw110001
lo-raw110001

masq:
#INTERFACE:DESTSOURCEADDRESSPROTOPORT(S)   
IPSECMARKUSER/SWITCHORIGINAL
#GROUPDEST
eno1192.168.2.0/24192.168.1.2

and in rules I simply modified the DNAT rules for the Pis to reflect the
different IP addressing scheme (I didn't mention that before).

Best regards - Philip


On 03/01/2017 17:22, Tom Eastep wrote:
> On 01/03/2017 06:51 AM, Philip Le Riche wrote:
> > I've been trying without success on and off for some while to
> > modify an existing Shorewall configuration for the purposes of a
> > school lesson on Internet routing, using traceroute.
>
> > I originally set up the firewall to protect the school network from
> > a bunch of Raspberry Pis, operated "headless" from school PCs using
> > VNC or ssh, thus we had 3 zones:
>
> > #ZONETYPEOPTIONSINOUT fw
> > firewall schlipv4 pinetipv4
>
> > The idea is to run traceroute from the Pis, but since since
> > traceroute is blocked by the school firewall/proxy I've added a
> > mobile data dongle and a new zone giving me unfiltered Internet
> > access: inetipv4
>
> > My interfaces file now looks like this: schleno1
> > tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0 pinet
> > enp2s0  tcpflags,nosmurfs,routefilter,logmartians inet
> > ppp0
> > tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0,optional
>
> > In my providers file I've defined a provider "raw" for the
> > unfiltered mobile data interface: #NAMENUMBERMARK
> > DUPLICATEINTERFACEGATEWAYOPTIONS raw  1 1
> > -ppp0
>
> > I've been trying both regular traceroute (udp/33434-33523) and
> > traceroute -P 253 (protocol 253), and so I'm using mangle to mark
> > all such packets coming from the Pi network (and from the firewall
> > while I'm at it, for testing purposes): #ACTIONSOURCEDEST
> > PROTOPORT(S)SOURCEUSERTEST #
> > PORT(S) MARK(1)enp2s0-   udp33434:33523--
> > - MARK(1)enp2s0-   253---- MARK(1)
> > $FW   -   udp33434:33523--- MARK(1)$FW
> > -   253----
>
> > And in rtrules I'm directing marked packets at provider raw: SOURCE
> > DESTPROVIDERPRIORITYMARK enp2s0-   raw
> > 11000   1 lo-   raw 11000   1
>
> > In my rules file I've allowed traceroute from pinet and $FW to
> > inet: # # pinet -> inet # Allow traceroute only # ACCEPT
> > pinetinetudp33434:33523 ACCEPTpinet
> > inet253
>
> > # # $FW -> inet # #ACTION SOURCE  DESTPROTO   DEST
> > SOURCE  RATEUSER/ #
> > PORT(S) PORT(S) LIMIT   GROUP ACCEPT$FWinetudp
> > 33434:33523 ACCEPT$FWinet253
>
> > Since the mobile data dongle hasn't connected by the time
> > Shorewall starts on a reboot, I have to do a shorewall restart, and
> > also if I plug in th

[Shorewall-users] Routing traceroute through an unfiltered Internet connection

[Philip Le Riche]

I've been trying without success on and off for some while to modify an
existing Shorewall configuration for the purposes of a school lesson on
Internet routing, using traceroute.

I originally set up the firewall to protect the school network from a
bunch of Raspberry Pis, operated "headless" from school PCs using VNC or
ssh, thus we had 3 zones:

#ZONETYPEOPTIONSINOUT
fwfirewall
schlipv4
pinetipv4

The idea is to run traceroute from the Pis, but since since traceroute
is blocked by the school firewall/proxy I've added a mobile data dongle
and a new zone giving me unfiltered Internet access:
inetipv4

My interfaces file now looks like this:
schleno1   
tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0
pinet   enp2s0  tcpflags,nosmurfs,routefilter,logmartians
inetppp0   
tcpflags,nosmurfs,routefilter,logmartians,sourceroute=0,optional

In my providers file I've defined a provider "raw" for the unfiltered
mobile data interface:
#NAMENUMBERMARKDUPLICATEINTERFACEGATEWAYOPTIONS
raw  1 1   -ppp0

I've been trying both regular traceroute (udp/33434-33523) and
traceroute -P 253 (protocol 253), and so I'm using mangle to mark all
such packets coming from the Pi network (and from the firewall while I'm
at it, for testing purposes):
#ACTIONSOURCEDESTPROTOPORT(S)SOURCEUSERTEST
#PORT(S)
MARK(1)enp2s0-   udp33434:33523---
MARK(1)enp2s0-   253----
MARK(1)$FW   -   udp33434:33523---
MARK(1)$FW   -   253----

And in rtrules I'm directing marked packets at provider raw:
SOURCEDESTPROVIDERPRIORITYMARK
enp2s0-   raw 11000   1
lo-   raw 11000   1

In my rules file I've allowed traceroute from pinet and $FW to inet:
#
# pinet -> inet
# Allow traceroute only
#
ACCEPTpinetinetudp33434:33523
ACCEPTpinetinet253

#
# $FW -> inet
#
#ACTION SOURCE  DESTPROTO   DESTSOURCE  RATEUSER/
#   PORT(S) PORT(S) LIMIT   GROUP
ACCEPT$FWinetudp33434:33523
ACCEPT$FWinet253

Since the mobile data dongle hasn't connected by the time Shorewall
starts on a reboot, I have to do a shorewall restart, and also if I plug
in the dongle at any time after booting.

However, there still seems to be an error or omission in my logic as
traceroute on the firewall Pi still shows it routing through the school
network, as evidenced by the ip addresses reported (as far as they go),
and traceroute on a Pi shows nothing beyond the pinet firewall interface.
Perhaps you can provide me with that lightbulb moment which seems to be
evading me.

Regards - Philip

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] icmp timeout packets

[Philip Le Riche]

I'm trying to run traceroute from a Raspberry Pi on one side of
shorewall through to the Internet on the other, for the purposes of an
Internet routing lesson.

I can detect some hosts on the far side of shorewall but not as many as
I was hoping (possibly due to ISP filtering), even though I didn't think
to add a rule for returning icmp timeout packets. On reflection, perhaps
I ought to have since a rule is needed for ping. Does this indicate that
shorewall passes some icmp packets by default, and if so, which? I don't
immediately see anything on this in the documentation.

Regards - Philip

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle/rtrules problem

[Philip Le Riche]

Thank you - so I take it there's nothing conceptually wrong with my
approach. It'll be next Wednesday before I can get to the machine again
to take a dump though. In fact for other reasons it looks like we'll
have to do this Internet routing lessons another way, but even so I'd
like to understand this for my own satisfaction.  - Philip

On 27/10/2016 22:57, Tom Eastep wrote:
> On 10/27/2016 2:34 PM, Philip Le Riche wrote:
> > Everything in shorewall.conf I didn't seem to need or fully understand I
> > left as out-of-the-box. MARK_IN_FORWARD_CHAIN is set to no so the
> > default prerouting chain would appear to be correct.
>
> Okay
>
>
> > Does Wireshark cohabit comfortably with Shorewall if I wanted to
> > actually see the packets coming in or going out? I presume it monitors
> > the raw socket rather than going anywhere near the IP stack.
>
> Yes
>
>  Or can I
> > use a LOG action  to show routing decisions, including those in rtrules?
> > (I have limited access to the machine so I'm afraid I can't just go and
> > try it.)
>
> No.
>
>
> If you will send me the output of 'shorewall dump' collected as
> described at http://www.shorewall.org/support.htm#Guidelines, I'll be
> happy to take a look.
>
> -Tom
> >
--
> The Command Line: Reinvented for Modern Developers > Did the
resurgence of CLI tooling catch you by surprise? > Reconnect with the
command line and become more productive. > Learn the new .NET and
ASP.NET CLI. Get your free copy! > http://sdm.link/telerik >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle/rtrules problem

[Philip Le Riche]

Everything in shorewall.conf I didn't seem to need or fully understand I
left as out-of-the-box. MARK_IN_FORWARD_CHAIN is set to no so the
default prerouting chain would appear to be correct.

Does Wireshark cohabit comfortably with Shorewall if I wanted to
actually see the packets coming in or going out? I presume it monitors
the raw socket rather than going anywhere near the IP stack. Or can I
use a LOG action  to show routing decisions, including those in rtrules?
(I have limited access to the machine so I'm afraid I can't just go and
try it.)

Regards - Philip

On 27/10/2016 21:26, Tom Eastep wrote:
> On 10/27/2016 12:29 PM, Philip Le Riche wrote:
> > As I said, traceroute is being used on the Pis, not the firewall,
> > so after leaving a raw socket on a Pi they should still hit the IP
> > stack on the firewall and get filtered and routed by Shorewall like
> > anything else. My question remains.
>
> > Useful to know about traceroute and raw sockets though - like many
> > things, obvious when you think about it. I was going to set up
> > similar rules with $FW as source  purely for testing and
> > diagnostics.
>
> Okay -- what are the setting of MARK_IN_FORWARD_CHAIN? If it is Yes,
> then you need to alter your mark rules to include the :P chain designator.
>
> -Tom
>
> >
--
> The Command Line: Reinvented for Modern Developers > Did the
resurgence of CLI tooling catch you by surprise? > Reconnect with the
command line and become more productive. > Learn the new .NET and
ASP.NET CLI. Get your free copy! > http://sdm.link/telerik >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] mangle/rtrules problem

[Philip Le Riche]

As I said, traceroute is being used on the Pis, not the firewall, so
after leaving a raw socket on a Pi they should still hit the IP stack on
the firewall and get filtered and routed by Shorewall like anything
else. My question remains.

Useful to know about traceroute and raw sockets though - like many
things, obvious when you think about it. I was going to set up similar
rules with $FW as source  purely for testing and diagnostics.

Regards - Philip

On 27/10/2016 19:04, Tom Eastep wrote:
> On 10/27/2016 08:10 AM, Philip Le Riche wrote:
> > I'm using Shorewall to separate a bunch of Raspberry Pis on a
> > local network (enp2s0 - pinet) from the school network (eno1 -
> > schl). The ruleset allows the Pis to be controlled from school PCs
> > using PuTTy or VNC and to access the web through the school
> > network. I added a 3rd NIC (enp3s0 - inet) to the firewall
> > connected to an unfiltered Internet connection to allow students to
> > use traceroute on the Pis for the purposes of a lesson on Internet
> > routing. The idea is to use the fact that traceroute uses udp
> > 33434-33523 to route traceroute traffic only to inet.
>
> > In providers I have: #NAMENUMBERMARKDUPLICATE
> > INTERFACEGATEWAYOPTIONS raw11-enp3s0
> > 172.18.57.254
>
> > I mark traceroute traffic in mangle with: #ACTIONSOURCEDEST
> > PROTOPORT(S)SOURCEUSERTEST #
> > PORT(S) MARK(1)enp2s0-udp33434:33523--
> > -
>
> > and I route them in rtrules with: #SOURCEDESTPROVIDER
> > PRIORITYMARK enp2s0-raw110001
>
> > Relevent rules are: #ACTION SOURCE  DESTPROTO   DEST
> > SOURCE  RATEUSER/ #
> > PORT(S) PORT(S) LIMIT   GROUP ACCEPTpinetinet
> > udp33434:33523
>
> > yet traceroute shows the next hop as 172.16 (schl) not 172.18
> > (inet).
>
> > I also tried traceroute -P 253, replacing udp 33434:33523 with 253
> > in mangle and rules, with no greater success.
>
> > Is there something obvious I'm doing wrong?
>
>
> Traceroute uses raw sockets which don't go through the IP stack.
>
> -Tom
> >
--
> The Command Line: Reinvented for Modern Developers > Did the
resurgence of CLI tooling catch you by surprise? > Reconnect with the
command line and become more productive. > Learn the new .NET and
ASP.NET CLI. Get your free copy! > http://sdm.link/telerik >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] mangle/rtrules problem

[Philip Le Riche]

I'm using Shorewall to separate a bunch of Raspberry Pis on a local
network (enp2s0 - pinet) from the school network (eno1 - schl). The
ruleset allows the Pis to be controlled from school PCs using PuTTy or
VNC and to access the web through the school network. I added a 3rd NIC
(enp3s0 - inet) to the firewall connected to an unfiltered Internet
connection to allow students to use traceroute on the Pis for the
purposes of a lesson on Internet routing. The idea is to use the fact
that traceroute uses udp 33434-33523 to route traceroute traffic only to
inet.

In providers I have:
#NAMENUMBERMARKDUPLICATEINTERFACEGATEWAYOPTIONS
raw11-enp3s0172.18.57.254

I mark traceroute traffic in mangle with:
#ACTIONSOURCEDESTPROTOPORT(S)SOURCEUSERTEST
#PORT(S)
MARK(1)enp2s0-udp33434:33523---

and I route them in rtrules with:
#SOURCEDESTPROVIDERPRIORITYMARK
enp2s0-raw110001

Relevent rules are:
#ACTION SOURCE  DESTPROTO   DESTSOURCE  RATEUSER/
#   PORT(S) PORT(S) LIMIT   GROUP
ACCEPTpinetinetudp33434:33523

yet traceroute shows the next hop as 172.16 (schl) not 172.18 (inet).

I also tried traceroute -P 253, replacing udp 33434:33523 with 253 in
mangle and rules, with no greater success.

Is there something obvious I'm doing wrong?

Regards - Philip

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Cinnamon desktop someties failing to start

[Philip Le Riche]

Well that's odd. I already have LOGFILE=/var/log/messages. I tried
LOG_BACKEND=LOG (it was empty - ULOG gave an error) and I tried upping
VERBOSITY from 1 to 2, but still no logging. Other log parameters are
unchanged.

Regards - Philip

On 26/10/2016 16:36, Tom Eastep wrote:
> On 10/26/2016 07:13 AM, Philip Le Riche wrote:
> > I'm running Shorewall (latest version downloaded a couple of months
> > ago) on Linux Mint Cinnamon. The GUI login screen always comes up
> > on boot, but after logging in, maybe once in half a dozen goes, I
> > get a message that Cinnamon has crashed and it enters a Fallback
> > Mode. I mentioned it a while back and was recommended to do
> > shorewall dump and to grab Xorg.0.log, which was tricky at the time
> > since Fallback Mode, incredibly, doesn't seem to offer a shell!
>
> > I managed to get a shell this morning and did just that. Shorewall
> > dump said /var/log/messages didn't exist (which I confirmed) and
> > Xorg.0.log is appended, though it shows nothing untoward that I can
> > see.
>
> So set LOGFILE in shorewall.conf to point to the log where Shorewall
> messages are being sent.
>
>
> > My hunch is that the Cinnamon desktop is trying to use something
> > that Shorewall hasn't quite finished twiddling with. The
> > variability would certainly suggest a timing problem. However, it
> > may be nothing to do with Shorewall, but if smeone could cast an
> > eye over the log I'd be grateful.
>
>
> Unfortunately, the X log didn't show anything out of the ordinary that
> I could see.
>
> -Tom
> >
--
> The Command Line: Reinvented for Modern Developers > Did the
resurgence of CLI tooling catch you by surprise? > Reconnect with the
command line and become more productive. > Learn the new .NET and
ASP.NET CLI. Get your free copy! > http://sdm.link/telerik >
___ > Shorewall-users
mailing list > Shorewall-users@lists.sourceforge.net >
https://lists.sourceforge.net/lists/listinfo/shorewall-users >


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Cinnamon desktop someties failing to start

[Philip Le Riche]

I'm running Shorewall (latest version downloaded a couple of months ago)
on Linux Mint Cinnamon. The GUI login screen always comes up on boot,
but after logging in, maybe once in half a dozen goes, I get a message
that Cinnamon has crashed and it enters a Fallback Mode. I mentioned it
a while back and was recommended to do shorewall dump and to grab
Xorg.0.log, which was tricky at the time since Fallback Mode,
incredibly, doesn't seem to offer a shell!

I managed to get a shell this morning and did just that. Shorewall dump
said /var/log/messages didn't exist (which I confirmed) and Xorg.0.log
is appended, though it shows nothing untoward that I can see.

My hunch is that the Cinnamon desktop is trying to use something that
Shorewall hasn't quite finished twiddling with. The variability would
certainly suggest a timing problem. However, it may be nothing to do
with Shorewall, but if smeone could cast an eye over the log I'd be
grateful.

Regards - Philip

[20.577]
X.Org X Server 1.18.3
Release Date: 2016-04-04
[20.577] X Protocol Version 11, Revision 0
[20.577] Build Operating System: Linux 3.13.0-85-generic i686 Ubuntu
[20.577] Current Operating System: Linux PiWall 4.4.0-34-generic
#53-Ubuntu SMP Wed Jul 27 16:06:28 UTC 2016 i686
[20.577] Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-4.4.0-34-generic
root=UUID=0954e7e3-891b-4f41-bc4c-4f9603f27c11 ro quiet splash vt.handoff=7
[20.577] Build Date: 07 April 2016  09:18:48AM
[20.577] xorg-server 2:1.18.3-1ubuntu2 (For technical support please
see http://www.ubuntu.com/support)
[20.577] Current version of pixman: 0.33.6
[20.577] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[20.577] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[20.577] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Oct 26
11:42:32 2016
[20.578] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[20.578] (==) No Layout section.  Using the first Screen section.
[20.578] (==) No screen section available. Using defaults.
[20.578] (**) |-->Screen "Default Screen Section" (0)
[20.578] (**) |   |-->Monitor ""
[20.588] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[20.588] (==) Automatically adding devices
[20.588] (==) Automatically enabling devices
[20.588] (==) Automatically adding GPU devices
[20.588] (==) Max clients allowed: 256, resource mask: 0x1f
[20.588] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
exist.
[20.588] Entry deleted from font path.
[20.588] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not
exist.
[20.588] Entry deleted from font path.
[20.588] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not
exist.
[20.588] Entry deleted from font path.
[20.588] (WW) The directory "/usr/share/fonts/X11/100dpi" does not
exist.
[20.588] Entry deleted from font path.
[20.588] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[20.588] Entry deleted from font path.
[20.588] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/Type1,
built-ins
[20.588] (==) ModulePath set to
"/usr/lib/i386-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[20.588] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable
AutoAddDevices.
[20.588] (II) Loader magic: 0x802d8700
[20.588] (II) Module ABI versions:
[20.588] X.Org ANSI C Emulation: 0.4
[20.588] X.Org Video Driver: 20.0
[20.588] X.Org XInput driver : 22.1
[20.588] X.Org Server Extension : 9.0
[20.590] (++) using VT number 8

[20.590] (II) systemd-logind: logind integration requires -keeptty
and -keeptty was not provided, disabling logind integration
[20.590] (II) xfree86: Adding drm device (/dev/dri/card0)
[20.593] (--) PCI:*(0:0:2:0) 8086:0102:8086:200a rev 9, Mem @
0xfe00/4194304, 0xd000/268435456, I/O @ 0xf000/64
[20.594] (II) LoadModule: "glx"
[20.594] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[20.611] (II) Module glx: vendor="X.Org Foundation"
[20.611] compiled for 1.18.3, module version = 1.0.0
[20.611] ABI class: X.Org Server Extension, version 9.0
[20.611] (==) AIGLX enabled
[20.611] (==) Matched intel as autoconfigured driver 0
[20.611] (==) Matched intel as autoconfigured driver 1
[20.611] (==) Matched modesetting as autoconfigured driver 2
[20.611] (==) Matched fbdev as autoconfigured driver 3
[20.611] (==) Matched vesa as autoconfigured driver 4
[20.611] (==) Assigned the driver to the 

[Shorewall-users] Cinnamon desktop someties failing to start

[Philip Le Riche]

I'm running Shorewall (latest version downloaded a couple of months ago)
on Linux Mint Cinnamon. The GUI login screen always comes up on boot,
but after logging in, maybe once in half a dozen goes, I get a message
that Cinnamon has crashed and it enters a Fallback Mode. I mentioned it
a while back and was recommended to do shorewall dump and to grab
Xorg.0.log, which was tricky at the time since Fallback Mode,
incredibly, doesn't seem to offer a shell!

I managed to get a shell this morning and did just that. Shorewall dump
said /var/log/messages didn't exist (which I confirmed) and Xorg.0.log
is appended, though it shows nothing untoward that I can see.

My hunch is that the Cinnamon desktop is trying to use something that
Shorewall hasn't quite finished twiddling with. The variability would
certainly suggest a timing problem. However, it may be nothing to do
with Shorewall, but if smeone could cast an eye over the log I'd be
grateful.

Regards - Philip

[20.577]
X.Org X Server 1.18.3
Release Date: 2016-04-04
[20.577] X Protocol Version 11, Revision 0
[20.577] Build Operating System: Linux 3.13.0-85-generic i686 Ubuntu
[20.577] Current Operating System: Linux PiWall 4.4.0-34-generic
#53-Ubuntu SMP Wed Jul 27 16:06:28 UTC 2016 i686
[20.577] Kernel command line:
BOOT_IMAGE=/boot/vmlinuz-4.4.0-34-generic
root=UUID=0954e7e3-891b-4f41-bc4c-4f9603f27c11 ro quiet splash vt.handoff=7
[20.577] Build Date: 07 April 2016  09:18:48AM
[20.577] xorg-server 2:1.18.3-1ubuntu2 (For technical support please
see http://www.ubuntu.com/support)
[20.577] Current version of pixman: 0.33.6
[20.577] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[20.577] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[20.577] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Oct 26
11:42:32 2016
[20.578] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[20.578] (==) No Layout section.  Using the first Screen section.
[20.578] (==) No screen section available. Using defaults.
[20.578] (**) |-->Screen "Default Screen Section" (0)
[20.578] (**) |   |-->Monitor ""
[20.588] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[20.588] (==) Automatically adding devices
[20.588] (==) Automatically enabling devices
[20.588] (==) Automatically adding GPU devices
[20.588] (==) Max clients allowed: 256, resource mask: 0x1f
[20.588] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
exist.
[20.588] Entry deleted from font path.
[20.588] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not
exist.
[20.588] Entry deleted from font path.
[20.588] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not
exist.
[20.588] Entry deleted from font path.
[20.588] (WW) The directory "/usr/share/fonts/X11/100dpi" does not
exist.
[20.588] Entry deleted from font path.
[20.588] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[20.588] Entry deleted from font path.
[20.588] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/Type1,
built-ins
[20.588] (==) ModulePath set to
"/usr/lib/i386-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[20.588] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable
AutoAddDevices.
[20.588] (II) Loader magic: 0x802d8700
[20.588] (II) Module ABI versions:
[20.588] X.Org ANSI C Emulation: 0.4
[20.588] X.Org Video Driver: 20.0
[20.588] X.Org XInput driver : 22.1
[20.588] X.Org Server Extension : 9.0
[20.590] (++) using VT number 8

[20.590] (II) systemd-logind: logind integration requires -keeptty
and -keeptty was not provided, disabling logind integration
[20.590] (II) xfree86: Adding drm device (/dev/dri/card0)
[20.593] (--) PCI:*(0:0:2:0) 8086:0102:8086:200a rev 9, Mem @
0xfe00/4194304, 0xd000/268435456, I/O @ 0xf000/64
[20.594] (II) LoadModule: "glx"
[20.594] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[20.611] (II) Module glx: vendor="X.Org Foundation"
[20.611] compiled for 1.18.3, module version = 1.0.0
[20.611] ABI class: X.Org Server Extension, version 9.0
[20.611] (==) AIGLX enabled
[20.611] (==) Matched intel as autoconfigured driver 0
[20.611] (==) Matched intel as autoconfigured driver 1
[20.611] (==) Matched modesetting as autoconfigured driver 2
[20.611] (==) Matched fbdev as autoconfigured driver 3
[20.611] (==) Matched vesa as autoconfigured driver 4
[20.611] (==) Assigned the driver to the 

[Shorewall-users] Apache failing to start

[Philip Le Riche]

OK, this is getting too deep for me. On Linux Mint Cinnamon 18, I'm
running Shorewall and apache2 (and isc-dhcp-server, openssh-server and
samba). One of the interfaces apache is listening on has a number of
additional ip addresses matching DNAT rules. Apache fails to start on
boot because the attempt to listen on this interface (on the base IP
address) fails. It's not clear whether this is because shorewall is
still starting or because the basic networking is still messing about
adding IP addresses to the interface. Starting apache later by handworks
fine.

The whole init system on Mint 18 seems a mess. Shorewall is started by
systemd from /lib/systemd/shorewall.service, apache is started by SysV
init from /etc/init.d/apache2, whereas sshd and samba are started by
upstart from /etc/init/ssh.conf and /etc/init/samba.conf. I think in
fact systemd is masquerading as init - there's no inittab, but how
systemd and upstart dependencies are supposed to resolve is as yet a
mystery to me.

A long time ago (on Mint 17) I had a problem with sshd not starting
which was fixed by putting a sleep 5 in /etc/init/ssh.conf and this fix
also works on Mint18.

I could presumably put a sleep 5 in /etc/init.d/apache2 but the real
solution would be to sort out the dependencies. Any idea how to do that?

Regards - Philip

--
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting

[Philip Le Riche]

I've just popped in to the school and the systemctl enable shorewall did
the trick.

Three or four reboots later I thought I'd seen the last of the desktop
crash, but then I was sorting out another problem - I have 16 DNAT rules
but had only added 8 extra IP addresses to the source NIC. After adding
the remaining 8 I rebooted and the desktop crashed. I was going to do a
shorewall dump as suggested but this crazy fallback desktop, would you
believe, doesn't provide a terminal! The usual ctl-alt-t didn't produce
one either. After rebooting it was fine and I'll probably never see it
again so it's not an issue for me. Probably I should have done a
shorewall reload before rebooting. If you can see theoretically why what
I did caused it to get into a strange state and can make it more robust,
then well and good.

I now just have one other unrelated problem and I'll start another
threadif I can't see how to fix it.

Thanks for your help and patience - regards - Philip

On 15/09/2016 13:33, Roberto C. Sánchez wrote:
> On Thu, Sep 15, 2016 at 09:18:26AM +0100, Philip Le Riche wrote:
>>OK, thanks, so on this near-clone system, systemd is installed and
>>systemctl shows  shorewall as disabled. When next I can get to the live
>>system (probably next week) I'll repeat it there, and it sounds like it
>>should then start on boot.
>>
> I hope that fixes the start-on-boot problem for you.
>
>>But does that explain why the desktop crashed when I enabled start-on-boot
>>through shorewall.conf and /etc/defaults/shorewall? Does the desktop need
>>an ACCEPT $fw $fw rule to talk to its (local) display server, or is the
>>route from a zone to itself always implicitly allowed?
>>
> I think that might be a different issue.  Unless you have done something
> peculiar with your configuration, $FW<->$FW connections should be
> allowed by default.
>
> To properly diagnose this, we will need the output of 'shorewall dump'
> just after a boot/crash.  It would be helpful if you could also include
> other relevant logs (e.g., the Xorg.log).
>
> Regards,
>
> -Roberto
>
>
>
> --
>
>
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users

--
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting

[Philip Le Riche]

OK, thanks, so on this near-clone system, systemd is installed and
systemctl shows  shorewall as disabled. When next I can get to the live
system (probably next week) I'll repeat it there, and it sounds like it
should then start on boot.

But does that explain why the desktop crashed when I enabled
start-on-boot through shorewall.conf and /etc/defaults/shorewall? Does
the desktop need an ACCEPT $fw $fw rule to talk to its (local) display
server, or is the route from a zone to itself always implicitly allowed?

Regards - Philip

On 14/09/2016 22:53, Roberto C. Sánchez wrote:
> On Wed, Sep 14, 2016 at 10:40:37PM +0100, Philip Le Riche wrote:
>>It reports:
>>Philip-Desktop ~ # apt-cache policy shorewall
>>shorewall:
>>  Installed: 5.0.4-1
>>
> That version of Shorewall had a packaging bug such that it wouldn't
> start on boot on systems running systemd.
>
>>I'm having difficulty working out what init system it uses and the release
>>notes don't seem to say. (I was brought up on SystemV inittab - I've got
>>the white hair - I just need the walking frame.) Running ps reports
>>process 1 as /sbin/init splash. There's no /etc/inittab but /etc/init is a
>>directory containing loads of .conf files including several
>>upstart-*.conf, smbd.conf and ssh.conf but no shorewall.conf, possibly
>>because I haven't started it.
>>
> What is the output of `apt-cache policy systemd`?  If it reports
> something in the version field for "Installed", then look at the output
> of `systemctl is-enabled shorewall`.  If that spits out "disabled" then
> you can turn it on with `systemctl enable shorewall` and it will start
> on boot as you would expect.
>
> Regards,
>
> -Roberto
>
>
>
> --
>
>
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users

--
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting

[Philip Le Riche]

Ah, come to think of it I've got another Linux Mint system down here in
a corner which I set up as far as I can tell identically but it doesn't
have Shorewall configured or started as I don't have the requisite NICs
and only have one network.

It reports:
Philip-Desktop ~ # apt-cache policy shorewall
shorewall:
  Installed: 5.0.4-1
  Candidate: 5.0.4-1
  Version table:
 *** 5.0.4-1 500
500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
500 http://archive.ubuntu.com/ubuntu xenial/universe i386 Packages
100 /var/lib/dpkg/status

I'm having difficulty working out what init system it uses and the
release notes don't seem to say. (I was brought up on SystemV inittab -
I've got the white hair - I just need the walking frame.) Running ps
reports process 1 as /sbin/init splash. There's no /etc/inittab but
/etc/init is a directory containing loads of .conf files including
several upstart-*.conf, smbd.conf and ssh.conf but no shorewall.conf,
possibly because I haven't started it.

Regards - Philip

On 14/09/2016 21:51, Roberto C. Sánchez wrote:
> On Wed, Sep 14, 2016 at 09:31:12PM +0100, Philip Le Riche wrote:
>>I don't have immediate access to the system and can't easily get precise
>>subversion numbers  but it's running a freshly installed Linux Mint 18 and
>>Shorewall 5 as offered by the standard repository just a few weeks ago.
>>I'm also running Apache2, Samba, isc-dhcp-server and openssh-server. I
>>could be wrong, but to me this has the feel of something to do with the
>>way shorewall and Mint 18 interact rather than something specific to a
>>subversion.
>>
> I am not a Linux Mint user, so I looked on the Mint package listing page
> for the current release and Shorewall is not listed as a package in the
> distribution.  Just tell us the Shorewall package version (output of
> `apt-cache policy shorewall`) so that we can help diagnose the problem.
>
> Also, since you indicated originally that your problem has to do with
> Shorewall not starting at boot, what init system are you using?
>
> Regards,
>
> -Roberto
>
>
>
> --
>
>
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users

--
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting

[Philip Le Riche]

I don't have immediate access to the system and can't easily get precise
subversion numbers  but it's running a freshly installed Linux Mint 18
and Shorewall 5 as offered by the standard repository just a few weeks
ago. I'm also running Apache2, Samba, isc-dhcp-server and
openssh-server. I could be wrong, but to me this has the feel of
something to do with the way shorewall and Mint 18 interact rather than
something specific to a subversion.

Regards - Philip

On 14/09/2016 16:33, Roberto C. Sánchez wrote:
> On Wed, Sep 14, 2016 at 04:27:15PM +0100, Philip Le Riche wrote:
>> After a bit of googling I set startup=1 in /etc/default/shorewall and on
>> the next reboot following logon the desktop crashed before displaying
>> anything, dropping me into fallback mode. Now shorewall again doesn't
>> start on boot.
>>
> What version of Shorewall and what installation source (upstream
> installer or distro packages)?
>
> Regards,
>
> -Roberto
>
>
>
> --
>
>
> ___
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users

--
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Shorewall not starting

[Philip Le Riche]

We'd been running Shorewall successfully since a couple of years ago on
the then current version of Linux Mint. I recently rebuilt the firewall
on slightly less ancient hardware and with the latest Linux Mint and
Shorewall, and now it doesn't start automatically.

After a bit of googling I set startup=1 in /etc/default/shorewall and on
the next reboot following logon the desktop crashed before displaying
anything, dropping me into fallback mode. Now shorewall again doesn't
start on boot.

I think I got the same desktop crash when I first set
STARTUP_ENABLED=Yes in shorewall.conf. The ruleset is unchanged from the
previous build. Do you now need an ACCEPT $FW $FW rule to allow the
desktop to talk to its graphics server? And how do I now get shorewall
to start on boot?

Regards - Philip

--
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Documemtation metadata error

[Philip Le Riche]

Err, the file http://shorewall.net/manpages/shorewall-tcrules.html
contains the html page title tag

shorewall-mangle

This confused me for a little while as I wasn't sure whether I was
writing a mangle rule
or a tcrules rule, as the wrong page title was appearing in my browser tab.


Regards - Philip

--
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Documemtation metadata error

[Philip Le Riche]

In fact, I'm not sure I'm totally deconfused. Example 2 in
http://shorewall.net/manpages/shorewall-mangle.html seems to be
suggesting putting a mangle rule in /etc/shorewall tcrules.

Regards - Phiip

On 04/09/2016 19:43, Philip Le Riche wrote:
> Err, the file http://shorewall.net/manpages/shorewall-tcrules.html
> contains the html page title tag
>
> shorewall-mangle
>
> This confused me for a little while as I wasn't sure whether I was
> writing a mangle rule
> or a tcrules rule, as the wrong page title was appearing in my browser tab.
>
>
> Regards - Philip


--
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Macrofied DNAT not working

[Philip Le Riche]

Thanks Tom -

It must've been something silly as it seems to be working ok now.
(Unfortunately I only get access to the firewall briefly once a week.)

Regards - Philip

On 13/12/2014 17:01, Tom Eastep wrote:
 On 12/3/2014 10:05 AM, Philip Le Riche wrote:
 Probably something silly I'm doing but I don't see it for the moment.

 I had rules:
 DNATschlpinet:${Pinet}.1tcpssh-   
 ${Schlnet}.129
 DNATschlpinet:${Pinet}.1tcp5900-   
 ${Schlnet}.129
 plus another 7 pairs with consecutive destination and original
 destination addresses.

 I needed to add an http rule and expand it to 16 IP addresses, so I
 wrote a macro.Pi:
 PARAM   -   -   tcp 5900:5909   -   -
 PARAM   -   -   tcp ssh -   -
 PARAM   -   -   tcp http-   -

 and replaced all the former rules by 16 after the fashion:
 Pi(DNAT)schlpinet:${Pinet}.1-   -   -  
 ${Schlnet}.129
 (I generalised the VNC port while I was at it.)

 Connections utilising those rules were then refused. I don't see why.

 I don't either, but if you will send me the original rules file, the
 modified rules file and your macro file then I will take a look.

 -Tom

 PS - My apologies for the slow response; I've been traveling abroad and
 only had mobile phone internet access.


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk


 ___
 Shorewall-users mailing list
 Shorewall-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/shorewall-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Macrofied DNAT not working

[Philip Le Riche]

Probably something silly I'm doing but I don't see it for the moment.

I had rules:
DNATschlpinet:${Pinet}.1tcpssh-   
${Schlnet}.129
DNATschlpinet:${Pinet}.1tcp5900-   
${Schlnet}.129
plus another 7 pairs with consecutive destination and original
destination addresses.

I needed to add an http rule and expand it to 16 IP addresses, so I
wrote a macro.Pi:
PARAM   -   -   tcp 5900:5909   -   -
PARAM   -   -   tcp ssh -   -
PARAM   -   -   tcp http-   -

and replaced all the former rules by 16 after the fashion:
Pi(DNAT)schlpinet:${Pinet}.1-   -   -  
${Schlnet}.129
(I generalised the VNC port while I was at it.)

Connections utilising those rules were then refused. I don't see why.

Perhaps this would be a classic use case for IPsets.

Regards - Philip

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting on boot - eth0 not up yet

[Philip Le Riche]

On 11/20/2014 00:42 AM, Tom Eastep wrote:

No -- but they are pretty obvious. Given the error message you are
seeing, something you are doing requires the IP address of eth0. Some
possibilities are:

- You are calling find_first_interface_address() in your params file
- You have used eth0 or %eth0 in one of your files
- You have used detect: in a rule.
- You have entered detect in the ADDRESS column in the masq file

Thanks Tom, and yes, that seems to be it. I have the Address column in
masq as detect, probably for historical reasons from when I was setting
it up in a test environment. That interface now has 17 IP addresses
(recently increased from 9), 16 associated with DNAT rules. So masq
would have been using them all as masqueraded adresses, which is not
what I intended.

Regards - Philip

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting on boot - eth0 not up yet

[Philip Le Riche]

Thanks Tom - it sounds like adding something like required,wait=5
would at least be a viable work-around.

But reading between the lines, it seems you're saying that I could in
all likelihood sidestep the problem completely, just by specifying
optional instead (I presume required is the default - the man page
is silent on that.) Is there a discussion somewhere of what
configurations require required?

Regards - Philip

On 18/11/2014 16:47, Tom Eastep wrote:
 On 11/18/2014 1:12 AM, Philip Le Riche wrote:
 I'm using Shorewall to protect a school network from a classroom network
 of Raspberry Pis, which are operated headless from school network PCs using 
 VNC or PuTTy.

 All was working fine, starting up successfully on boot until I did the
 following:
 Installed isc-dhcp-server to serve dhcp to guest Pis
 Installed Apache2 and a cgi script to report DHCP leases
 Added 8 more fixed IP addresses to the school NIC and 8 more DNAT rules
 (bringing it to 16) mapping them to classroom IP addresses
 Installed OpenSSH for firewall maintenance
 Added Shorewall ACCEPT rules with destination $FW for the above.

 Now Shorewall doesn't start on boot, and neither does sshd, but both
 start successfully if you log in and type shorewall start and service
 sshd start. (Apache and dhcp-server start up ok.)

 The problem seems to be that eth0 is still not up by the time the
 Shorewall and sshd init scripts get run. In shorewall-init.log there are
 messages Can't determine the IP address of eth0
 You have configured Shorewall so that eth0 *must* be up before Shorewall
 can start. If that is really necessary (which I rather doubt), then:

 a) Specify 'required' on the eth0 entry in /etc/shorewall/interfaces
 b) Additionally, specify 'wait=N' where N is the number of seconds that
 you are willing to wait for eth0 to come up.

 -Tom


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk


 ___
 Shorewall-users mailing list
 Shorewall-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/shorewall-users

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Shorewall-users] Shorewall not starting n boot - eth0 not up yet

[Philip Le Riche]

I'm using Shorewall to protect a school network from a classroom network
of Raspberry Pis, which are operated headless from school network PCs using VNC 
or PuTTy.

All was working fine, starting up successfully on boot until I did the
following:
Installed isc-dhcp-server to serve dhcp to guest Pis
Installed Apache2 and a cgi script to report DHCP leases
Added 8 more fixed IP addresses to the school NIC and 8 more DNAT rules
(bringing it to 16) mapping them to classroom IP addresses
Installed OpenSSH for firewall maintenance
Added Shorewall ACCEPT rules with destination $FW for the above.

Now Shorewall doesn't start on boot, and neither does sshd, but both
start successfully if you log in and type shorewall start and service
sshd start. (Apache and dhcp-server start up ok.)

The problem seems to be that eth0 is still not up by the time the
Shorewall and sshd init scripts get run. In shorewall-init.log there are
messages Can't determine the IP address of eth0 and in
/var/log/auth.log there are sshd messages Cannot bind any address.

Shorewall is running under Linux Mint 16.

It may be arguable whether the Shorewall (and sshd) init scripts are at
fault or whether the fault lies with networking startup, but it must be
an issue other people round here have hit. Is there a recognised fix,
either to delay startup of Shorewall (and sshd), or to ensure networking
runs to completion before dependant init scripts are run? Googling for
the sshd half of the problem only seems to come up with sticking plaster
solutions.

Regards - Philip


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Shorewall not starting n boot - eth0 not up yet

[Philip Le Riche]

No, I believe it uses Upstart.

- Philip

On 18/11/2014 09:44, Artur Uszyński wrote:
 Is Mint 16 using systemd ?

 --
 Artur

 W dniu 18.11.2014 o 10:12, Philip Le Riche pisze:
 I'm using Shorewall to protect a school network from a classroom network
 of Raspberry Pis, which are operated headless from school network PCs using 
 VNC or PuTTy.

 All was working fine, starting up successfully on boot until I did the
 following:
 Installed isc-dhcp-server to serve dhcp to guest Pis
 Installed Apache2 and a cgi script to report DHCP leases
 Added 8 more fixed IP addresses to the school NIC and 8 more DNAT rules
 (bringing it to 16) mapping them to classroom IP addresses
 Installed OpenSSH for firewall maintenance
 Added Shorewall ACCEPT rules with destination $FW for the above.

 Now Shorewall doesn't start on boot, and neither does sshd, but both
 start successfully if you log in and type shorewall start and service
 sshd start. (Apache and dhcp-server start up ok.)

 The problem seems to be that eth0 is still not up by the time the
 Shorewall and sshd init scripts get run. In shorewall-init.log there are
 messages Can't determine the IP address of eth0 and in
 /var/log/auth.log there are sshd messages Cannot bind any address.

 Shorewall is running under Linux Mint 16.

 It may be arguable whether the Shorewall (and sshd) init scripts are at
 fault or whether the fault lies with networking startup, but it must be
 an issue other people round here have hit. Is there a recognised fix,
 either to delay startup of Shorewall (and sshd), or to ensure networking
 runs to completion before dependant init scripts are run? Googling for
 the sshd half of the problem only seems to come up with sticking plaster
 solutions.

 Regards - Philip


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Shorewall-users mailing list
 Shorewall-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/shorewall-users


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Shorewall-users mailing list
 Shorewall-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/shorewall-users



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Re: [Shorewall-users] Checking out my success

[Philip Le Riche]

Great, very useful. Thanks Tom!

A couple of points though as I don't quite seem to be there yet with
netmap or ADD_DNAT_ADDRS.

There's no ADD_DNAT_ADDRS in shorewall.conf. Adding it caused shorewall
start to spit it out. Perhaps you meant ADD_IP_ALIASES, or even
ADD_SNAT_ALIASES, but neither seemed to result in additional ip
addresses on the interface as shown by the GUI. So as a stopgap, I
recreated them manually.

There's no annotated (or plain) netmap file that I can see, so I created
one containing:

DNAT  ${Schlnet}.128/27 eth0 ${Pinet}.0/27  -  tcp  ssh
DNAT  ${Schlnet}.128/27 eth0 ${Pinet}.0/27  -  tcp  5900

(in order to map a 32-address block at eth0 to a corresponding block at
eth1).

I was gratified that shorewall start showed it as compiled without
complaint, but I couldn't ping or ssh the Pinet host through the Schlnet
ip address.

The docs say I need NETMAP support, but shorewall show capabilities
doesn't show it. I guess I need to recompile the kernel - hopefully just
a case of setting CONFIG_IP_NF_TARGET_NETMAP=y in a file somewhere and
typing make. I don't expect you to tell me how to do that but any quick
pointers would be appreciated (Linux Mint - based on Ubuntu - based on
Debian as I understand).

Regards - Philip


On 08/04/2014 22:48, Tom Eastep wrote:
 On 4/8/2014 2:01 PM, Philip Le Riche wrote:
 Folks -

 New round these parts (though not to firewalls), so please bear with any
 stoopid questions.

 I'm setting up Shorewall on a Linux Mint box in order to isolate a
 Raspberry Pi farm in a school, allowing access by ssh and vnc from
 school PCs and the Pis to access the Internet for updates and package
 downloads. Pretty much all else unnecessary is blocked. After a fairly
 thrilling scramble up the learning curve it all seems to work and just
 needs validating and tidying up. One or two questions have arisen on the
 way though:

 1. I'm using DNAT to map the Pi ip addresses (on their own private
 subnet) onto addresses on the school network. I did something logically
 similar some years ago for a completely different application, which I
 did with static NAT on a Cisco PIX. In that case, the PIX determined
 that it had an interest in those pre-NATted ip addresses and responded
 to ARP requests for them just as part of the day job. I vaguely assumed
 the same would happen here until I realised I'd probably have to
 explicitly add the pre-NATted ip addresses to the outer interface, which
 I did by hand. Question: would Shorewall have done that for me if I'd
 been a bit more patient? Maybe I went ahead before I'd got Shorewall to
 understand where I was going with this.
 Check out the ADD_DNAT_ADDRS in shorewall.conf.

 2. I'd like to parameterise this where I can to facilitate reuse in
 other schools if it turned out to be useful. I've just stumbled across
 the params file, which I don't remember seeing on my way up the learning
 curve, but on the face of it, it only appears to allow parameterisation
 of complete lexical items. But having done a bit of shell and Perl in my
 time I was tempted to try:
 Schoolnet=172.16.1
 Pinet=192.168.1
 and in my rules, brandish something like:
 DNATskoolpinet:${Pinet}.1tcpssh${Schoolnet}.129
 (There will need to be a number of such lines.) It seems to work. Am I
 playing with fire?
 That should work fine.

 3. Is there a more succinct way of performing a linear mapping of one
 block of ip addresses onto another, rather than repeated lines as above?
 I thought I could map one CIDR range onto another with the PIX, but my
 memory is a bit hazy from more than 10 years ago.
 Check out http://www.shorewall.org/netmap.html

 4. Changing DROP to REJECT quickly found my last bug, but I never got
 logging to work. I created /var/log/messages in order to eliminate an
 error, but putting debug in the LOG LEVEL field of the policy file
 didn't do anything. In fact, I've never had anything  beyond the startup
 message in /var/log/messages. I've never had occasion to more than
 scratch the surface of syslog so this may be a silly question. Is there
 something I'm missing?
 http://www.shorewall.org/shorewall_logging.html

 Anyway, great work Tom. Having quickly dismissed gufw and geared myself
 up if necessary to fight with raw iptables, you've saved me a lot of work!
 Thanks Philip!

 -Tom


 --
 Put Bad Developers to Shame
 Dominate Development with Jenkins Continuous Integration
 Continuously Automate Build, Test  Deployment 
 Start a new project now. Try Jenkins in the cloud.
 http://p.sf.net/sfu/13600_Cloudbees


 ___
 Shorewall-users mailing list
 Shorewall-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/shorewall-users

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration

[Shorewall-users] Checking out my success

[Philip Le Riche]

Folks -

New round these parts (though not to firewalls), so please bear with any
stoopid questions.

I'm setting up Shorewall on a Linux Mint box in order to isolate a
Raspberry Pi farm in a school, allowing access by ssh and vnc from
school PCs and the Pis to access the Internet for updates and package
downloads. Pretty much all else unnecessary is blocked. After a fairly
thrilling scramble up the learning curve it all seems to work and just
needs validating and tidying up. One or two questions have arisen on the
way though:

1. I'm using DNAT to map the Pi ip addresses (on their own private
subnet) onto addresses on the school network. I did something logically
similar some years ago for a completely different application, which I
did with static NAT on a Cisco PIX. In that case, the PIX determined
that it had an interest in those pre-NATted ip addresses and responded
to ARP requests for them just as part of the day job. I vaguely assumed
the same would happen here until I realised I'd probably have to
explicitly add the pre-NATted ip addresses to the outer interface, which
I did by hand. Question: would Shorewall have done that for me if I'd
been a bit more patient? Maybe I went ahead before I'd got Shorewall to
understand where I was going with this.

2. I'd like to parameterise this where I can to facilitate reuse in
other schools if it turned out to be useful. I've just stumbled across
the params file, which I don't remember seeing on my way up the learning
curve, but on the face of it, it only appears to allow parameterisation
of complete lexical items. But having done a bit of shell and Perl in my
time I was tempted to try:
Schoolnet=172.16.1
Pinet=192.168.1
and in my rules, brandish something like:
DNATskoolpinet:${Pinet}.1tcpssh${Schoolnet}.129
(There will need to be a number of such lines.) It seems to work. Am I
playing with fire?

3. Is there a more succinct way of performing a linear mapping of one
block of ip addresses onto another, rather than repeated lines as above?
I thought I could map one CIDR range onto another with the PIX, but my
memory is a bit hazy from more than 10 years ago.

4. Changing DROP to REJECT quickly found my last bug, but I never got
logging to work. I created /var/log/messages in order to eliminate an
error, but putting debug in the LOG LEVEL field of the policy file
didn't do anything. In fact, I've never had anything  beyond the startup
message in /var/log/messages. I've never had occasion to more than
scratch the surface of syslog so this may be a silly question. Is there
something I'm missing?

Anyway, great work Tom. Having quickly dismissed gufw and geared myself
up if necessary to fight with raw iptables, you've saved me a lot of work!

Best regards - Philip


--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users