@ryu945 Found nothing on a Netgate forum search. Took a few hours but finally found the solution here. Needs a client specific override with the common name and the desired ip/subnet as an "advanced" entry i.e. ifconfig-push 192.168.98.5 255.255.255.248

@pandafy

ok, sorry I'm out can't get the benefit, but that's just me.
of wanna doing something essential on pfS like openVPN with a pretty good webIF outside of pfS
good luck NP

@JKnott , I uninstalled the network printer driver. Then, i manually re-installed the printer using it's static LAN IP. Windows re-used the existing driver and i was able to print locally as if nothing happened.

Then, I tested if i was able to find my printer when connected via OpenVPN and, what do you know?, It worked flawlesly!!!!!! Just as you suggested.

Now I'm able to print from withing the LAN and when connected via OpenVPN.

Also, your comment: "Those require multicast and that doesn't normally pass through a router" made me think, will the SMB share be discoverable if I specify a host override for its server under the DNS resolver settings?

As it turns out, it does!!!!!. Now all my shares and printers are discoverable when connected to the LAN via OpenVPN tunel.

I hope my experience and report can help somebody else having these issues and
thank you so much for pointing me into the right direction.

@viragomann thanks for the clarification.
There you have it, i was indeed overthinking it.

see extract from log
ug 18 12:03:17 openvpn 61300 OpenVPN 2.5.2 amd64-portbld-freebsd12.2 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jun 24 2021
Aug 18 12:03:17 openvpn 61300 library versions: OpenSSL 1.1.1k-freebsd 25 Mar 2021, LZO 2.10
Aug 18 12:03:17 openvpn 61612 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug 18 12:03:17 openvpn 61612 WARNING: experimental option --capath /var/etc/openvpn/server1/ca
Aug 18 12:03:17 openvpn 61612 TUN/TAP device ovpns1 exists previously, keep at program end
Aug 18 12:03:17 openvpn 61612 TUN/TAP device /dev/tun1 opened
Aug 18 12:03:17 openvpn 61612 ioctl(TUNSIFMODE): Device busy (errno=16)
Aug 18 12:03:17 openvpn 61612 /sbin/ifconfig ovpns1 10.0.1.1 10.0.1.2 mtu 1500 netmask 255.255.255.0 up
Aug 18 12:03:17 openvpn 61612 /usr/local/sbin/ovpn-linkup ovpns1 1500 1621 10.0.1.1 255.255.255.0 init
Aug 18 12:03:17 openvpn 61612 UDPv4 link local (bound): [AF_INET]51.75.92.46:1194
Aug 18 12:03:17 openvpn 61612 UDPv4 link remote: [AF_UNSPEC]
Aug 18 12:03:17 openvpn 61612 Initialization Sequence Completed
Aug 18 12:07:06 openvpn 61612 event_wait : Interrupted system call (code=4)
Aug 18 12:07:08 openvpn 61612 /usr/local/sbin/ovpn-linkdown ovpns1 1500 1621 10.0.1.1 255.255.255.0 init
Aug 18 12:07:09 openvpn 61612 SIGTERM[hard,] received, process exiting
Aug 18 12:10:20 openvpn 35855 Options error: --server directive network/netmask combination is invalid
Aug 18 12:10:20 openvpn 35855 Use --help for more information.
Aug 18 13:28:10 openvpn 28137 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
Aug 18 13:28:10 openvpn 28137 Options error: --server directive network/netmask combination is invalid
Aug 18 13:28:10 openvpn 28137 Use --help for more information.
Aug 18 14:18:46 openvpn 80616 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
Aug 18 14:18:46 openvpn 80616 Options error: --server directive network/netmask combination is invalid
Aug 18 14:18:46 openvpn 80616 Use --help for more information.
Aug 18 14:51:33 openvpn 16749 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
Aug 18 14:51:33 openvpn 16749 Options error: --server directive network/netmask combination is invalid
Aug 18 14:51:33 openvpn 16749 Use --help for more information.
Aug 18 14:56:40 openvpn 16513 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
Aug 18 14:56:40 openvpn 16513 Options error: --server directive network/netmask combination is invalid
Aug 18 14:56:40 openvpn 16513 Use --help for more information.
Aug 18 14:57:22 openvpn 33554 DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
Aug 18 14:57:22 openvpn 33554 Options error: --server directive network/netmask combination is invalid
Aug 18 14:57:22 openvpn 33554 Use --help for more information.
Aug 18 14:58:31 openvpn 40653 Options error: --server directive network/netmask combination is invalid
Aug 18 14:58:31 openvpn 40653 Use --help for more information.
Aug 18 15:08:15 openvpn 31653 Options error: --server directive network/netmask combination is invalid
Aug 18 15:08:15 openvpn 31653 Use --help for more information.
Aug 18 15:12:39 openvpn 98194 Options error: --server directive network/netmask combination is invalid
Aug 18 15:12:39 openvpn 98194 Use --help for more information.
Aug 18 15:12:58 openvpn 55110 Options error: --server directive network/netmask combination is invalid
Aug 18 15:12:58 openvpn 55110 Use --help for more information.
Aug 18 15:21:13 openvpn 23712 Options error: --server directive network/netmask combination is invalid
Aug 18 15:21:13 openvpn 23712 Use --help for more information.
Aug 18 15:22:13 openvpn 71847 Options error: --server directive network/netmask combination is invalid
Aug 18 15:22:13 openvpn 71847 Use --help for more information.

