Have you set a firewall rule on pfSense at OpenVPN interface to allow the access to the other site?

Ensure that software firewalls (Windows) at the destination hosts do not block the access.

no, the tunnel keeps running fine. that's the weird thing.
if I ping or ssh from pfSense it has no problems. But from "Local LAN" it works the 3rd try.  ???

I took a look at their ovpn files and it doesn't look like there's anything that would make much difference.

The guide should work, just skip steps 10, 11 and 12 and enter the username and password in the pfSense gui.

If it still doesn't work, you'll have to post your log.

your route command doesn't look right off the top of my head..

route add -net 172.16.10.0/24 172.16.1.1

Would be proper syntax

I add vpn subnet to local network in asterisk and everything work ! thanks

@jimp Thanks, that worked for me.

Wound up resetting to default, reinstalled everything as it was, everything worked. No clue what caused the issue. Did not install squid this time however.

regarding point 2, i found the solution in one of the blogs. the following option needs to be selected (Checked)

System -> Advanced -> Firewall and NAT -> Bypass firewall rules for traffic on the same interface.

any hints for point 1?

thank you

Ok, I didnt give up…. yet :) I read that Synology NAS cant do site to site but I guess that goes for being server.

I changed port number on NAS config to connect to correct server, so from existing RA to PtP.
Using existing config file exported from pfS with inline cert/key/tls
Authentication failing.
PtP server generated new tls key, I hit my head, I should know...

Copy key over but then the server log spits:
" TLS Auth Error: --client-config-dir authentication failed for common name 'NAS' file='/var/etc/openvpn-csc/server2/NAS' "

" '/var/etc/openvpn-csc/server2/NAS' " here my mistake.

So now I know this way it`s not working :) Have to export NAS and not use the existing one.

Me trying to take shortcuts but eventually it takes longer :)

Thanks for the succinct answer!

"I wouldn't trust the hardware if it's that old, though."

Exactly which is why I would get new hard, do a nice clean install - put in your config, swap them this provides for very short down time.  How ever long it takes to you swap the cables really.  And if something not working because you missed a config, etc.  Then you could swap the cables back.

To me this is the safest approach since swapping disks maybe something else fails on the ancient hardware on a reboot.  Shit does that old of hardware even support sata as a disk connection..  You mention soekris, what model number - prob has some soldered CF so can not even swap that.. I would prob go with their net6501-70 if customer wants to stay with same namebrand, etc.

But for that price point why not just go with pfsense sg-4860 or Netgate RCC-VE 4860, etc..  Sure that would huge improvement to some soekris system from 9 years ago ;)

I found it! For some reason, I had a 1:1 NAT entry pointing the 1st IP of my external address block to the internal IP address of the pfsense box. This kills it of course.

Glad to help you! I don't think you need to change anything.

These are P2P connections and I have the network specified in the remote networks of the main firewall. Also the route appears in both the main firewall and my remote client firewall. I can also try adding push route to the advanced options and will get the same result.

Tried a reboot, but no change…

From the pfsense:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpns5, link-type NULL (BSD loopback), capture size 65535 bytes
22:06:25.727660 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 7, length 64
22:06:26.727671 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 8, length 64
22:06:27.727676 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 9, length 64
22:06:28.727686 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 10, length 64
22:06:32.620809 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 1, length 64
22:06:32.920929 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 1, length 64
22:06:33.621049 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 2, length 64
22:06:33.921304 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 2, length 64

And from the remote end Linux host:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
17:36:32.798639 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 1, length 64
17:36:32.798655 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 1, length 64
17:36:33.799001 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 2, length 64
17:36:33.799024 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 2, length 64

It only sees the traffic to the tunnel ip, not any of the traffic destined for hosts beyond

Well I have a more fundamental issue.. my provider has different TLS keys for every server and so I'm trying to figure out how to have multiple remote statements with different TLS keys.

I found that as of a recent OpenVPN version, there's a notion of connection profiles, specified using <connection>tags in which you can have targeted parameters, but unfortunately they are specific ones, so I've opened a feature request with OpenVPN to allow the tls-auth and ideally cert directives to be included so you can have per-server settings.

I need this to be able to have my client try different servers within the same country when one goes down.

For my direct question, I've found a workaround where I can just specify an external openvpn config file with the inline configuration and it works.</connection>