Cross interface talk (how to)
-
@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.
-
@tknospdr
There is no NAT 1:1 needed.Set a static mapping for the AP to get a fix IP via DHCP.
Masquerading is done with outbound NAT in pfSense.
Enable the hybrid mode and add a rule:
Interface: which the AP is connected to
source: your management network
destination: AP IP
translation: interface address -
I see now. I actually started with a rule in that section, but it remained in 'disabled' mode no matter what I did. I was missing the info about changing to hybrid mode.
Also, I just set up a host override for the name of the router too, and that also works now.
Thanks!