@viragomann I guess my question was how can we setup a ddns without exposing the real wan ISP IP. But i dont think that is possible as the vpn profile file will need a remote url that points to your wan ip

@viragomann said in Adding additional route to OpenVPN Client:

So this network is on another location connected to the office network via IPSec?

Yes, correct.

I have figured it out already, basically I just need to add another Phase 2 entry on the IPsec tunnel.
Phase2-Entry.png

So now I can reach the remote site over OpenVPN.

Thanks @viragomann @marvosa

If they are different interfaces and not switch ports - then no there is no way to put them on the same network without bridging them.

But the only reason you need for them to be on the same network is broadcast traffic.. They could be on different networks and still access everything on the other network. Just create any any rules.

Do these devices use some broadcast/multicast discovery or protocol that is required that they are required to be on the same network..

If want to leverage your ports for individual devices - ok... But why do you need to bridge them.. Just use 192.168.1/24 on 1 and 192.168.2/24 on 2.. And use an any any rule - there you go these devices can talk to each other for anything other than broadcast traffic.

Bridge is only going to complex up the config, and more overhead for what? Are you doing something that requires broadcast to work? Then get a switch... Really the only time it makes sense to leverage a bridge is media conversion...

Or I had something that required the devices to be in the same broadcast domain, ie the same L2 network.. But I also wanted to be able to firewall between them for some stuff. In that case you would use a bridge (transparent firewall) and be able to do such a thing. But just wanting to leverage the ports on your pfsense box.. I don't see the point of trying to bridge them?

@viragomann Thank you Sir.
The redirect IPv4 Gateway option in PfSense OPENVPN did the trick.

@bp81

I'm distributing the "Client Export set of files" in a password protected zip file.

/Bingo

@viragomann

Thanks for replying. I created a new CA and generate new client configuration.

@stefan1

I hate to be the one replying to my own topic, but I discovered the problem was the firewall on Client Netgate Box:

65308152-4aa0-434b-98dd-85894a86220d-image.png

The default firewall rule for the LAN assigned ports out-of-the-box is accept Source: LAN net.

When bridging with layer 2, the client will receive an IP from the remote DHCP. The IP assigned to the client will be not known to this interface. I needed to change this to Source: any and now its working.

@kwriley87 said in Open VPN clients unable to connect to IPSec site-to-site resources:

To be clear, if I look at my IPSec tunnels on Site A, there is only 1 Phase 1 tunnel set up, but 2 Phase 2 tunnels (one for Site A LAN to Site B LAN and one for OVPN LAN to Site B LAN):
https://pasteboard.co/KfhG7AH.png

Yes, this is ok. And at B you should have the same, but with inverted networks.

The tunnel might go down if it's idle. You have to initiate traffic to get it up.
If not, check the IPSec log for hints.

@sasa1
When you are running OpenVPN on pfSense itself, you have only to check "Redirect gateway" on the OpenVPN server settings and add an outbound NAT rule to WAN for the VPN tunnel network.
You have to switch the outbound NAT into hybrid mode and save it. Then add a rule:
interface: WAN
source: <OpenVPN tunnel network>

All other options may stay on default values. Save it.

@tman I started seeing the same issues myself, and I also can't find any obvious culprits. I would expect that the connection would attempt to restore itself, but that's not the case. When I remote in to the server side of the VPN, the OpenVPN daemon isn't running, which leads me to believe it crashed somehow, but I'm not seeing anything obvious in the logs. Does this match your findings, and did you find a solution for this?