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

zoomer

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.)

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.
I don't think there is much difference between tun and tap when talking about the routing.

zoomer

@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.

heper

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