[Shorewall-users] Securely adding & isolating a *2nd* wifi SSID from a single Physical Adapter, with completely different access policy?

[d***@123mail.org]

I'm adding WiFi to my Shorewall router.

In "step 1" (earlier thread) I added a wifi adapter, device == wlan0, to zone == wifi0.

I assigned a unique segment to its DMZ, 10.128.128.0/24, whereas the rest of my LAN is on 10.1.1.0/24.

Using policies I set it up for passthrough access

net wifi0 ACCEPT
wifi0 net ACCEPT
all wifi0 REJECT
wifi0 all REJECT

got DHCP & PING working, and got hostapd running with wlan0.

Now I can log in to the wifi0 zone, get an IP in its segment, and access the net -- bypassing the 'net. Exactly what I wanted.

I learned that hostapd can broadcast multiple SSIDs on a single adapter.

As 'step 2', I want to add a second SSID for login -- but integrated into my LAN, *not* isolated from it.

I configured hostapd so that it creates two 'virtual' interfaces,

wlan0, 10.128.128.0/24
wlan1, 10.2.2.0/24

I want wlan1 'fully integrated' into my LAN -- subject to same access rules, protections etc., while wlan0 still functions exactly as above.

IIUC I can either

(1) put wlan1 on a bridge with my already setup internal ethernet interface
(2) put wlan1 in another DMZ segment, and setup access policies or rules

I understand from docs how I'd do (1).

I want to figure out how to do (2) safely.

If I assign the 2nd interface, wlan1, to a 2nd zone == wifi1, & add policies

net wifi0 ACCEPT
wifi0 net ACCEPT
all wifi0 REJECT
wifi0 all REJECT
$FW $FW ACCEPT
$FW all+ ACCEPT
+ wifi1 $FW ACCEPT
+ lan wifi1 ACCEPT
+ wifi1 lan ACCEPT

will that provide my wifi1-logged-in users full access to the LAN == lan zone, **AND** keep it safely isolated from the 'passthrough' wlan0?

I want to make sure that since 'wlan0' and 'wlan1' are both attached to the same PHYSICAL interface -- on the same adapter, coordinated/assigned by hostapd -- that I'm not somehow re-opening an insecure 'leak' between wlan0 and my LAN, by providing that access to wlan1.

DT

[Tom Eastep]

Post by d***@123mail.org
I'm adding WiFi to my Shorewall router.
In "step 1" (earlier thread) I added a wifi adapter, device ==
wlan0, to zone == wifi0.
I assigned a unique segment to its DMZ, 10.128.128.0/24, whereas
the rest of my LAN is on 10.1.1.0/24.
Using policies I set it up for passthrough access
net wifi0 ACCEPT wifi0 net ACCEPT all wifi0 REJECT
wifi0 all REJECT
got DHCP & PING working, and got hostapd running with wlan0.
Now I can log in to the wifi0 zone, get an IP in its segment, and
access the net -- bypassing the 'net. Exactly what I wanted.
I learned that hostapd can broadcast multiple SSIDs on a single adapter.
As 'step 2', I want to add a second SSID for login -- but
integrated into my LAN, *not* isolated from it.
I configured hostapd so that it creates two 'virtual' interfaces,
wlan0, 10.128.128.0/24 wlan1, 10.2.2.0/24
I want wlan1 'fully integrated' into my LAN -- subject to same
access rules, protections etc., while wlan0 still functions exactly
as above.
IIUC I can either
(1) put wlan1 on a bridge with my already setup internal ethernet
interface (2) put wlan1 in another DMZ segment, and setup access
policies or rules
I understand from docs how I'd do (1).
I want to figure out how to do (2) safely.
If I assign the 2nd interface, wlan1, to a 2nd zone == wifi1, & add policies
net wifi0 ACCEPT wifi0 net ACCEPT all wifi0 REJECT
wifi0 all REJECT $FW $FW ACCEPT $FW all+ ACCEPT +
wifi1 $FW ACCEPT + lan wifi1 ACCEPT + wifi1 lan
ACCEPT
will that provide my wifi1-logged-in users full access to the LAN
== lan zone, **AND** keep it safely isolated from the 'passthrough'
wlan0?
I want to make sure that since 'wlan0' and 'wlan1' are both
attached to the same PHYSICAL interface -- on the same adapter,
coordinated/assigned by hostapd -- that I'm not somehow re-opening
an insecure 'leak' between wlan0 and my LAN, by providing that
access to wlan1.

What I would do is simply add wlan1 to the loc zone.

- -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.net \________________________________________________

[Tom Eastep]

Post by Tom Eastep
What I would do is simply add wlan1 to the loc zone.

Make that the 'lan' zone.

- -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.net \________________________________________________

[d***@123mail.org]

Tom

Post by Tom Eastep

Post by Tom Eastep
What I would do is simply add wlan1 to the loc zone.

That's slick. I didn't think I could do that because it's on a different LAN segment. Re-reading the docs, I clearly got that mixed up!

