Cannot initiate traffic from LAN to OVPN Client [SOLVED]



  • On my network I have a pfSense server running 2.3.3. The pfSense server is the default gateway for the LAN and is also hosting OpenVPN server(s) for remote users. I have several site to site IPSec tunnels. There are 2 WAN gateways in a failover group for continuous outbound Internet access.

    The OpenVPN server is for remote users accessing via Windows clients (road warriors.) Access from the OpenVPN clients to servers on the LAN works great. ssh, http, imap, smtp, dns, you name it. No problems from OpenVPN to LAN.

    The problem I have been struggling with for months is this. I have a custom application that passes data between Windows clients that are all running this program. LAN users can pass data back and forth with each other. OpenVPN users can pass data with each other. OpenVPN users can pass data to LAN users. What I cannot get to work is LAN users initiating traffic to the OpenVPN users.

    Details:
    LAN subnet:  192.168.88.0/24
    LAN interface:  192.168.88.249
    OVPN subnet: 10.42.25.0/24

    TCP Connect 10.42.25.2 –> 10.42.25.3 OK
    TCP Connect 10.42.25.2 --> 192.168.88.64 OK
    PING 10.42.25.2 --> 192.168.88.64 OK

    PING 192.168.88.64 --> 10.42.25.2 OK

    BUT, TCP connection 192.168.88.64 --> 10.42.25.2 times out. Sounds like a firewall rules issue, right? I don't think it is. I can find no evidence in the firewall logs to indicate traffic is blocked.

    Now the strange part.

    When I run a packet trace I find the ICMP traffic is passing directly from LAN to OVPN. However, I discovered TCP traffic on the WAN interface and getting NATted. I discovered this when I found entries in the states table.  (WAN ip address is obfuscated in the below output)

    States entries

    
    LAN     tcp     192.168.88.64:62582 -> 10.42.25.2:15576                             CLOSED:SYN_SENT     2 / 0     104 B / 0 B
    WAN     tcp     66.1.2.3:22469 (192.168.88.64:62582) -> 10.42.25.2:15576            SYN_SENT:CLOSED     2 / 0     104 B / 0 B
    
    

    Packet trace

    
    15:48:55.491069 IP 66.1.2.3.62582 > 10.42.25.2.15576: tcp 0
    15:48:58.490986 IP 66.1.2.3.62582 > 10.42.25.2.15576: tcp 0
    15:49:04.491547 IP 66.1.2.3.62582 > 10.42.25.2.15576: tcp 0
    
    

    My routing table shows that traffic for the 10.42.25.0/24 subnet should route over an openVPN interface:

    
    IPv4 Routes
    Destination	Gateway	Flags	Use	Mtu	Netif	Expire
    10.42.25.0/24	link#38	U	808	1500	ovpns3	
    10.42.25.1	link#38	UHS	0	16384	lo0
    
    

    Why would ICMP traffic seemingly pass directly from LAN to ovpns3 interface but TCP traffic route via the WAN interface? What could I have missed in the setup to pass TCP traffic directly from LAN to OpenVPN?

    Thanks in advance for any advice.


  • Netgate

    Your multi-wan rules are policy routing the traffic you want to go to the OpenVPN tunnel subnet out the WAN interface instead.

    Bypass policy routing for the OpenVPN tunnel subnet on your LAN rules.

    https://doc.pfsense.org/index.php/Bypassing_Policy_Routing



  • @Derelict:

    Your multi-wan rules are policy routing the traffic you want to go to the OpenVPN tunnel subnet out the WAN interface instead.

    Bypass policy routing for the OpenVPN tunnel subnet on your LAN rules.

    https://doc.pfsense.org/index.php/Bypassing_Policy_Routing

    Derelict,

    Thank so much! That page described my situation exactly, and such an easy fix. My application is working great now. I can't thank you enough.

    I'm still a little puzzled by why the ICMP and TCP traffic seemingly were treated differently, but I never argue with success.