Access OPT1 AP from LAN
-
I have an Wifi AP on OPT1 that I am trying to access from the LAN. (I can ping it from PFsense)
I created these rules but still no joy.
Can some one please enlighten me on this…on LAN:
Proto Source Port Destination Port Gateway Queue Schedule Description-
LAN net * * * * none Default LAN -> any
-
LAN net * OPT1 net * * none Lan -> ZimmerReef
on OPT1:
Proto Source Port Destination Port Gateway Queue Schedule Description- OPT1 net * * * * none Default ZimmeReef -> any (OPT1)
TCP LAN net * OPT1 net * * none Lan -> ZimmerReef
-
-
AP is likely missing its default gateway from the sounds of it.
-
There is no place to set a default GW on the AP.
The AP is an old D-Link wifi router that I connected one of it's LAN ports directly to OPT1. I disabled it's internal DHCP and enabled DHCP on OPT1.
I also set the LAN address on the AP to be in the same range as OPT1, and as I said, I can ping the AP from PFsense's Diagnostics page.Do you mean that I need to set something on the "System: Gateways" page ?
If so, is there any documentation as for how to do so ? -
If the AP doesn't have a default gateway, you can't talk to it from other subnets. You'll either need to setup NAT so traffic to the AP gets NATed to an IP on its subnet, or get the default gateway on the AP.
-
I am sure that I am missing you some where so i'll try again from the start.
This is my network.
I have NAT running on both LAN and OPT1 ports, as well as DHCP. I can surf on both, also by connecting trough the d-link AP.
The AP is connected by one of it's LAN ports, it's DHCP disabled and it's LAN set statically.what I want is to be able to type "192.168.40.2" in the house computers and access the AP's control panel.
I can access it from the LAB computers but they are on the same subnet.BTW
I am using the S-Box strictly as a dialer as the PPTP/L2TP features on V.2 still don't work perfectly… -
If you can't set the gateway when entering static addresses by hand, what about activating the DHCP client in the D-Link so tat it will ask a IP/mask and gateway from the DHCP server running on pfSense/OPT1 ?
The D-Link will get 192.168.40.2 as an LAN IP from pfSense, just nail it down with it's MAC address.
-
Again, I'm sure I am missing somthing.
Why do I need to set a gateway on the AP ? It's the destination.
I can access it from the computers in the LAB that are on the same subnet. (all on OPT1). I can also use the internet from laptops connected to it wirelessly as well as access the PFsense control panel.What I want is to be able to access the AP's control panel from the computers in the house, on the LAN subnet.
I triad to create FW rouls to allow trafic from LAN to pass to OPT1 but it was not working.
Do I need to do somthing else ? (like set a gateway to OPT1 somwhere on the PFsense box) or is it just FW stuff ? -
what you are missing is that the packets from the AP need to be able to find a return path to the computers NOT on its subnet. If the PC is on a different subnet, without a default gateway, the dlink has no idea where to send them.
-
To add to that, the D-link has some process like i.e. a nntp that really would like to sync with the correct nntp-server address on the net ;)
I can't say it the way danswartz said, but my rule is that any device with a Ethernet plug should have a gateway address.
Btw: I have 4 WRT54GS's as AP's on my Wifi-portal, and I can manage them very well from any PC on my LAN (192.168.1.x/24)
My Wifi-portal, subnet is 192.168.2.x/24, the AP's have x=2,3 & 4. Gateway on all of them: 192.168.2.1 (pfSense: Opt1) -
A little lesson in IP: if device A wants to talk to device B, and they are in the same subnet, device A will send an ARP request for device B's IP, which is an ethernet level broadcast. Device B will reply with its MAC address and device A will be good to go. If they are in different subnets, the broadcast ARP will not reach device B (simplified explanation.) This is why the default gateway IP has to be in the same subnet as the device using it (otherwise you have a chicken and egg problem…)
-
As much as I hate to accept it, since as for my understanding it was not supposed to be like that, it seem that you are correct. I can access other computers on that subnet, but from some reason still cant access the AP. Soooo it will have to be replaced.
The bigger problem as I can see it now is,
I was able to access OPT1 computers without any changes to the FW rules. only the basic ones.
Default opt1 -> any & Default LAN -> anyHow do I block traffic from OPT1 from reaching my privet LAN subnet. I don't want clients using the Wifi or viruses running in computers in the Lab to be able to get into my home network…
-
Change your OPT1 rule so instead of allowing any as the destination, it allows 'not LAN net'.
-
I use these rules for some years on my Portal interface:
Rule 1/2/3: These are used for each AP so they can syslog to one of my PC's on the LAN
(note: and addionnel "Captive portal::allowed IP addresses will also be needed")Rule 4: Throttle SMTP 25 ;)
Rule 5/6/7: Block some very noisy "Dos/Win" ports
Rule 8: Block all direct access to the gateway (on 192.168.2.1 = pfSense)
Rule 9 : Block access to my WAN device (it's local IP)
Rule 10: Block all that isn't for destination not WAN
Rule 11: Block everything.
-
Done Ty.
Now to get a new better AP…
-
You can work around this.
Firewall –> nat --> outbound.
Enable manual rule generation.
Create a new rule for the opt interface with source LAN-subnet and destination IP_of_AP/32.
Like this you NAT all traffic to the AP, and it appears for it as if the pfsense is accessing it (to which it knows the way back since it's in the same broadcast-domain. -
@roi:
As much as I hate to accept it, since as for my understanding it was not supposed to be like that, it seem that you are correct. I can access other computers on that subnet, but from some reason still cant access the AP. Soooo it will have to be replaced.
It's a basic rule of networking, as others have described.
You can work around it by NATing all traffic from LAN to the AP using advanced outbound NAT on the AP's interface. It still may have other complications as previously mentioned, as the AP may need NTP to sync its time or other things, and it can't get to the Internet without a default gateway either.
-
What I was expecting to happen is since PFsense is a router that it will NAT the traffic as you just wrote.
then traffic from one subnet will be seen by the AP as virtually on the same subnet.
I was not aware that the other option exist.Since then I got a Level one WAB-3001 professional outdoors AP, that have the option for default GW input.
200$ for the parts and several hours of installing work later and the WiFi to the people at my B&B was never so good.No for solving other problems…..
-
@roi:
What I was expecting to happen is since PFsense is a router that it will NAT the traffic as you just wrote.
Only that which is destined to the Internet by default. You rarely want to NAT between your internal networks, it's unnecessary overhead, and causes problems with some services (Windows file sharing primarily).
Sounds like you have a much better setup now, NATing would be a hack in that scenario.
-
If I wanted Windows file sharing to work between these computers I'd put them on the same subnet…
The Idea is to separate the lab where I fix client's computers that many time have viruses on them and the B&B where I have kid's with daddy's laptop looking around and the home network.If I had another interface I'd even separate the B&B from the lab and put a capping on it so the kid's will not kill my connection downloading video's w/Utorrent. It seem that my next toy will be a managed switch with option for speed limiting for each port ;)
-
@roi:
If I had another interface I'd even separate the B&B from the lab and put a capping on it so the kid's will not kill my connection downloading video's w/Utorrent. It seem that my next toy will be a managed switch with option for speed limiting for each port ;)
Limiters on 2.0 make that really easy, and speed limits on managed switches tend to not be as configurable (depending on the switch), so you may want to check into that in the future.