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

@jknott said in OpenVPN tunnel network overlapping LAN network: @bingo600 If they are in fact using /9 and not /8, then use the other half. Regardless, it's still best to use different addresses. What happens if the ISP decides to go with /8? I have done a lot of networking in business environments. I have learned there are commonly used subnets, which should be avoided to prevent collisions. That includes 10. and 192.168 subnets. So, I put my networks on 172.16 to avoid problems. IMHO that's pure lottery I have been using 172.16.x.x/12 ranges lots of times too. The OP mentioned 10.0.0.0/9 , not me I think i see something similar w. my ExpressVPN aka. they use RFC1918 for link addresses. Here's a "snip" from a DEB10 VM , that is connected via them. vpn-01:~$ sudo route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ...SNIP... 0.0.0.0 10.141.0.35 128.0.0.0 UG 0 0 0 tun0 default 10.xxx.zzz.1 0.0.0.0 UG 0 0 0 ens192 10.141.0.1 10.141.0.35 255.255.255.255 UGH 0 0 0 tun0 10.141.0.35 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 85.www.22.65 10.xxx.zzz.1 255.255.255.255 UGH 0 0 0 ens192 128.0.0.0 10.141.0.35 128.0.0.0 UG 0 0 0 tun0 ...SNIP... vpn-01:~$ IMHO the OP could just as well use the high 10.x.x.x/9 Or take the chance with the existing network, until proven otherwise. Btw: Neat trick with the 0.0.0.0/1

@deon-0 It seems as if the IP forwarding doesn't work. Did you restart the primary endpoint machine after adding it? To investigate do some tcpdump on the primary on the vpn interface and on pfSense, while you try to ping 10.8.0.2.

@spaceboy You can do that on pfSense directly with Diagnostic > Packet Capture. Select the interface the client is connected to and enter its IP and start the capture. Access the remote site, then stop the capture to see the result. You will find all IPs the client had called. However, it would be more reliable to know the host names, because a host name can be resolved to multiple IP, while the client only call one of it on a single access. Since I don't know what your client really tries to access, I'm in the dark here.

@cctl01 I can't say for certain, but I suspect from your description you had a /16 subnet mask, which meant those subnets actually overlapped. With a /16 mask, everything within 10.1.0.0 /16 is one subnet.

@pcooper I have client logs but the forum will not let me post them.

@nerdzilla IMHO you should describe your setup here, in the thread. I'm not going to spend a lot of time watching youtube , in order to understand your setup. /Bingo

@pepito32 said in CYBERGHOST CONFIGURATION: cyberghost Hi, I found this one: https://forum.netgate.com/topic/146717/cyberghost-openvpn-config-files-for-client-get-mangled-by-pfdense-web

You need to add an iroute (VPN > OpenVPN > Client Specific Overrides) when using topology style subnet. Use the client cert name as Common Name and fill the Clients local subnet to IPv4 Remote Network/s -Rico

@marvosa thanks for answering me. The reason why I've deployed a bridged solution is because I am doing a migration of several virtual machine from the siteA to the siteB and I can't change IP address of thoose virtual machine for multiple reasons. I've invastigated more deeply the problem and it appears that the issu comes from the pfsense of the siteB. In fact, when the pfsenseA (18.254) send a ping to the pfsenseB (18.1), the pfsenseB receive the ping request but it doesn't reply to it. And when the pfsenseB (18.1) send a ping to the pfsenseA (18.254), the pfsenseA replies to pings but the pfsenseB doesn't interpret the answer for an unknown reason. So I don't really know what is wrong with the pfsenseB.

@sse450 So the client cannot connect to the server from what I can see here. However, the provided screenshots are not very helpful to investigate this issue. Your client log is puzzling me. Seems you have multiple remote lines for different servers / IPs, but since you've replaced all remote IPs with the same string, I have to assume, it is connecting to the same IP on each attempt. Is the server running? What does Status > OpenVPN show? Is the server listening on WAN address? Can you see something in the server log mentioned the connection attempts?

@holly Apart from the routes within OpenVPN, wich you may have already set, you need a route on the device 192.168.178.52 for 192.168.1.250 pointing to 192.168.178.51 (the RPi).