Just go live pfsense. A few hickups needed help

bthoven

@johnpoz thank. Yes, the gateway was set to pfSense ip (192.168.2.1).
Also set port forwarding on pfSense, still can't access from public internet (neither with/without openvpn connection).

Gertjan

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

Also set port forwarding on pfSense, ....

No need to.
I can access my AP's (192.168.2 - 192.168.2.3 - 192.168.2.4 ....... 192.168.2.7) just fine from a device (PC) on my LAN (192.168.1.17 - pfSense is 192.168.1.1/.24).
Never tried to connected to them - their WebGUI - using OpenVPN, from the outside, but I guess it works just fine.

What are your firewall rules on the OpenVPN interface ?
Rules on the OPT1 interface ? (these shouldn't matter normally).

edit :
Connected my Phone using OPenVPN to pfSense (from the outside) and visited an AP 1292.168.2.2 : works just fine.

johnpoz

Les see these settings on your AP for this gateway. Your running 3rd party firmware on it? I do not recall ever seeing native firmware that allows for setting a gateway on the lan interface.

What port forwarding did you set? It is done different for a source nat..And would ONLY be required if your AP didn't support a gateway. And its not really a port forward, it would be an outbound nat on your inside interface.

Please post screenshot of your AP lan interface settings. And delete any port forwarding you might of setup to access your AP..

Also lets see your lan rules - your not sending stuff out some gateway on the rules are you? They are the default any any rule? Yoru not going to want to open up your AP gui from the public internet!!!

stephenw10

No default route would be my guess too. Or maybe some local firewall restriction.

You could probably workaround both with an outbound NAT rule on the pfSense LAN but it would be better to fix the AP.

Steve

bthoven

@Gertjan Thanks for testing yours. I search the net and found a lot of TPLink users facing this issue. Strange.

bthoven

@johnpoz
I'm running TPLink stock firmware. You are right, there is no gateway setting on LAN setting page. I set it on DHCP page which I was not supposed to set; but I did because, if not, it will default to TPLink Lan IP (254) instead of PfSense IP (1) and all the wifi connected devices will not be able to have internet connection. I know it sounds silly, but true.

My pfSense LAN rules are all automatically populated. No tweak.

One question, should I disable all firewall protection on my TPLink? Not sure it is relevant.

bthoven

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

No default route would be my guess too. Or maybe some local firewall restriction.

You could probably workaround both with an outbound NAT rule on the pfSense LAN but it would be better to fix the AP.

Steve

Thanks. How to do that?

johnpoz

Yeah like I thought - see your lan settings, there is not gateway there. So when you talk to this device, from something other than 192.168.2.x it has no idea how to get back to you.

You have a couple of options

put 3rd party firmware on it that allows you to set a gateway on the lan interface. Say dd-wrt if your tplink support that
use source natting on pfsense so traffic from other network, or your vpn tunnel network looks like it comes from pfsense 192.168.2.1 address.

How do that is with outbound nat on our lan interface..

switch to hybrid outbound nat, and add a rule using your lan interface with a destination of your tplink 192.168.2.254 and source as your tunnel network, interface as the IP..

Like this. Keep in mind your settings will be slightly different to keep with your setup. But I have multiple local networks... So if I ping on a IP in my dmz segment 192.168.3.31 from a box on my lan 192.168.9/24 and capture that with sniff on the .31 box you can see the IP is coming from my 192.168.9 address

root@pi:/home/pi# tcpdump icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:54:01.567454 IP 192.168.9.100 > 192.168.3.31: ICMP echo request, id 1, seq 757, length 40
07:54:01.567771 IP 192.168.3.31 > 192.168.9.100: ICMP echo reply, id 1, seq 757, length 40
07:54:02.573583 IP 192.168.9.100 > 192.168.3.31: ICMP echo request, id 1, seq 758, length 40
07:54:02.573898 IP 192.168.3.31 > 192.168.9.100: ICMP echo reply, id 1, seq 758, length 40
07:54:03.580602 IP 192.168.9.100 > 192.168.3.31: ICMP echo request, id 1, seq 759, length 40
07:54:03.580892 IP 192.168.3.31 > 192.168.9.100: ICMP echo reply, id 1, seq 759, length 40
07:54:04.586562 IP 192.168.9.100 > 192.168.3.31: ICMP echo request, id 1, seq 760, length 40
07:54:04.586852 IP 192.168.3.31 > 192.168.9.100: ICMP echo reply, id 1, seq 760, length 40

Now if I add source nat via outbound nat so anything coming from 192.168.9/24 going to 192.168.3.31 looks like the pfsense IP connected to the dmz network 192.168.3.253

And I ping it again - you see that its coming from the pfsense IP address and not 192.168.9.100

root@pi:/home/pi# tcpdump icmp -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:52:19.736323 IP 192.168.3.253 > 192.168.3.31: ICMP echo request, id 36431, seq 753, length 40
07:52:19.736638 IP 192.168.3.31 > 192.168.3.253: ICMP echo reply, id 36431, seq 753, length 40
07:52:20.742098 IP 192.168.3.253 > 192.168.3.31: ICMP echo request, id 36431, seq 754, length 40
07:52:20.742416 IP 192.168.3.31 > 192.168.3.253: ICMP echo reply, id 36431, seq 754, length 40
07:52:21.748461 IP 192.168.3.253 > 192.168.3.31: ICMP echo request, id 36431, seq 755, length 40
07:52:21.748756 IP 192.168.3.31 > 192.168.3.253: ICMP echo reply, id 36431, seq 755, length 40
07:52:22.755955 IP 192.168.3.253 > 192.168.3.31: ICMP echo request, id 36431, seq 756, length 40
07:52:22.756239 IP 192.168.3.31 > 192.168.3.253: ICMP echo reply, id 36431, seq 756, length 40

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.