LAN network unable to communicate with remote network on OpenVPN TAP connection



  • I set up pfSense to connect to a remote network (192.168.122.0/24) that only accepts tap connections.

    The connection is being initiated successfully, but LAN network is unable to communicate with the remote LAN

    pfSense (192.168.1.1/24) itself can connect to remote hosts:

        pfsense# traceroute -n 192.168.122.1
        traceroute to 192.168.122.1 (192.168.122.1), 64 hops max, 40 byte packets
         1  192.168.122.1  116.968 ms  54.357 ms  52.655 ms
    
    

    Hosts on the pfSenses' LAN network (e.g. 192.168.1.8/24) fail to connect:

        lan-machine# traceroute -n 192.168.122.1
        traceroute to 192.168.122.1 (192.168.122.1), 30 hops max, 60 byte packets
         1  192.168.1.1  0.283 ms  0.303 ms  0.379 ms
    
    

    Running a ping from LAN to a host fails, but tcpdump on pfSense shows that the packets are correctly forwarded:

        lan-machine# ping 192.168.122.1
        pfsense# tcpdump -vvi ovpnc4
        tcpdump: listening on ovpnc4, link-type EN10MB (Ethernet), capture size 96 bytes
        11:54:06.975866 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
            192.168.1.8 > 192.168.122.1: ICMP echo request, id 23622, seq 106, length 64
    
    

    It appears to me that somehow responses fail to return (?)

    What can I do to have the interface route correctly?
    Is there anything I could do to further debug the issue?

    (Note that LAN net needs to stay 192.168.1.0/24 - I cannot just change both sites to 192.168.122.0/24.)



  • It sounds very similar to the issues I had in https://forum.pfsense.org/index.php?topic=78416.0 so take a look and see if that might help.
    I don't think there is much difference between tun and tap when talking about the routing.



  • @SalSolo:

    It sounds very similar to the issues I had in https://forum.pfsense.org/index.php?topic=78416.0 so take a look and see if that might help.

    Thank you for the hint. I set up NAT as outlined on the site you linked from within that thread (http://www.bodenzord.com/archives/324).

    This way it works. However, this setup requires manual NAT rules to be defined. If there's a way to avoid that, I'd be very curious to know about it.



  • tun/tap are fundamently different. personally i'd allways use tun if you are not bridging. Routing over tap is just causing yourself more trouble then needed.
    tun will almost allways result in better throughput.

    quote from openvpn website:

    Now lets see benefits and drawbacks of TAP vs TUN.

    TAP benefits:

    behaves like a real network adapter (except it is a virtual network adapter)
        can transport any network protocols (IPv4, IPv6, Netalk, IPX, etc, etc)
        Works in layer 2, meaning Ethernet frames are passed over the VPN tunnel
        Can be used in bridges

    TAP drawbacks

    causes much more broadcast overhead on the VPN tunnel
        adds the overhead of Ethernet headers on all packets transported over the VPN tunnel
        scales poorly

    TUN benefits:

    A lower traffic overhead, transports only traffic which is destined for the VPN client
        Transports only layer 3 IP packets

    TUN drawbacks:

    Broadcast traffic is not normally transported
        Can only transport IPv4 (OpenVPN 2.3 adds IPv6)
        Cannot be used in bridges