Local resources not reachable via tcp
-
Hi,
I've been struggling for days on the following problem:
I am relatively new to pfsense: I just started out by adding a VM with pfsense 2.6.0-RELEASE to a network that was already fully set up.
In other words there is a second active router (main router) that handles the main network traffic.
That router of course is the default gateway for all machines in the LAN.I have setup OpenVPN following the instructions on
https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-ra.html
using the OpenVPN Wizard.As far as I can tell OpenVPN is working and my clients can connect via OpenVPN.
I see the connected clients on the OpenVPN Status page.After adding a static route for the VPN in the main router I am also able to ping from
VPN-Clients to any machine in the LAN and also from local machines back to the VPN-clients,
what means that ICMP works bothways.The VPN-Clients can also access the pfsense-webconfig.
Unfortunately any other access to local resources - (supposedly based on tcp) does not work.
So I think it must be a routing issue with pfsense or some blocking firewall rule.
In the "Packet Cature" of pfsense I see the connection request from VPN-Clients
but no response.I checked the rules created by the OpenVPN-Wizard but could not spot any suspicious setup.
I also already tried out several hints I have found on the Internet, like adding specific Destination to the OpenVPN rule instead of 'any' or setting up a Outbound-NAT (as a workaround).
None of them seem to work.I am really lost now and would appreciate any hint or guiding directions.
Thanks,
Manfred. -
@mweiler said in Local resources not reachable via tcp:
In other words there is a second active router (main router) that handles the main network traffic.
That router of course is the default gateway for all machines in the LAN.After adding a static route for the VPN in the main router I am also able to ping from
VPN-Clients to any machine in the LAN and also from local machines back to the VPN-clients,
what means that ICMP works bothways.The VPN-Clients can also access the pfsense-webconfig.
Unfortunately any other access to local resources - (supposedly based on tcp) does not work.
So I think it must be a routing issue with pfsense or some blocking firewall rule.Yeah, such setup typically ends up in asymmetric routing issues and what you see now, is exactly this.
If you run the VPN endpoint not on the default router, you either have to
- remove the VPN endpoint from the local network and put it into a transit network, which is connected to the primary router. Then you have to add static routes on the primary to point the VPN tunnel network to it and also one on the VPN gateway to route the local networks.
- add a static route on each of the local devices you want to access from a VPN cleint.
- enable masquerading (outbound NAT) on pfSense on traffic from VPN clients to the local networks.
-
hm ... somehow I was afraid of such a 'what-you-do-is-stupid'-answer, at least it helps from wasting time on following that track.
I am wondering, how this situation is different from a setup where no router but a dedicated computer (server, raspi, ...) is running the openvpn server?
That machine would also typically be part of the LAN.
Well static routes would definitely be required in this case because the LAN-machines otherwise do not know about the VPN-Route.
Would I also need maquerading in this case?In other words why / in what way is this different to hosting the openvpn server on pfsense?
-
@mweiler said in Local resources not reachable via tcp:
I am wondering, how this situation is different from a setup where no router but a dedicated computer (server, raspi, ...) is running the openvpn server?
And you mean, you can access all LAN devices across this VPN?
So I'd assume, the VPN server does masquerading.You only need to configure one of the options, I mentioned above.
The first one is the most reliable and professional solution. Masquerading is the easiest to do.
The drawback of this is that your devices see the packets coming from pfSense itself, but not the real origin client IP. If the VPN is meant to get access to your local network for your own purposes, this might be sufficient. -
@viragomann said in Local resources not reachable via tcp:
add a static route on each of the local devices you want to access from a VPN cleint.
So you are saying that this should work, even with my setup of two routers in the same LAN?
I had already tried that, but somehow failed.
And doesn't the fact that 'ping' works already prove that the clients know the routes?
-
@mweiler said in Local resources not reachable via tcp:
add a static route on each of the local devices you want to access from a VPN cleint.
So you are saying that this should work, even with my setup of two routers in the same LAN?
Yes, this should work.
You need a static route for the VPN tunnel network and point it to the LAN IP of pfSense.I had already tried that, but somehow failed.
Also consider to allow the access on the destination device itself. Its firewall might block the access by default, because its from outside of the local subnet.
Masquerading would circumvent this.
And doesn't the fact that 'ping' works already prove that the clients know the routes?
No, as I mentioned in my first post, you actually have an asymmetric routing.
Request packets from VPN client go from pfSense directly to the destinations device, but response packets are sent to the router. If the router is statefull, he might drop the packets, because he never saw the belonging request packet.
Ping (ICMP) is stateless, hence this doesn't matter.However, why won't you set up a transit network? If your primary router is capable to handle multiple local subnets or VLANs, this would be the preferred option for me.