Yes, on each site pfSense is the main gateway/router. I applied the config and rebooted pfSense on both ends, still no luck. Ping attempt from the branch office: PING 10.1.1.9 (10.1.1.9) from 192.168.1.1: 56 data bytes --- 10.1.1.9 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss This is an attempt to ping one of my servers (10.1.1.9) from the LAN interface at the branch office. Here is some more interesting behavior: I can ping the main office LAN gw (10.1.1.1) from the branch office on the VPN interface: PING 10.1.1.1 (10.1.1.1) from 10.0.0.109: 56 data bytes 64 bytes from 10.1.1.1: icmp_seq=0 ttl=64 time=51.527 ms 64 bytes from 10.1.1.1: icmp_seq=1 ttl=64 time=84.772 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=64 time=27.185 ms --- 10.1.1.1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 27.185/54.495/84.772/23.603 ms But I cannot ping servers from the VPN interface at the branch office: PING 10.1.1.9 (10.1.1.9) from 10.0.0.109: 56 data bytes --- 10.1.1.9 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss I cannot ping the main office LAN gw from the branch office LAN PING 10.1.1.1 (10.1.1.1) from 192.168.1.1: 56 data bytes --- 10.1.1.1 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss Routes at the branch office: 10.0.0.0/24 gw 10.0.0.1 10.1.0.0/16 gw 10.0.0.1 10.196.54.128/26 gw 10.0.0.1 Routes at the main office 10.0.0.0/24 gw 10.0.0.2 192.168.1.0/24 gw 10.0.0.2

It’s complicated. I tried to replicate the problem and succeeded two times, only to see that when I replay the actions after a full reinstall without restore, the problem disappeared. My impression is that the problem occurs when one replaces a VPN provider that uses TLS (NordVPN), add a new provider that doesn’t use TLS and then replace the client in the interfaces. When I deleted the interfaces first, save and then recreated the interfaces I never had troubles. I’ve spend more than 12 hours now on trying to create a decent and easy to replicate big report but it is complicated. I’ll have  more time in a couple of weeks and I will do a follow up then.

You are joking, right? When you say: @SirBisgaard: my OpenVPN server is working then I expect you tested that already. How? With an OpenVPN client on your laptop? Use that (Tunnelblick as OpenVPN client) when you are in school. Or ask your IT teacher to help you solve this … if you are not the teacher, that is.  :-) And may I suggest some reading here: https://forum.pfsense.org/index.php?topic=20236.0 BTW: what did you already do/test and what's not working?

Hello, have you manage to fix this? I have exact same issue. Cheers!

Sorry for BUMP topic. But i need help about gaming over OpenVPN. I have several clients which should join into VPN network to play games. All works fine while game supports direct IP like Arma 2, but when we want to join in another game which uses broadcast like Borderlands 2 - no joy. Does anyone know any tutorial how to create VPN with pfSense so settings are actually allowing broadcasting so we can see ones another game. Im pretty sure this is common problem and hope someone will help me. Many thnx in advance.

I fired up wireshark and ran openvpn alongside it on a pc on my LAN. Not sure if I'm looking for anything in particular but I see a 54 byte packet go from the client to the server. This is pretty much the same thing that I see with a cellular client. That's the end of the similarities. The pc and router send several packets back and forth and then the OpenVPN client says "connected" The second to last line in the openVPN client is interesting: Wed Oct 25 22:45:56 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=1 Wed Oct 25 22:45:56 2017 add_route_ipv6(fdf7:a829:80e5:45a9::/64 -> fdf7:a829:80e5:45a9::1000 metric 0) dev Ethernet 3 Wed Oct 25 22:46:01 2017 ROUTE: route addition failed using service: The parameter is incorrect.  [status=87 if_index=14] Wed Oct 25 22:46:01 2017 Initialization Sequence Completed Not sure if that could have any relation to the OpenVPN Server errors that occur while trying to connect over cellular. Though I checked the OpenVPN server logs with my successful LAN PC connection and everything looks perfectly happy. I ran another packet capture on pfSense while testing my cellular client (my original capture used promiscuous mode). I was able to see the packet come in on the WAN (without using promiscuous mode). I then tested again capturing LAN traffic and didn't see the client IP (which I shouldn't as the connection happens within the router). Lastly, I tested again capturing OpenVPN Server traffic and didn't see a single line in the output. Totally empty. So the traffic seems to make it to the router and from what I can tell it doesn't seem to be getting blocked, but it also isn't finding it's way to the OpenVPN Server either. Edit: Apparently I don't get any logs during packet capture on the OpenVPN Server interface…I did a capture while connecting from a LAN client, successfully connected, and didn't get anything logged in the packet capture. I find it weird that the OpenVPN Server does have logs when I try to connect over cellular, granted they are error messages, but it is at least getting "something" from the client. Any ideas? Do you think I would have better luck in the firewalling subforum? Thanks Edit2: Ran some more packet captures on LAN and WAN interfaces and verified what I think was already said. When establishing the VPN connection from a LAN based client, no client traffic crosses the WAN interface to establish the VPN connection. All of the VPN traffic occurs on the LAN interface.

