Cross interface talk (how to)
-
Link is to pic of my network layout.
I'm trying to figure out what the FW rule would be that would allow me to access the web GUI of my WAP from the SECURE wifi.10.0 is the management subnet
AP's static IP is 10.100.10.9As of right now, the 20.0 FW has allow any rules set up and the 10.0 FW has only one rule to allow traffic out to talk to my cloud RADIUS auth server.
Right now I have to switch to the wifi associated with 10.0 in order to access the GUI.
-
@tknospdr said in Cross interface talk (how to):
As of right now, the 20.0 FW has allow any rules set up
The rule might pass the access to the webGUI of the AP, but possibly the AP itself blocks it, because it's from outside of it's subnet.
Or it cannot route, since it doesn't have a default gateway set. -
I'll have to double-check, but I thought I was able to access the GUI when I had an ANY rule on the 10.0 interface.
-
T tknospdr referenced this topic on
-
Either something changed, or (more likely), I was on the management enabled SSID and didn't realize it.
I put the ANY rule back in place and I still couldn't get to the GUI of the AP from a different SSID.
There is no separate FW or setting that I can find that restricts access beyond normal user auth.So the question remains, can I force traffic across interfaces? Maybe it's not really a FW issue, but something else I need to do.
I used to be able to access the interface from the Internet when it was in router mode, maybe I can continue to do that by doing a port forward and hitting it from the ext IP address?
-
@tknospdr
pfSense routes traffic by default to the other interface if it is destined to a connected device. You need just a proper firewall rule to pass it.Again to what I mentioned already above:
Does the AP have a gateway setting?
If yes, is it correctly?
Is the network mask set correctly?It's probably that it blocks access from outside of its own subnet by default. Maybe there is an option to allow this.
If there is no option allowing outside accesss, you could masquerade traffic on pfSense destined to the AP as a workaround. -
Okay, so I just opened the port and am able to get on the GUI via the internet from outside the network.
So there's got to be a way to do the same thing without going outside the network and back in.
-
@viragomann said in Cross interface talk (how to):
Again to what I mentioned already above:
Does the AP have a gateway setting?Yes, 10.100.10.1, it's the address of interface it's on.
If yes, is it correctly?
I believe that's what it's supposed to be, no?
Is the network mask set correctly?
I think so, it's 255.255.255.0
-
@tknospdr said in Cross interface talk (how to):
Yes, 10.100.10.1, it's the address of interface it's on.
If yes, is it correctly?I believe that's what it's supposed to be, no?
It has to be the interface IP of pfSense. I guess, that's the case.
Is the network mask set correctly?
I think so, it's 255.255.255.0
I assume, you have a /24 subnet, so it's fine.
-
-
@tknospdr
Seems all correct so far. -
@viragomann said in Cross interface talk (how to):
@tknospdr
Seems all correct so far.Indeed, so... ?
As of right now I've set up a DDNS name and a port forward thru the WAN in order to access it no matter where I'm at, but it seems silly to send requests outside the network only to come back in for local access.
-
@tknospdr
For sure you should be able to access the AP from the other subnet.So you have a firewall rule in place to allow this?
Then enable to logging in the rule and check the log to find out if it even matches the traffic.Also enable logging of the default blocks and check if concerned packets are blocked.
Also I would sniff the packets on the interface, where the AP is connected to, to verify that both, request and respond packets are passing pfSense. Since the AP is multi-homed, maybe it sends responses out on the wrong interface. However, it shouldn't do this at all if it's really in AP-mode.
-
@viragomann said in Cross interface talk (how to):
@tknospdr
For sure you should be able to access the AP from the other subnet.So you have a firewall rule in place to allow this?
Then enable to logging in the rule and check the log to find out if it even matches the traffic.So I'm really new to pfSense. Can you help me out with what the FW rule should look like?
The management interface is on interface ETH3, the AP's static IP is 10.100.10.0, and the GUI runs on port 8001.
The interface I'm connected to when sending the requests is ETH3_20_SECURE, subnet is 10.100.20.0Also enable logging of the default blocks and check if concerned packets are blocked.
Also I would sniff the packets on the interface, where the AP is connected to, to verify that both, request and respond packets are passing pfSense. Since the AP is multi-homed, maybe it sends responses out on the wrong interface. However, it shouldn't do this at all if it's really in AP-mode.
Once I'm sure I've got the correct FW rules on the correct interfaces, then I'll tackle learning how to sniff packets et al.
The rule should be on the 20.0 interface since that's where the packets are coming from right?
-
@tknospdr
Yes, the rule has to be on the incoming interface, so ETH3_20_SECURE.So to allow access from the whole subnet the values should be:
Interface: ETH3_20_SECURE
address family: IPv4
protocol: TCP
source: ETH3_20_SECURE net
destination: single IP > 10.100.10.9
dest. port: 8001
Log checked
enter a descriptionHowever, since you said you didn't get access even with an allow any to any rule, I suspect that it's not on the firewall itself.
In Status > System Logs > Settings check "Log firewall default blocks".
Try to access and then check the firewall logs for concerned blocks.
-
Idiot power company cut the fiber to my house for the 2nd time this month.
So I'll have to wait till I get home to create any rules and do any testing.Will report as soon as I can.
-
@viragomann said in Cross interface talk (how to):
Try to access and then check the firewall logs for concerned blocks.
There are no entries in the log.
-
@tknospdr
If you've enabled all rules logging and there is nothing in the log, the packets doesn't pass pfSense obviously.
In the rule set do also see any state or bytes?Are sure that the AP is running in real AP-mode? Does it have IPs in both subnets?
Yes, you can run a packet capture on ETH3_20_SECURE to see if there is any packet coming in, when you try to access the AP from this subnet. But I'm in doubt.
-
I feel like I've tried every possible set of rules, and like you said, since even an ANY/ANY/ANY rule wasn't passing the traffic I've given up.
I created a NAT rule to pass outside traffic to the AP, and then I turned on 'Pure NAT' reflection. I know it's not the most elegant solution, but I can now access the GUI from any internal subnet as well as from outside if I need to.
-
T tknospdr referenced this topic on
-
I just re-read the thread, you also said something about IP masquerading.
How would I do that to see if it's a viable solution?
-
Answering my own question (partially).
I set up a NAT 1:1 rule and I'm now able to access the WAP GUI on it's internal IP address from this computer, but it's tenuous.
I had to create the rule using the IP address of this computer that is subject to change via DHCP.
When I changed the rule from IP to 'net' it broke.
Is there a way to do the masquerading via the whole subnet I want to connect from, or should I just stick to the NAT reflection that I've already set up?
It's certainly much faster to respond via IP.I guess it's probably not an issue for most folks, but I'm a bit of a computer hoarder, I access my network from a small army of different devices. Inside my home I may connect from my desktop Mac, or one of my two different laptops depending on where I am, then there's the iOS app I can connect on from either my iPhone or iPad. And I swap out my computers on a semi-regular basis.
I'm an Apple Certified hardware tech so I always find good deals that then make their way to my armada.