Just go live pfsense. A few hickups needed help
-
Before disabling my wifi router dhcp, it has ip 192.168.2.1. My new pfsense box ip is also 192.168.2.1 in order to maintain IP addresses of all my devices.
Is it possible this could cause the problem of not being able to see my wifi router online?
-
Well you can not have duplicate IPs and expect anything to work for either of those machines sharing the IPs ;) Or any other device on the network that needs to talk to say pfsense on 2.1 since it prob ends up sending the traffic to your AP 2.1
If your AP was 192.168.2.1, and pfsense is also pfsense 2.1, change one of them to 2.2
-
@JKnott said in Just go live pfsense. A few hickups needed help:
Why do people always say turn off the DHCP server? Multiple servers are allowed
Sure.
Instead of shutting one down, you should manage the two or more so they give the same (DNS, gateway, etc) info. Also, pool sizes should be identical. Or, wait, know : make a mix up and see what happens ....Btw : admins are lazy : admin one thing, or admin 2 things ? Who wins ?
Also : it's more easy to write "shut it off" as "set them all up correctly". The first contains less words.
And : .... I have 5 AP's running with pretty identical settings for my captive portal. I have to run all over these devices to check if my pool is about to be depleted ?
Just imagine : only one slot is left. Some DHCP server wins, but the IP he chooses is already used. He chooses another one ... used also. etc etc etc. The whole pool has to be actively analysed. I guess this will need some network traffic - or a single server just checks his list and knows that this is the last IP.Last but not least :
Advertise : "run multiple DHCP servers on a LAN segment and the DHCP and DNS forum will get a whole boatload of "new issues" ^^Final : I 'trust' the DHCP server pfSense is using. Without any judgements coming from me, I do probably trust less the DHCP server on "some AP".
-
@johnpoz said in Just go live pfsense. A few hickups needed help:
change one of them to 2.2
Chagge the IP of the AP, and set the gateway and DNS on that AP to "192.168.2.1".
You'll be fine. -
Why are you telling them to do that @Gertjan - they could change pfsense to 2.2 if they wanted to.. There is nothing saying that pfsense should be .1
Why would you tell them to do that ;) hehehehe
-
Thanks again for all your replies. It seems the problem of accessing Archer C9 admin page after disabling dhcp is a common one as seen in this thread:
https://awesometoast.com/archer-c9/
Still not sure how to solve it; though both wired and wireless connections to Archer C9 work fine. -
Not sure where you got that from - its one guy that said that... You know what happen, his client he connected to didn't get an IP address because he had NO dhcp server running ;)
I have been doing this since there was wifi router, back in the B wifi days... Disabling dhcp server is not going to stop you from talking to the IP address you set on the thing ;)
But yeah your going to have to have an IP on your client with the correct ip and mask to talk to the IP you set on the thing ;)
-
Okay, thanks. I will have to detach it from pfsense box, reset it, assign fixed ip 192.168.2.2 (or .254), disable dhcp, change wifi ssid/password... and plug it back. May have to wait till my family are all sleeping to do that :)
-
only if your having issues talking to it because of the dupe IP.. If you can log into currently no reason to disconnect it
Why do you think you need to change the ssid, and reset??
-
@johnpoz said in Just go live pfsense. A few hickups needed help:
only if your having issues talking to it because of the dupe IP.. If you can log into currently no reason to disconnect it
Now I can't talk to it. It doesn't even show in the dhcp lease list.
Why do you think you need to change the ssid, and reset??
No, I don't want to change the ssid; as now I can't talk to the wifi router, I may have to reset it to factory default before doing the setup again with same ssid, but with different fixed LAN IP, and dhcp disabled.
Sorry for any confusion I may have made.
-
why would it show up in the dhcp lease? Ever? The lan IP of all wifi routers is set as static.. kind of hard to run a dhcp server when your also a dhcp client..
No you wouldn't have to reset it.. You might need to disconnect it from your network and connect to its switch or wifi to see its mac.. Or you could always just manipulate your clients arp table - delete the mac of the pfsense for .1 currently and let it re arp and see if you get the mac of the AP.. Or you could always set a temp static arp with the AP mac for whatever IP you wanted to use to get to it..
But sure if temp removal from the network and resetting is what you want to do - then sure that will work as well :) just not really required any down time to change is IP.
-
If it was using the same IP as pfSense I would expect to see that reported in the system logs when responds to ARP requests at the same time pfSense does.
Steve
-
Thank you for all your support.
I disconnected my wifi router and reset it. Disabled dhcp, then reconnect. Everything works fine. I set its LAN ip as 192.168.2.254, with dns server 192.168.2.1, my pfSense router IP; also reserved the 254 IP in pfSense dhcp; and the status in pfSense Status->DHCP leasing page is online. What strange is when I connected my laptop at home, I can access my wifi access point web config; but it can't be accessed via openvpn on public internet. On openvpn, I can access other local devices by local ips without problem, except the access point (tplink Archer C9 wifi router with disabled dhcp).
Any additional setting I need to make? Thanks -
Do you have a gateway (192.168.2.1 pfsense) set on the wifi router? If not no you wouldn't be able to access it gui remotely, ie your vpn tunnel network.. You would have to create a port forward so you could source nat the traffic so the wifi router thinks your coming from the pfsense 2.1 address.
-
@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). -
@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. -
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!!!
-
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
-
@Gertjan Thanks for testing yours. I search the net and found a lot of TPLink users facing this issue. Strange.
-
@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.
-
@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?
-
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
-
Wow...thanks it is working now! Is it the right setting?
-
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..
-
@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.
-
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
-
@stephenw10 Thanks. Is there any harm doing this kind of workaround?
Another question: should I disable the firewall function in the Archer C9? -
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.
-
@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.
-
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.
-
@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) ;)
-
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.