Set up your OpenVPN server to listen on port 443 and connect via TCP. I've noticed a lot of free wifi hotspots block port 1194 and UDP connections on 443 (probably by way of only allowing DNS-53-TCP/UDP, HTTP-TCP, and HTTPS-443)

take a look here https://helpdesk.privateinternetaccess.com/hc/en-us/articles/225274288-Which-encryption-auth-settings-should-I-use-for-ports-on-your-gateways-

I've looked into the meaning of this header and as far as I can tell, the 02 00 00 00 header is used by BSD on the loopback interface in order to indicate the type of package transmitted. 02 00 00 00 indicates an IPv4 package. However, when directly piping onto the virtual interface used for OpenVPN, the family seems get changed. Looking at the Wireshark dump of my OpenVPN tunnel, I can see the four header bytes, you are talking about.  However, I do not know, why the manual redirection of packages should cause a change. The only thing I could find, is the following from http://www.tcpdump.org/linktypes.html BSD loopback encapsulation; the link layer header is a 4-byte field, in host byte order, containing a value of 2 for IPv4 packets, a value of either 24, 28, or 30 for IPv6 packets, a value of 7 for OSI packets, or a value of 23 for IPX packets. All of the IPv6 values correspond to IPv6 packets; code reading files should check for all of them. Note that host byte order'' is the byte order of the machine on which the packets are captured; if a live capture is being done, host byte order'' is the byte order of the machine capturing the packets, but if a ``savefile'' is being read, the byte order is not necessarily that of the machine reading the capture file. Maybe, this gives you a starting point.

I'm also new to pfsense and openvpn and did everything with the help of this topic. https://forum.pfsense.org/index.php?topic=93432.0

@viragomann: Presumably you are using TLS authentication and connect from both devices using the same user cert, so go to the server settings and check "Duplicate Connection" in the "Tunnel Settings" section. Thank you! This is what I was looking for.

I guess they could make the button colors red for xp, yellow for win6 and green for Vista or later…  For us slow non-readers!  haha

FYI, it appears that NordVPN has addressed whatever issue was causing random ping timeouts after TLS renegotiation. I haven't seen it happen in the past two weeks, which is by far the longest stretch ever.

dpinger works fine. You are seeing an OpenVPN issue. You have to monitor something that will actually respond to pings. The gateway address is automatically inserted. There is no mechanism to "automatically" choose something else. You can place whatever monitor IP address in there you think is better than the gateway address. This has nothing to do with dpinger.

@HeMaN: I have some issues with openvpn clients on the firewall itself as well after upgrading to 2.4 The configuration I have is based on the 2.3 version of this guide (he has it now updated to 2.4): https://nguvu.org/pfsense/pfsense-multi-vpn-wan/ I use two client connections to AirVPN combined in a Gatewaygroup, and it was wording fine on 2.3 In 2.4 I can see the connection with AirVPN is setup ok, but it seems the creation of the interface is giving issues: /sbin/ifconfig ovpnc1 10.4.94.253 10.4.0.1 mtu 1500 netmask 255.255.0.0 up ifconfig: ioctl (SIOCAIFADDR): File exists "Solved" it for this moment by disabling one of the clients, then it seems to work agin for that one client. I found the solution for my problem :) In the 2.3 version of the guide I mentioned there was a monitor IP configured for each VPN GW. Comparing them with the 2.4 version of the guide he published now, there was no GW monitor IP. After removing them both stay active. It is either this or the fact I updated pfblockerng to the latest version because of the infamous 502 bad gateway issue, which I changed first before I changed the VPN GW configuration.

Thanks Room 7609! Tried it but alas same result :( Good idear though, I did say that mentioned a few times… Will keep you posted. CP