• Hello! I've kinda asked this question in the past, but I thought I'd start fresh and offer a more-visual explanation of what's going on.

    I'm looking for a way for machines inside my LAN to talk to machines connected via OpenVPN.

    I know pfSense doesn't support Bridging OpenVPN anymore for whatever reason and forces you to be Routed. This, in and of itself, isn't a big issue.

    Back when I used eBox, it forced Routed, but I was at least able to contact machines on the VPN from inside the LAN. eBox had a checkbox which allowed you to enable or disable NAT in case your eBox was a regular LAN machine instead of the WAN-facing machine.

    From what I've seen, while pfSense does allow 1:1 NAT, when using OpenVPN, this doesn't work properly. I am also going to assume the NAT'd OpenVPN is also not Masq'd. This would explain why you cannot receive replies to pings or pings if you're connected via VPN.

    To note, OpenVPN clients can access LAN machine services like RDP and Samba so I'd like to know why ping responses aren't working and why those clients cannot be accessed by LAN machines over VPN.

    I made up some numbers there to represent something similar to my setup to explain how it's working in detail.

    OpenVPN		10.0.0.0/24 @ 10.0.0.1
    LAN		10.1.0.0/16 @ 10.1.1.1
    
    <->	Ping & Pong
    <-	Ping no Pong
     <x>No Ping or Pong
    
    OpenVPN @ 10.0.0.18
    	10.0.0.18	<->
    	10.0.0.1	<->
    	10.1.1.1	<->
    	10.1.1.4	<-
    
    LAN @ 10.1.1.5
    	10.0.0.18	 <x>10.0.0.1	<->
    	10.1.1.1	<->
    	10.1.1.4	<->
    
    pfSense @ 10.1.1.1 & 10.0.0.1
    	10.0.0.18	 <x>10.0.0.1	<->
    	10.1.1.1	<->
    	10.1.1.4	<-></x></x></x>
    

    It's not just ping that's not working, I'm just using that in the example.

    I have not tested OpenVPN machines pinging each other recently so I don't remember how it functions. Sorry about the lack of that piece of data, but I do have "allow communication between clients connected to this server" enabled.

    I've also tried doing this with the "provide a virtual adapter IP address to clients (see Tunnel Network)" checkbox both checked and unchecked. In fact, I've noticed no difference either way.

    Strangely, the subnet of my OpenVPN clients should be /24, but it's showing up as /30 in Windows when I go to the VPN tap interface's details.


  • You can bridge OpenVPN, there is a package with some fixes for 2.0. But bridging VPNs is generally the wrong thing to do.

    @Saturn2888:

    To note, OpenVPN clients can access LAN machine services like RDP and Samba so I'd like to know why ping responses aren't working and why those clients cannot be accessed by LAN machines over VPN.

    Is it safe to summarize VPN clients to LAN all works fine, but vice versa does not? Are you doing outbound NAT to fix return routing?

    @Saturn2888:

    Strangely, the subnet of my OpenVPN clients should be /24, but it's showing up as /30 in Windows when I go to the VPN tap interface's details.

    That's how OpenVPN works. The /24 is just the pool it assigns from, each client has a /30.


  • Weird. I didn't know that it assigns the /24s because it never used to. Well either way, last night I setup bridging and while OpenVPN's process died quite a few times on its own, it seems to be working perfectly today.

    Thanks!


  • Ok yeah, after some client disconnects, the process dies, and you can't connect again. I don't know why that's happening.

    Also, I'm assuming this might be getting fixed, but if DHCP leases for OpenVPN clients don't show up in the management console.