Post by Tom Eastep
Make that the 'lan' zone.

Yep I figured :-)

Ok let's take a look.

Atm, I have

interfaces
net EXTIF optional,physical=$IETH0,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0
wifi0 WIFI0IF optional,physical=$IWLAN0,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0
wifi1 WIFI1IF optional,physical=$IWLAN1,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0
- INTIF physical=$IETH1,dhcp,tcpflags,logmartians=1,routefilter=0

To "simply add wlan1 to the loc zone", would just changing the 'wifi1' line to

- wifi1 WIFI1IF optional,physical=$IWLAN1,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0
+ loc WIFI1IF optional,physical=$IWLAN1,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0

or

- wifi1 WIFI1IF optional,physical=$IWLAN1,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0
+ - WIFI1IF optional,physical=$IWLAN1,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0

be the way to do that? (Not 100% clear yet on the implications of that "-").

DT

[Tom Eastep]

Post by d***@123mail.org
Tom

Post by Tom Eastep

Post by Tom Eastep
What I would do is simply add wlan1 to the loc zone.

That's slick. I didn't think I could do that because it's on a
different LAN segment. Re-reading the docs, I clearly got that
mixed up!

Post by Tom Eastep
Make that the 'lan' zone.

Yep I figured :-)
Ok let's take a look.
Atm, I have
interfaces net EXTIF
optional,physical=$IETH0,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0

wifi0 WIFI0IF
optional,physical=$IWLAN0,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0

Post by d***@123mail.org
wifi1 WIFI1IF
optional,physical=$IWLAN1,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0

- - INTIF
physical=$IETH1,dhcp,tcpflags,logmartians=1,routefilter=0

Post by d***@123mail.org
To "simply add wlan1 to the loc zone", would just changing the
'wifi1' line to
- wifi1 WIFI1IF
optional,physical=$IWLAN1,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0

+ loc WIFI1IF
optional,physical=$IWLAN1,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0
That's the correct thing to do.

- -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.net \________________________________________________

[Les Niles]

Post by d***@123mail.org
...
I configured hostapd so that it creates two 'virtual' interfaces,
wlan0, 10.128.128.0/24
wlan1, 10.2.2.0/24
I want wlan1 'fully integrated' into my LAN -- subject to same access rules, protections etc., while wlan0 still functions exactly as above.
IIUC I can either
(1) put wlan1 on a bridge with my already setup internal ethernet interface
(2) put wlan1 in another DMZ segment, and setup access policies or rules
...

In the spirit of ignoring your actual question and offering advice instead:
You should decide if you want the Ethernet and wlan1 segments to be on the same LAN. If you want systems on the Ethernet to be able to discover services on wlan1 and vice-versa, or use the same pool of IP addresses, then bridging the two networks is the way to go. If not, then making them separate LANs gives options for managing them separately if you decide that's useful. Some consider any wifi to be inherently less secure, for example, since it has less physical constraints on access.

-Les

[d***@123mail.org]

With the setup advised in this thread, I've got secure/authenticated connectivity for the adapter; I can login with specified used credentials from my test-device -- my Android phone.

Once connected, I can run a speed test -- and performance is GREAT: 75Mbps x 25Mbps.

Unfortunately, that's NOT my LAN/ISP connection -- that's Cell-network speeds !?

If I turn OFF my phone's "Mobile Networks", leaving ONLY the WiFi connectivity, there's no more connectivity at all.

If I turn on info=level logging in policy for the Wifi zone,

net wifi0 ACCEPT info
wifi0 net ACCEPT info
all wifi0 REJECT info
wifi0 all REJECT info


I do see plenty of these

Mar 14 08:31:21 rbox kernel: [53995.695471] SW:[P4]wifi02net:ACCEPT IN=wlan0 OUT=enp1s0 SRC=10.128.128.200 DST=8.8.8.8 LEN=63 TOS=0x00 PREC=0x00 TTL=63 ID=27812 DF PROTO=UDP SPT=15906 DPT=53 LEN=43

Mar 14 08:31:21 rbox kernel: [53995.809845] SW:[P4]wifi02net:ACCEPT IN=wlan0 OUT=enp1s0 SRC=10.128.128.200 DST=8.8.4.4 LEN=73 TOS=0x00 PREC=0x00 TTL=63 ID=27824 DF PROTO=UDP SPT=23073 DPT=53 LEN=53

which clearly shows traffic going out the physical ethernet through my ISP connection, but no other traffic.

I also have in rules

DHCPfwd(ACCEPT) $FW wifi0
Ping(ACCEPT) $FW wifi0

I've obviously missed something. Again.

What do I need to get ALL the traffic to/from the WiFi-attached cell-phone working over WiFi only?

DT

[Tom Eastep]

