Just go live pfsense. A few hickups needed help

bthoven

Wow...thanks it is working now! Is it the right setting?

johnpoz

Well if its working - I would have to say "yes" hehehe

You understand your source natting to ALL of your 192.168.2 network with that.. Which might not be a big deal, but if you have stuff on your network that you might want know the IP that is talking to it from your vpn, or might want to firewall on the box, etc.

Its normally better to be as specific as possible with rules, vs blanket sort of cover all sort of rules. I assume your other devices on your lan use pfsense as their gateway... And don't require the source nat.. So your dest should be more directed 192.168.2.254/32 so it only source nats to your wifi router IP.

edit: I see you changed it..

bthoven

@johnpoz Yes, I saw it covered all. So I changed it to be specific to 254 only. Thanks a lot. I'm noob to network; you patience and detailed explanation are really appreciated.

stephenw10

I would often recommend looking at OpenWRT/DD-WRT in cases like this as that would allow you to configure it correctly without the NAT workaround.
But it looks like the wifi in the Broadcom chipset for the Archer C9 is not supported (likely some closed source firmware) so that kinda defeats the point!

Steve

bthoven

@stephenw10 Thanks. Is there any harm doing this kind of workaround?
Another question: should I disable the firewall function in the Archer C9?

johnpoz

There is no harm, just a work around for a limitation in your device. As to firewall on your wifi router - its not doing anything.. It only firewalls between wan and lan, and your not doing any traffic that direction.. Your just using its bridge between the wifi an the lan... So yeah you can turn it off if you want to save a few cpu cycles on the thing.

Gertjan

@johnpoz said in Just go live pfsense. A few hickups needed help:

its not doing anything..

But it might do something useful ;)

First case :

#!/bin/sh
/usr/sbin/iptables -I INPUT -s 192.168.2.1 -p tcp --dport 22 -j ACCEPT
/usr/sbin/iptables -I INPUT -s 192.168.2.1 -p tcp --dport 80 -j ACCEPT
/usr/sbin/iptables -I INPUT -i br0 -s 192.168.2.0/24 -p tcp --dport 80 -j DROP
/usr/sbin/iptables -I INPUT -i br0 -s 192.168.2.0/24 -p tcp --dport 21 -j DROP
/usr/sbin/iptables -I INPUT -i br0 -s 192.168.2.0/24 -p tcp --dport 22 -j DROP
/usr/sbin/iptables -I INPUT -i br0 -s 192.168.2.0/24 -p tcp --dport 23 -j DROP
/usr/sbin/iptables -I INPUT -i br0 -s 192.168.2.0/24 -p tcp --dport 443 -j DROP

My AP lives on 192.168.2.2 - it will accept incoming conections from 192.168.2.1 (= pfSense) and no one else.
This means : visitors that use my captive portal (the 192.168.2.x guys) can not connect to my AP.

Now, more complicated : I do not want that captive portal visitor 1 can browser shared files of captive portal visitor 2.
Normally, I don't care if people share their drives even on public network, it's up to them.

So, I activated "Isolate network" on my AP's :

Which blocks traffic coming in via via and leaving via wifi (== to other connected users).
Now, my clients can only use the gateway (= pfSense) and no one else. Even when they scan the entire Captive portal network (192.168.2.0/24).

There is a caveat : I have multiple AP's. 192.168.2.2, 3 4 and 5.
AP isolation between AP's does NOT work. The Wifi traffic comes into one AP, leaves by it's LAN interface, enters another AP-LAN interface and leaves by the Wifi .

So, I added this :

#!/bin/ash
insmod ebtables
insmod ebtable_filter
ebtables -t filter -A FORWARD -s 0:0:0:0:0:0/0:0:0:0:0:0 -d Broadcast -j ACCEPT
ebtables -t filter -A FORWARD -s 0:0:0:0:0:0/0:0:0:0:0:0 -d 00:0f:b5:fe:4e:e7 -j ACCEPT
ebtables -t filter -A FORWARD -s 00:0f:b5:fe:4e:e7 -d 0:0:0:0:0:0/0:0:0:0:0:0 -j ACCEPT
ebtables -t filter -A FORWARD -j DROP
## end

Note "00:0f:b5:fe:4e:e7 " is the MAC of my pfSense Captive portal interface.

What ebtables (a Linux MAC based firewall does, is accepting broadcasting to any - needed for DHCP business.
Traffic from "00:0f:b5:fe:4e:e7" and to "00:0f:b5:fe:4e:e7" is ok.
The rest is dropped. Clients are truly isolated. One big perfect public network.

ebtables is NOT iptables.

Btw : all this is possible when you use some firmware that is meant to be used an an real AP. Like DD-WRT.

johnpoz

Yeah if he could leverage the firewall on the side of lan - and the control that comes with actual being able to access/add/edit firewall rules.. Sure ok could be useful..

But to be honest in most of these soho firmwares its an on/off button ;) at best he might be able to block access to the gui from wireless network ;)

I would check that - do you want wireless to be able to access the gui? If not check that when you turn off the firewall that feature still works.

Gertjan

@johnpoz said in Just go live pfsense. A few hickups needed help:

do you want wireless to be able to access the gui?

These firewall rules - the iptables rules mentioned above - on the AP protect the GUI of the AP itself.

pfSense can protects itself very well already (using some rules on the portal interface) ;)

johnpoz

But unless he puts 3rd party on it - he is not going to have such control in the soho native firmware. He might have a check box to block or allow wireless access to the gui.