[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:
#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
raw 1 1 - enp3s0 172.18.57.254

I mark traceroute traffic in mangle with:
#ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST
# PORT(S)
MARK(1) enp2s0 - udp 33434:33523 - - -

and I route them in rtrules with:
#SOURCE DEST PROVIDER PRIORITY MARK
enp2s0 - raw 11000 1

Relevent rules are:
#ACTION SOURCE DEST PROTO DEST SOURCE RATE USER/
# PORT(S) PORT(S) LIMIT GROUP
ACCEPT pinet inet udp 33434: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

[Tom Eastep]

Post by 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: #NAME NUMBER MARK DUPLICATE
INTERFACE GATEWAY OPTIONS raw 1 1 - enp3s0
172.18.57.254
I mark traceroute traffic in mangle with: #ACTION SOURCE DEST
PROTO PORT(S) SOURCE USER TEST #
PORT(S) MARK(1) enp2s0 - udp 33434:33523 - -
-
and I route them in rtrules with: #SOURCE DEST PROVIDER
PRIORITY MARK enp2s0 - raw 11000 1
Relevent rules are: #ACTION SOURCE DEST PROTO DEST
SOURCE RATE USER/ #
PORT(S) PORT(S) LIMIT GROUP ACCEPT pinet inet
udp 33434: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
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[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

Post by Tom Eastep

Post by 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: #NAME NUMBER MARK DUPLICATE
INTERFACE GATEWAY OPTIONS raw 1 1 - enp3s0
172.18.57.254
I mark traceroute traffic in mangle with: #ACTION SOURCE DEST
PROTO PORT(S) SOURCE USER TEST #
PORT(S) MARK(1) enp2s0 - udp 33434:33523 - -
-
and I route them in rtrules with: #SOURCE DEST PROVIDER
PRIORITY MARK enp2s0 - raw 11000 1
Relevent rules are: #ACTION SOURCE DEST PROTO DEST
SOURCE RATE USER/ #
PORT(S) PORT(S) LIMIT GROUP ACCEPT pinet inet
udp 33434: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

[Tom Eastep]

Post by 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.

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

- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[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

Post by Tom Eastep

Post by 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.

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

[Tom Eastep]

Post by 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.

Okay

Post by Philip Le Riche
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

Post by Philip Le Riche
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
- --
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________

[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

Post by Philip Le Riche

Post by 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.

Okay

Post by Philip Le Riche
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

Post by Philip Le Riche
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