Found it. Either this thread can be deleted or we can see if others would see the error. Hint: I would have had assumed that with this error, nothing would have had worked, but instead it did - even with mediocre speed ;-)

No idea what directory you are talking about, can you specify the question? -Rico

@webstaff Google foo.. Just pop this in Server custom options. push "route 0.0.0.0 0.0.0.0" https://forums.openvpn.net/viewtopic.php?t=27321 Seems to do the job.. If anyone wants to give me some Karma so I can post without getting hit as a spammer that would be great. Regards Dave

@meaglerick I think, that is the wrong place to ask this. Possibly you have luck in the OpenVPN community forum. We are just following here the guides provided by Netgate: https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-psk.html https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html

Solved : I change the IPV4 Tunnel Network CIDR to 172.16.40.0/24 and everything is working again.

@viragomann Okay the Firewall logs only include people sniffing at some Ports. Idk The pfSenseA is the default gateway on the server. The Gateway of pfSenseA is WAN, and the tunnel is established over WAN. (there is another router in front of the pfSenseA could this lead to problems? I thought the packets are routet through the established site to site connection)

@dabbelju007 said in Adding OpenVPN Interface in Interface Assignments: Traffic from my OpenVPN network is hitting the "OpenVPNOPT" interface, not as I would expect the OPENVPN. Without knowing your firewall rules I cannot estimate. However, it behaves like stated in the link. The OpenVPN is an interface group is mentioned. For testing you can add a block any protocol, source, destionation rule to the top of the OpenVPN tab. Consider to flush the states on that interface before trying to access something.

Just tried making heads or tails of out that thread.. Makes zero sense to me.. If you you need a downstream router (doing vpn or not) - then connect it to pfsense via a transit network.. Has zero to do with trying to create a vpn interface on a vpn client connection.

It's not a bug. Option 1: Update your clients to OpenVPN 2.5.x Option 2: Check the legacy box before exporting

@beui You can do the by a policy routing rule. You have to assign an interface to the OpenVPN instance at A if you didn't that already. Add all your internal destinations or networks the TV need to access or as well possible all RFC 1918 networks to an alias. Then add a pass rule to the interface the TV is connected to, at destination check "invert" and enter the alias, expand the advanced options and go to gateway and select the openVPN gateway from the drop-town. Put this rule to the top of the rule set so that it is applied before checking the others for local traffic.

Unbound ACL's ? Ohh a bit to late ...

@jegr ping

@johnpoz said in Unable setup IPv4 Tunnel Network /30: But from that error, is seems there is some openvpn limitation for /29 being the smallest - maybe something to make sure you can use a net30 setting for sure? This is for any tunnel subnet, f.e. /24: .0 = network .1 = server address .254 = dhcp .255 = broadcast Those four addresses cannot be used for clients. One can confirm this in the server log, f.e. /24: IFCONFIG POOL IPv4: base=10.8.0.2 size=252 The deprecated /30 topology is from the past when Windows could not handle the subnet topology.

@rico said in Site-to-site VPN, can only connect one direction to appliance: Your IPSec Local Network overlaps 192.168.97.0/24 and 192.168.33.0/24 I'm not really into IPsec, but pretty sure it could grab that OpenVPN traffic. TBH, I lose track a bit about your whole setup, it is not easy to follow which site is which Configuration, Rules or even local/remote networks. It could help to sketch up your network layout. -Rico Thanks for all your help, but it actually looks like everything was correct in terms of settings, I just needed to reboot the appliance and it worked. I didn't realize rebooting would help here

@gertjan , thanks for answering. The problem was the antivirus firewall Kaspersky.

@bambos You can either use the certificates common name (CN) or the user name, but not both! And you have to tell the server, what should be used by checking the Username as Common Name option or not in the server advanced configuration.

@bbrendon Thank you. Happy New Year.

@gertjan and @all Thank you very much for your time and comments! Indeed the port forwarding on my ISP router was not configured correctly. That being corrected everything is now working as expected I wish you a great start into the new year!!