General Routing issue on new install

awair

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 accessible

Inside 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 accessible

Prior 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

johnpoz

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 accessible

Unless 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.

awair

sorry it didn't make sense…

OpenVPN network
192.168.30.0/24

LAN
192.168.31.0/24

Firewall rule
permit any from source 192.168.30.0/24 to destination 192.168.31.0/24

All 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.

awair

RIP disabled, still working…

No other changes made to configuration or topology.

Any other clues as to what might have been the issue?

imaginary_number

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!

johnpoz

"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 :)

awair

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…

IMG_0400.jpg_thumb

johnpoz

" 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?

awair

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#msg680758

My 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...

johnpoz

Glad we got it worked out, great that you were in chicagoland, and thanks for lunch! ;)