Hi all, happy new year.
To test if the problem could be other things running / configured on the machine I built the same setup on a raspberry pi4 running raspian (buster). Nothing else is installed besides hostapd for the wifi AP, the bridge-utils and shorewall. I get the same issue - all traffic is blocked as per policy even if the connection is initiated from the privileged network (e.g. creating a ssh connection to a machine in 'tech'. When doing 'shorewall clear' the conneciton works. I feel I might have missed something incredibly trivial, so I reread https://shorewall.org/bridge-Shorewall-perl.html but didnt find anything. Does anyone know if in the setup displayed in the 2nd picture of the page is supposed to allow an ssh connection from 192.168.1.2 into 192.168.1.10 with the configuration shown in that section of the text? Regards Markus Am Mo., 23. Dez. 2019 um 10:08 Uhr schrieb Markus Reitschuster < markus.reitschus...@googlemail.com>: > Tom, in shorewall.conf RELATED_DISPOSITION=ACCEPT is set. In the rules > files I have only entries in ?SECTION ALL. > > Justin, my rules file looks like this (I have removed most of the > commented lines): > > ?SECTION ALL > # Allow DNS requests > DNS(ACCEPT) tech ofen:192.168.1.2 > DNS(ACCEPT) ofen:192.168.1.2 tech > > # Allow DHCP requests > DHCPfwd(ACCEPT) ofen tech > DHCPfwd(ACCEPT) tech ofen > > ?SECTION ESTABLISHED > ?SECTION RELATED > ?SECTION INVALID > ?SECTION UNTRACKED > ?SECTION NEW > > > Am Mo., 23. Dez. 2019 um 05:49 Uhr schrieb Tom Eastep < > teas...@shorewall.net>: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> >> >> On 12/22/19 2:08 PM, Markus Reitschuster wrote: >> > Hi all, >> > >> > I have a bridged firewall and am unable to ssh from the privileged >> > part into the unprivileged part. >> > >> > I am trying to configure shorewall on a device (nano) that bridges >> > 2 parts of my local network - 'ofen' and 'tech'. turris is my >> > router to the internet. Shorewall is running on 'nano'. nano has a >> > bridge br0 between eth0 (connected to the switch connecting to >> > turris and all other devices on 'ofen') and wlan0 (hostapd >> > running, offering the 'tech' network) >> > >> > tech <-> nano <-> ofen <-> turris <-> inet >> > >> > clients that connect to 'tech' are using the DNS and DHCP from the >> > 'ofen' network. Both networks use the same subnet. I added rules >> > allowing DNS and DHCP in /etc/shorewall/rules - this works. Iin >> > general connections originating from tech targeting ofen should be >> > dropped. Connections from ofen to tech should be accepted. >> > Background is that in tech I put some devices that I do not want to >> > let phone home, e.g. IP cam that I still want to access from my >> > computer. The policy file is quite simple: >> > >> > ofen all ACCEPT debug all fw >> > ACCEPT fw all ACCEPT all all REJECT >> > debug >> > >> > nano is running armbian (based on Ubuntu Bionic) with shorewall >> > 5.1.12.2 and a 4.4 kernel for rk3399 chipset. >> > >> > When trying to ssh from a member of ofen (192.168.1.239) to a >> > member of tech (192.1688.1.247) I get the following in the >> > logfile: Dec 22 22:50:36 localhost kernel: [ 6426.160957] ofen-tech >> > ACCEPT IN=br0 OUT=br0 PHYSIN=eth0 PHYSOUT=wlan0 >> > MAC=b8:27:eb:25:63:bd:d4:3d >> > >> >> :7e:f6:78:26:08:00:45:00:00:3c:7d:d7:40:00:40:06:37:ae:c0:a8:01:ef:c0:a8:01:f7:91:28:00:16:83:65:82:7d:00:00:00:00:a0:02:fa:f0:c8:da:0 >> > >> > >> 0:00:02:04:05:b4:04:02:08:0a:9c:ed:ca:ee SRC=192.168.1.239 >> > DST=192.168.1.247 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=32215 DF >> > PROTO=TCP SP T=37160 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0 Dec 22 >> > 22:50:36 localhost kernel: [ 6426.173197] tech-ofen REJECT IN=br0 >> > OUT=br0 PHYSIN=wlan0 PHYSOUT=eth0 MAC=d4:3d:7e:f6:78:26:b8:27 >> > :eb:25:63:bd:08:00 SRC=192.168.1.247 DST=192.168.1.239 LEN=60 >> > TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 DPT=37160 >> > WINDOW=2896 0 RES=0x00 ACK SYN URGP=0 Dec 22 22:50:38 localhost >> > kernel: [ 6428.176904] ofen-tech ACCEPT IN=br0 OUT=br0 PHYSIN=eth0 >> > PHYSOUT=wlan0 MAC=b8:27:eb:25:63:bd:d4:3d >> > >> >> :7e:f6:78:26:08:00:45:00:00:3c:7d:d8:40:00:40:06:37:ad:c0:a8:01:ef:c0:a8:01:f7:91:28:00:16:83:65:82:7d:00:00:00:00:a0:02:fa:f0:c0:fa:0 >> > >> > >> 0:00:02:04:05:b4:04:02:08:0a:9c:ed:d2:ce SRC=192.168.1.239 >> > DST=192.168.1.247 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=32216 DF >> > PROTO=TCP SP T=37160 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0 Dec 22 >> > 22:50:38 localhost kernel: [ 6428.191862] tech-ofen REJECT IN=br0 >> > OUT=br0 PHYSIN=wlan0 PHYSOUT=eth0 MAC=d4:3d:7e:f6:78:26:b8:27 >> > :eb:25:63:bd:08:00 SRC=192.168.1.247 DST=192.168.1.239 LEN=60 >> > TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=22 DPT=37160 >> > WINDOW=2896 0 RES=0x00 ACK SYN URGP=0 >> > >> > Similar things happen if I put up an apache2 on a member of 'tech' >> > and try to access it from 'ofen'. It was my understanding that with >> > the above policy bidirectional connections can be established, if >> > they are initiated by a member of subzone ofen. But it seems I am >> > either missing a piece of the puzzle or having a major >> > misunderstanding in how networking works. >> > >> > Regards & Happy Holidays >> >> In shorewall.conf, what is the RELATED_DISPOSITION setting? And do you >> have entries in the RELATED section of the rules file? >> >> Thanks, >> >> - -Tom >> - -- >> Tom Eastep \ Q: What do you get when you cross a mobster with >> Shoreline, \ an international standard? >> Washington, USA \ A: Someone who makes you an offer you can't >> http://shorewall.org \ understand >> \_______________________________________________ >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - http://gpgtools.org >> >> iQIzBAEBCgAdFiEEFNMNR63CLO6yqbL8luaz8kI6TRAFAl4ARyYACgkQluaz8kI6 >> TRCvCw//VJ9Nxb6gIlNoVzhbTS633pbcMJEHuru1HLQlJnnnYnO+ujt/wlRJgUpx >> dA8qKUe5B885XUQ7M2MkLSTSbfMqw/pgVfE1pxAGElnqkInn1GuQo8lySmBf1SAK >> YzJ7FhGwe2ipl5qVu50s3lzORVcTZ0ZhkNivTXXBMS1Rs8C9bFaQ8odqi3oMGP6j >> HUVeB2IgL3BcyWZ/bxgw4LmEytWzYjbpmb5cOUxYcxJAvcJXt7f1dRENmPJWqRTi >> KNDUdrkPGb23WT/OsuRVxd3FNwTK2m2y/iAAV/KO4jjMWOYunMHH6b+ZAQcxKLog >> 2QtBR/2qO6yB2yT3XYUrlu/ybR8D8tA37odKF6lDxk5Q5geDOX1z8UDat0v1ol4i >> dEA5wJ+KmBx+8W6apTnc2l7zFM/RvIZy6uYN39ItkiT9PlaJJwu78WbI1rK/oOue >> GXTkTDPW8wcSVkSCtnCwJ1xzOJ/QT6cJxi+wNXjpt3ZpXBvRqphCTBsW544fCy4S >> RjbKzLAdpMPRJga1UfJbomiwzbe8CKljSvWCr1HYV79dwIxoA61GEME2iHELeb0q >> 1eImzkn5cnt/jjVCsfC5LQ4UCgO72YtWzpaqk/+tqzKSIixKt1B0FIsC2KrYEdXs >> 05Cy6mc8IED81zoDqKAR3riPBmIytGnQaUn8z49dW44F6dzlUE4= >> =w30P >> -----END PGP SIGNATURE----- >> >> >> _______________________________________________ >> 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
