Looks like that could only happen if there were no certificates on the system at all, which is exceedingly rare. Someone would have to change the GUI to HTTP (dangerous enough as it is) and also delete the default GUI certificate. The code could handle that better, but it's still not something anyone should be hitting. You could make a certificate for now to work around it, either manually or by generating a GUI cert with pfSsh,php playback generateguicert from an SSH or console shell prompt.

@lifespeed My prefix has been the same for almost 5 years. However, this is one reason I mentioned ULA. It won´t change, unless you change it. There's not much to subnet. You just assign a /64 to each interface.

@franco5 said in Dial-in cannot communicate with Site to site: I add the networks local and remote in each configuration setting of Openvpn, On pfSense 2 you have to add "192.168.2.0/24,10.10.10.0/24" to the "Remote Networks" in the server settings. I add push "route 192.168.1.0 255.255.255.0" in Openvpn dial-in client, I add a static route in PFsense to route 192.168.1.0 by 192.168.101.1 These are not needed. On pfSense 2 you have also to add a CSO for the S2S client and state "192.168.2.0/24,10.10.10.0/24" as "Remote Networks" in the settings.

I got it! Right after I posted, I saw the log state that the vpn link did not have an ip address. I looked and the local address was my public ip. I manually set the IPv4 Tunnel Network on my client through the web gui and it worked. I now have a the route and I can ping in both directions. I think it also needs the gateway to be pushed. I'll play around a little more tomorrow just to see the actual reason. I am not sure why it wasn't getting an address without the tunnel network being predefined. I also gave the client vpn an interface. So I'm not sure if that is also required.

@SteveITS said in About Cryptographic Accelerator Support: @mcury openVPN does its own thing, take a look at https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/configure-server-crypto.html#hardware-crypto hmmm, thanks SteveITS. I did some tests right now, disabled Intel QuickAssist (QAT) and enabled AES-NI and BSD Crypto Device (aesni,cryptodev), then rebooted. Kept Intel RDRAND engine -RAND enabled in the OpenVPN client settings, and indeed I can't see any difference in performance and/or resources usage in the Firewall. Since I'm not using QAT, I'll keep it disabled, and will use AES-NI and BSD Crypto Device and Intel RDRAND in OpenVPN, along with IPSEC-MB to help Wireguard. Thanks again SteveITS

@viragomann It works now. I had to add another firewall rule on the LAG side. thanks for your response

@Nicholas-0 Do you have other options in the branch drop-town? Maybe it helps to switch the branch to something else and than back again. There are some threads in this forum with this or similar issues. Try to search the forum, maybe there are solutions.

Currently the connection is working well in both directions. But I don't know the needed change...

@mac1995 Nice hack, but not really a fix Another hack fix is to disable the WAN rule that allows the client to connect to the server. But that's only really effective if the OP has all the servers on his side, and the clients on the remote side.

@jbcortezf The machines will send responses to their default gateway. If this is not pfSense you have to route the home network to pfSense. As a workaround you can add an outbound NAT rule on pfSense for masquerading, if the VPN is for your private purposes. What is a CSO? VPN > OpenVPN > Client Specific Override

Here is what I could grab when I stopped home. Was in a hurry. I can get more detail if you need. Thanks for offering to help. This is really puzzling me. [image: 1702918250059-1.png] [image: 1702918257568-2.png] [image: 1702918260453-3.png] [image: 1702918266389-4.png]

@mrjoli021 SMS, I don't think this is the best option. Check this: FreeRadius on pfSense software for Two Factor Authentication

@viragomann Thanks this did nudge me in the right direction. I ended up creating vlan interfaces and made outbound nat rules. Since the pfsense LAN interfaces were already able to get to the internal VLANs it was simpler approach.

@tuannm1509 said in issue with VPN Tap mode: i can't ping form the VPN Client to Lan Interface of Pfsense Firewall and PC Test Do you mean, you ping from the client itself and use the LAN IP as source, or pinging from any other device on the clients LAN? For other devices on the LAN, you would need to add a static route to them for the remote network and point it to the Windows machine. Additionally on Windows you would need to enable routing and configure its firewall accordingly to pass through the traffic. I don't think, that the bridge do the job without this. It would be a better practice to run the OpenVPN client on the router instead. Anyway you need add a CSO on the OpenVPN server for the client, where you state the client sides LAN network at "Remote Networks". Additionally you need to state it also in the server settings.