Post by d***@123mail.org
With the setup advised in this thread, I've got
secure/authenticated connectivity for the adapter; I can login with
specified used credentials from my test-device -- my Android
phone.
Once connected, I can run a speed test -- and performance is GREAT: 75Mbps x 25Mbps.
Unfortunately, that's NOT my LAN/ISP connection -- that's
Cell-network speeds !?
If I turn OFF my phone's "Mobile Networks", leaving ONLY the WiFi
connectivity, there's no more connectivity at all.
If I turn on info=level logging in policy for the Wifi zone,
net wifi0 ACCEPT info wifi0 net ACCEPT info all wifi0
REJECT info wifi0 all REJECT info
I do see plenty of these
Mar 14 08:31:21 rbox kernel: [53995.695471] SW:[P4]wifi02net:ACCEPT
IN=wlan0 OUT=enp1s0 SRC=10.128.128.200 DST=8.8.8.8 LEN=63 TOS=0x00
PREC=0x00 TTL=63 ID=27812 DF PROTO=UDP SPT=15906 DPT=53 LEN=43
Mar 14 08:31:21 rbox kernel: [53995.809845] SW:[P4]wifi02net:ACCEPT
IN=wlan0 OUT=enp1s0 SRC=10.128.128.200 DST=8.8.4.4 LEN=73 TOS=0x00
PREC=0x00 TTL=63 ID=27824 DF PROTO=UDP SPT=23073 DPT=53 LEN=53
which clearly shows traffic going out the physical ethernet through
my ISP connection, but no other traffic.
I also have in rules
DHCPfwd(ACCEPT) $FW wifi0 Ping(ACCEPT) $FW wifi0
I've obviously missed something. Again.
What do I need to get ALL the traffic to/from the WiFi-attached
cell-phone working over WiFi only?

Please forward the output of 'shorewall dump' collected as described
at http://www.shorewall.net/support.htm#Guidelines

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.net \________________________________________________

[Simon Hobson]

Post by d***@123mail.org
I do see plenty of these
Mar 14 08:31:21 rbox kernel: [53995.695471] SW:[P4]wifi02net:ACCEPT IN=wlan0 OUT=enp1s0 SRC=10.128.128.200 DST=8.8.8.8 LEN=63 TOS=0x00 PREC=0x00 TTL=63 ID=27812 DF PROTO=UDP SPT=15906 DPT=53 LEN=43
Mar 14 08:31:21 rbox kernel: [53995.809845] SW:[P4]wifi02net:ACCEPT IN=wlan0 OUT=enp1s0 SRC=10.128.128.200 DST=8.8.4.4 LEN=73 TOS=0x00 PREC=0x00 TTL=63 ID=27824 DF PROTO=UDP SPT=23073 DPT=53 LEN=53
which clearly shows traffic going out the physical ethernet through my ISP connection, but no other traffic.

Being pedantic, it shows the packet being matched by a rule or policy. A packet sniffer would show if it was actually going out through the interface.

The first thing that comes to mind is ... do you have an entry in masq that will change the source address ? That's bitten me more than once :-(

[d***@123mail.org]

Post by Simon Hobson
Being pedantic, it shows the packet being matched by a rule or policy. A packet sniffer would show if it was actually going out through the interface.

Ok good point.

Post by Simon Hobson
The first thing that comes to mind is ... do you have an entry in masq that will change the source address ? That's bitten me more than once :-(

Yeah, I had that in place.

I'm working on simplifying. I'm bound and determined to get this figured out this time by reading the manuals and understanding the way things work! :-)

I've removed the "passthrough Guest" for the moment, and switched to JUST a WiFi connection into the shorewall-defined LAN.

As I understand it this *should* work just like everything else already in/on my LAN.

If I attach a standalone WiFi router, configured as an AccessPoint, to my LAN

router
|
| ( "INT" interface )
|
ethernet switch
|
|-- standalone AP
|
( my LAN )

and connect a phone to it, the phone's *in* my shorewall-defined LAN, everything works fine. I can access the net from my phone, just

If instead I set it up with a WiFi adapter,

( "WIFI" interface )
router ---------------------- USB WiFi adapter
|
| ( "INT" interface )
|
ethernet switch
|
|
( my LAN )

with hostapd & dhcpd running on the router, and the WiFi adapter added to the LAN in shorewall's "interfaces"

net EXT optional,physical=$EXTIF,dhcp,tcpflags,nosmurfs,logmartians=1,routefilter=1,sourceroute=0
lan WIFI optional,physical=$WIFIIF,dhcp,tcpflags,logmartians=1,routefilter=0
- INT physical=$INTIF,dhcp,tcpflags,logmartians=1,routefilter=0

I can

(1) see the WiFi adapter's hostapd-generated SSID scan
(2) connect/authenticate the phone to the AP
(3) get a dhcpd-generated IP address for the phone

where the dhcpd server is listening additionally on the $WIFIIF.

But I can't access the 'net from the phone over WiFi.

Now I need to figure out what policy, rule, whatever -- above & beyond what the LAN rules/policies already allow -- is needed to get that last step of communicating "across" the WIFI interface to the net.