TAP (OpenVPN) Traffic Blocked



  • Hi,

    Unfortunately this used to work, but is not working now in v2.2.2 (or other recent versions, not quite sure … but it did work in v2.2) ... :(

    I have an OpenVPN server - I connect to it remotely, and that all works ... but I cannot get from the remote (client) machines to pfSense itself. From the logs and tcpdump, it seems like traffic can get from the client (TAP) to pfSense (due to a Rule I created to pass incoming TAP traffic), but I can't get back to the client (over OpenVPN). I have tried all sort of rules ... allow all LAN traffic, floating rule between LAN, TAP and OpenVPN - but none seem to work.

    Is this working for anyone else?

    Thanks!



  • Hi,

    OK, a bit more digging - and other than DHCP packets, nothing seems to be getting to pfSense (over OpenVPN). For now I have had to disable the OpenVPN server, as it's "dead" when I connect to it … :(.

    Thoughts?

    Thanks!



  • Whenever you connect to OpenVPN, can you post a screenshot of status -> OpenVPN.  Expand the routing tables and let us see what is happening.  This will help us see if it is at least hitting the network.

    Edit:  Lets also see a screenshot of OpenVPN log from status -> System Logs -> OpenVPN.  Lets also see those firewall rules



  • Hi,

    More than happy to, but a few issues … :(. Here we go ... ;)

    1. I re-enabled OpenVPN -> it killed PHP-FPM. This seems to happen a lot (have reported it). Restarted PHP-FPM.
    2. I then connected to OpenVPN, but as in my other post (https://forum.pfsense.org/index.php?topic=87193.msg516591#msg516591), the status screen shows no connections (OpenVPN-status.jpg), and the main screen shows OpenVPN down (load balancer, Main-status.jpg). When I disconnect my client -> status goes back to green. But also, I can't show the route table from the OpenVPN status tab, as it shows no connections. But I am connected!
    3. System Log is also attached (SystemLog.jpg).
    4. I have also added Diagnostics > Routes (Routes.jpg)

    Thoughts?

    Thanks!










  • You really don't want to use TCP there, UDP always best. Not related to the issue but best to change that.

    How is your bridge configured? Did you add one?



  • Hi,

    Sorry for the slow reply - out of town with my daughter for her sports. Back in town again … ;)

    Yes, I did add a Bridge, between LAN and TAP ... does that sound right?

    Thanks!



  • That's correct for the bridge.

    Just noticed something in your logs from an earlier post, it looks like you have a client running on the same system as the server, connecting to that server? The log line "TCP connection established with … 192.168.2.1:47209" indicates something on that same box is connecting to that OpenVPN instance.



  • Hi,

    Yep, that makes sense - did try to test the connection from the local subnet, just to see if I was responding. Debugging this remotely is "fun" … as you can't see anything if you can't get a connection ... :(. But the normal connection is from remote.

    Thanks!



  • If you tried it from the local subnet, it shouldn't have been coming from that host's own IP. That was actually from a different host on your LAN?

    How are your net.link.bridge.pfil_bridge and net.link.bridge.pfil_member tunables set under System>Advanced, System Tunables?



  • Yep, different machine on the LAN - just trying to see if the port was open / working. The problem is - when connecting remotely, and it won't pass traffic … difficult to debug ... :(.

    I didn't touch system tunables ... here is what those are,

    net.link.bridge.pfil_member Set to 0 to disable filtering on the incoming and outgoing member interfaces. default (1)
      net.link.bridge.pfil_bridge Set to 1 to enable filtering on the bridge interface default (0)

    Are these values a concern?

    Thanks!



  • And BTW, on the UDP vs. TCP … UDP is not an option for me. Often connecting from behind a proxy on the remote end, and it requires TCP (for the proxy to pass traffic). But that's OK - up until now TCP hasn't caused any grief (and even really now, not sure TCP is the issue here).

    Thanks!


Log in to reply