General Routing issue on new install
-
Still trying to take 'full' advantage of my new pfsense machine, but having a couple of apparently random problems. I am fairly sure that this first one is not Firewall related, but could be some simple tick-in-the-box that I've missed:
1) I have created an OpenVPN connection to home, in an attempt to access/control/review various devices while away:
iPad (OpenVPN) on the wild internet > PFS Router (OpenVPN Server & Home GW) > WAP 1 or WAP 2 or WAP 3 or other device in my LAN…
I can connect successfully to the OpenVPN server, and talk to PFS itself, as well as WAP 1, and a few other local devices. I cannot connect to, or ping WAP 2 or 3.
Both WAP 1 & 2 are identical hardware and firmware version (Asus RT-AC66 running Tomato). I thought that all settings were identical, but one is visible, the other is not. Any suggestions as to why this may occur? Is there some (obscure?) firewall setting I missed, or is there a general network setting that may help?
WAP 1 is connected to PFS via an unmanaged Gigabit switch. WAP 2 is connected via a (same-brand) 2nd unmanaged Gigabit switch (total 2), as is WAP 3 via a 3rd unmanaged Gigabit switch (total 2). Cable length is not an issue, as WAP 1 is further away. All Cat 5e ducted through the building.
PFS Router (Home GW) > Gigabit switch A > WAP 1
> Gigabit switch B > WAP 2
> Gigabit switch C > WAP 3When I am at home, all devices are accessible via WiFi/ethernet from any local device.
The strange thing is (strange to me, maybe a clue…):
iPad (OpenVPN) on the wild internet > PFS Router (Home GW) > PFS test (OpenVPN Server inside the LAN) & WAP 1 or WAP 2 or WAP 3 or other device in my LAN…
As I still have my test PFS device running, I can also connect (via OpenVPN, running on a different port) to my test PFS installation. Now I can access all devices, as the test PFS has a WAN address in the primary LAN.
So is this a Firewall/rules problem, something to do with 'hops' or something else?
Any pointers gratefully received! As soon as I've fixed this, I can shut down the test device, as I will finally have a (functional) improvement over my prior setup.
2) The second problem is that having setup a new interface (e.g. DMZ), added IP4, DHCP & Firewall rules, I cannot talk from LAN > DMZ. I'm fairly sure this is a firewall issue (but not 100%), but cannot see anything blocked or even attempted in the Firewall logs (changed settings to temporarily log everything).
As a solution, I have temporarily (disabled IP & DHCP on the interface, and) enabled LAN/DMZ to be bridged. Did I miss a simple step? Any pointers to the full steps required to prevent DMZ accessing LAN, but allow LAN to access DMZ would be appreciated.
Many thanks.
-
Success!
…but why?
It turns out that 'Switch B' was redundant, the Asus RT-AC66 had spare ports and the Switch wasn't fully utilised.
Now that the WAP is only 'one hop' from the PFS OpenVPN Server, I can access this remotely.
What setting do I need to change to get this fully working?
I cannot change the cabling for Switch C (still required), and more importantly my NAS is still inaccessible as it is connected to the Asus (now only 2 hops instead of 3).
Or is there a setting to change on the OpenVPN Server?
Many thanks again.
-
Installing RIP seems to have fixed the issue.
System/Package Manager/Available Packages/ "routed"
-
What?? Why would you need RIP?
Dude what network are you AP in.. I take it these are all on the same network? You have 3 switches daisy chained? A switch is not really a "hop" a hop is when you go through a router that makes a routing decision..
More than likely your issues with access to your AP if they are setup as AP on the same network? Are these all on the same rfc1918 network, ie 192.168.?/24 ? Is you do not have a gateway set on these other APs.. Like you do on AP 1 pointing to pfsense as their gateway.
Unless you are running RIP in your network with multiple downstream routers there is ZERO need for you to install the package that adds RIP..
-
John,
Thanks for the reply. I have absolutely no idea why I need RIP. Just wanted to report that adding it fixed whatever problem I had.
All devices are in the 192.168.31.0/24 network, all working and interconnected fine (including via an incoming IPsec tunnel). The only difference was that prior to my change I didn't have an OpenVPNServer.
Moving to pfsense was supposed to replicate (all) the existing functionality, and add OpenVPN access (as well as update/enhance security).
All of the APs are Asus Wireless Routers running Tomato. Set to 'WAN disabled' and Gateway 192.168.31.1 (which was previously a Linksys RV082, now pfsense).
I know a switch is not supposed to be a hop, but unless the switches just needed a power cycle, I have no idea why it was only half working, and now it is is 'fixed'. As reported in my 2nd/3rd posts, I only made one change at a time. Plugging everything into the Asus, instead of via a 2nd switch gave me access to WAP 2 but not 3. Adding RIP (and enabling) gave me access to WAP 3.
Having spent about a month testing the basic settings and getting OpenVPN working, I honestly expected everything to work just by swapping out my old router for pfsense.
Thanks again.
-
Going to be clear on this – RIP has ZERO to do with it.. ZERO!!!
Unless your not running tomato devices as AP Like you think, and your routing to them..
Here is the big thing.. "I have absolutely no idea why I need RIP." then clearly you don't need it!!!
How you have described your setup of your AP has ZERO to do with an old school routing protocol.. What I would really suggest you do is remove RIP and if your still having issue then troubleshoot it and actually find the actual problem vs thinking you need something you dont..
-
Just to clarify, the problem only exists when I access the 192.1.68.31.0/24 network via OpenVPN access to the (external facing) pfsense router.
I can access the pfsense interface (31.1) and some of the other internal LAN devices (31.7 - an AP, 31.10 - Server, 31.17 - a NAS) when connected via the 192.168.30.0/24 OpenVPN tunnel (firewall rules to allow traffic between these interfaces).
I could not access 31.5 (an AP), because it had two unmanaged switches between it and the pfsense gateway. Removing one switch corresponded with being able to access 31.5. No settings changed at all.
I was not able to try this for access to the 31.9 AP, (because I couldn't remove the intermediate 2nd switch).
192.168.30.2 (OpenVPN client) > 192.168.30.1 (PFS OpenVPN Server IP/LAN IP) 192.168.31.1 > 192.168.31.7 accessible
192.168.30.2 (OpenVPN client) > 192.168.30.1 (PFS OpenVPN Server IP/LAN IP) 192.168.31.1 > 192.168.31.9 not accessibleInside the LAN:
192.168.31.100 (typical client) > 192.168.31.1 accessible
192.168.31.100 (typical client) > 192.168.31.7 accessible
192.168.31.100 (typical client) > 192.168.31.9 accessible
192.168.31.100 (typical client) > 192.168.31.15 accessible
192.168.31.100 (typical client) > 192.168.31.17 accessiblePrior to introducing pfsense, as a direct replcaement for 192.168.31.1, I had a perfectly working, albeit less secure network. Just trying to find out what is the issue, that prevents access when using this OpenVPN tunnel only.
If I access an alternate OpenVPN tunnel at 192.168.31.31 (my test PFS device), everything is accessible.
10.0.9.2 (OpenVPN client from internet) > port forwarding via 192.168.31.1 > 10.0.9.1 (PFS OpenVPN Server IP/WAN IP) 192.168.31.31 > 192.168.31.1/7/9/15/17 all accessible
-
This makes ZERO sense
192.168.30.2 (OpenVPN client) > 192.168.30.1 (PFS OpenVPN Server IP/LAN IP) 192.168.31.1 > 192.168.31.7 accessible
192.168.30.2 (OpenVPN client) > 192.168.30.1 (PFS OpenVPN Server IP/LAN IP) 192.168.31.1 > 192.168.31.9 not accessibleUnless you have some really odd mask? Maybe a /29?? That would put .7 at the broadcast address and .9 in the next subnet.
Or you have some add firewall rules on your vpn interface?
What I can you for sure is RIP is not a requirement for such a setup.. And I don't see how enabling it would allow you access.. Unless you have some weird masking setup and rip is being handed off to your vpn client??? Make no sense..
So from your vpn client what route table after you connect to the vpn? You sure this other AP you can not connect to is using pfsense as its gateway with the correct mask on its network?
Your dumb switches inline would also have nothing to do with it.. Unless you had some sort of connectivity issue with its uplink and when your local your the same switch as your AP?
With the limited info I not sure exactly what your problem is - but RIP would have nothing to do with it as described where all your AP on 192.168.31/24 on your lan and your vpn users are on 192.168.30/24 And your vpn server either says hey default gateway come down the vpn or if you want to talk to 192.168.31/24 come down the tunnel.
The most likely problem is your AP you can not get to from another network is its gateway is wrong.. As to why it works alternate - that would point to it using that as its gateway.
-
sorry it didn't make sense…
OpenVPN network
192.168.30.0/24LAN
192.168.31.0/24Firewall rule
permit any from source 192.168.30.0/24 to destination 192.168.31.0/24All devices have standard mask 255.255.255.0 for /24 network.
Gateway is definitely not wrong on any device. I agree something is not right, but I have no idea what, hence my initial question.
The removal of the switch was obviously a factor, but the NAS connected to the Asus AP (that replaced the switch) was still not accessible until RIP was enabled.
The Asus Router is definitely in AP-only mode (LAN only address, with pfsense as GW & DNS. I don't know why this behaviour is happening. Apart from re-checking the obvious, I am at a loss. RIP may not have been the problem, but it did seem to be the solution.
-
RIP disabled, still working…
No other changes made to configuration or topology.
Any other clues as to what might have been the issue?
-
Can you confirm WAP 2 and WAP 3 have gateways configured? The most likely explanation is either they do not have gateways or have something other than the pfSense as a gateway (this applies to any other devices you are unable to reach via the tunnel, as well).
If the switches are unmanaged stop worrying about their effect on the network. If they are managed, unless you are fiddling with VLANs or something, just treat them like the WAPs (ie. only care if they have correct ip address and gateways configured).
EDIT: oops you said this, "Gateway is definitely not wrong on any device. I agree something is not right, but I have no idea what, hence my initial question." My bad!
-
"RIP disabled, still working…"
So now we may never know what was the issue.. But like I said RIP had zero to do with it :)
-
Update:
Obviously I spoke too soon. Now away from home, no configuration changes since I previously switched off RIP. The two hosts that were previously accessible, are no longer.
At least that's what I thought…
I am currently connected via 3 different devices to my home network. All OpenVPN users, with a separate IP address in the VPN subnet (192.168.30.0).
On my iPad, which I previously used for testing, I can still access all hosts on the 192.168.31.0 network. However, on the two Macs, which I hadn't used before, I cannot access two of the critical devices - exactly as before.
I will admit that there is definitely something very weird with my network. I have no idea what, or even how to begin diagnosing this. Firewall rules are OK, Gateway is the same, OpenVPN configurations were exported directly from pfsense. Nothing in the firewall logs to indicate what's going on…
-
" or even how to begin diagnosing this."
Well follow the packets.. So device that can access 192.168.31.9 but not .7 So when you do traceroute it goes down the tunnel? I would sniff on pfsense and make sure you see the packets come in the tunnel And then go where they are suppose to go.. Do you see an answer from the .7 box? Maybe that device is just offline? Or nobody can access it from vpn currently because pfsense doesn't know its mac, or there is duplicate IP?
So your saying that your Ipad at the same time as your other device can use .7 but your other device can not?
-
All fixed, with many thanks to @johnpoz.
My fault for neglecting to include some (vital) information, that I had posted in another thread…
https://forum.pfsense.org/index.php?topic=123209.msg680758#msg680758My APs, running Tomato, are used as alternate Gateways for devices that need an OpenVPN tunnel. At least one of the APs had two 'Default Routes'.
It was pure luck that I 'fixed' this previously, as the fix was only temporary (and random).
Adding a Static Route to the AP to permit a return path (for traffic from pfsense) appears to have been the correct solution, and probably also for the 2nd issue (DMZ) in my first post.
My follow-up task is now to prevent the Tomato box adding a 2nd default route when starting an OpenVPN client session.
Once again, many thanks to John - without whom, this would still be a puzzle.
I should add that the OpenVPN clients are scheduled for removal from the APs, and integrated into pfsense…
... one step at a time... -
Glad we got it worked out, great that you were in chicagoland, and thanks for lunch! ;)
