[solved] Can't reach OpenVPN Clients from LAN

  • Hi there!

    My setup are two physical interfaces (LAN and WAN), a bunch of VLAN interfaces and three OpenVPN interfaces with different firewall rules.
    The OpenVPN instances are assigned to unconfigured interfaces to apply different rules (at the moment it's just "allow all") to them. The OpenVPN rule is empty.
    I can access all the zones in the network from the VPN according to the firewall rules.

    Basically everything is working as expected, except for one strange thing:
    I can not ping VLAN-Clients from certain interfaces.

    For example, there is a VLAN "SERVER", a VLAN "CLIENTS" and an OpenVPN interface "VPN".
    For now, both are configured exactly the same and at the moment both have an "Allow anything IPv4" rule. The only difference I can see is the VLAN tag, which is 101 for servers and 103 for clients.

    When I got to "Diagnostics->Ping" and select "SERVER net" for the source adress, I can ping a device in "VPN" no problem.
    When I do the same, but select "CLIENTS net" for the source adress, I can NOT ping the very same device.

    Same thing with PCs connected to the interfaces. PCs in the SERVER net can ping VPN-CLIENTS, PCs in the CLIENTS net can not.
    The other way around, from VPN to CLIENTS everything works as expected.

    If I check "Inter-client communication" in the OpenVPN-Server-config, VPN can ping each other, but it solves nothing else.

    So what am I missing here.
    To me the CLIENTS and SERVER interfaces look exactly the same.

    What would be the option, that prevents an interface to communicate with the VPN, altough the VPN can communicate with the interface as expected?

    Same thing goes for other interfaces. 4 can ping VPN, 10 can not.

    I really hope this is a very obvious issue and I am just too blind to see it right now.
    Please help!

    Thank you!

  • Maybe you're missing routes on the vpn clients.
    Post the routing table of an affected client.
    Post your network ranges.

    Another reason for this could be to have overlapping networks on local and on client site.

  • You Sir, are a genious!

    Of course, I can only ping from networks, the OpenVPN-Client knows a route to (which they did not).

    The "problem" is was, that I want to have access to the clients from networks that are forbidden for the clients to access themselves.
    My "workaround" now is, that I push a route to the entire X.Y.0.0/16 network to the clients, so they always route X.Y.A.B Packets back through the OpenVPN Client.

    Now my only security barrier is the firewall rules… then again, a malicious client could add a route to X.Y.0.0/16 themselves, so not much is lost.

    Do you think this is good practice, or am I maybe missing something again?

  • The only drawback of this could be that you possibly override other routes on the client with that. E.g. the routes of a second vpn on the client.

    Another workaround for such routing problems is the set an SNAT rule for that traffic, translating source addresses in packets destined to vpn clients to the vpn interface address (servers IP). Here you have the disadvantage that it's not possible on the destination device to determine the origin IP of incoming packets.
    In pfSense that's in Firewall > NAT > outbound.
    The outbound NAT has to be set in hybrid or manual mode at first. Then add a rule:
    Interface: <the respective="" openvpn="" interface="">source: <the vlan="" "clients"="" or="" an="" alias="" for="" multiple="" networks="">destination: any
    translation address: interface address

    Yes, restrictive firewall rules are the only real security barrier, anyway.</the></the>

  • The only drawback of this could be that you possibly override other routes on the client with that.

    Yes, that happened ;D so I had to refine the pushed routes a bit.
    Now it seems that things are working as intended.

    I will ponder a bit about NATing the traffic and if it might improve things, but the origin problem is solved.

    Thank you very much for helping!

Log in to reply