(L'adresse 20.0.0.1 n'est pas privée : ce n'est pas recommandé !)

Je ne comprends pas que vous ayez utilisé le MEME réseau pour le VPN site-à-site et le VPN roadwarrior ! Ce réglage ne peut que perturber le pfSense !

Il faut

configurer des réseaux différents pour le client OpenVPN et le serveur OpenVPN, en sus, pour les clients roadwarrior, il faudra ajouter une route (push route) pour qu'il atteigne le site Bureau.

@johnnyfive Yeah this is the problem - what a shame. It would be really great to have full acceleration using QuickAssist!

Somebody please?

@mainzelman Thanks for the reply.

Site B IPSec firewall rules were empty (I assumed this to be ok because Site A and Site B hosts can talk no problems)

I added the rule for Site B and it appears to be now working!
dd6e54f6-fa74-4b38-bf03-a8b3e6c04ec9-image.png

I knew it had to be something simple I missed, thank you!

Do you see it being routed in packet captures or the state table when you try to reach 1.1.1.1?

Where does it fail?

@viragomann thank you for the suggestion, I am gonna give it a try, we should fix the issue by having the remote endpoint add a phase 2 for the openvpn subnet but in the meantime this should fix it as well.

Thank you very much! Your solution fixed my problem! I missed to add the tunnel network to the remote networks on site B.

IMO it's impossible to tell active directory domain member to not look for dns record of domain name.

Hey there,
I think the problem is not within the Router but in the testserver.

Even though I did a reinstall recently and never installed anything else than apache2 and openssh-server, a tcpdump confirmed that the packets arrive at my testserver but my testserver does not respond to them for whatever reason. So most probably my fault.

Anyway

Thank you @Rico !

Ce n'est pas agréable de répondre et de se voir attribuer une attitude qui n'est pas la sienne ... C'est donc mieux.

Le VPN_ADMIN est le VPN roadwarrior (qui est très bien avec OpenVPN).
La config que vous indiquez me semble correcte cette fois ci.
Elle est logique puisque le Local est l'ensemble des réseaux de chaque site !
Usuellement, et la doc pfSense l'utilise, le Tunnel est 10.0.x.0/24 (ce qui permet à 63 clients de se connecter).
Si on a plusieurs sites, avec chacun un serveur OpenVPN, on fait varier le x : 8,9,10, ...

Le VPN_SITES devrait passer à IPsec et idéalement en maillé.
Donc chaque site doit avoir des définitions suivantes
pour le site 1 :
phase1 : vers site 2 / phase 2 : lan1 <-> lan2 / 2 rules ipsec : lan1 -> lan2 + lan2 -> lan1
idem pour site 3
idem pour site 4
et on recommence site par site

So your on-prem Webserver is also running as OpenVPN client which is connected to your gcloud pfSense? You are only running this one pfSense? What is your OpenVPN mode?

-Rico

@azmodeuz said in OpenVPN SSL Site to Site - I am unable to push DNS to Site B and access a routed network in Site A from Site B:

I set pfSense3 as OpenVPN Server so remote users are connected locally to communicate with our Local Net. Would this still be possible if I use pfSense2 as the OpenVPN Server?

You will need a static route on pfSense3 for the OpenVPN tunnel network 192.168.121.0/24 pointing to pfSense2.

@azmodeuz said in OpenVPN SSL Site to Site - I am unable to push DNS to Site B and access a routed network in Site A from Site B:

Re: NAT, how should I do NAT to get responses back to pfSense3?

You can add an outbound NAT rule on pfSense3 (S-NAT, also known as masquerading) which translates the source IP in packets from the remote site of the VPN into the DMZ interface address. So responses are sent back to pfSense3.
However, that's a dirty solution and is not recommended if there are multiple clients connecting through the VPN.

Hi,

View /etc/inc/openvpn.inc.

Locate the several function calls and definition at the bottom of the function called : openvpn_add_keyfile

This function takes the directory, the extension, the PEM based64 encoded data and writes out the file.
File rights are set to 0600 and that's it.
It's line 760 in the openvpn.inc file.

If something goes wrong at that place, I guess the $data that gets base64 decodes isn't 'ok' ?
Is your cert ok ?
Many cert type files are created using that function. When only "server1.cert" goes wrong, I gues it's input (= $data) is 'wrong'.

An old 2.4.4-p3 bug that got resolved (?) ^^
edit : non. openvpn server was working just for for my when I was using 2.4.4-p3.

OK, I see the logic. Thanks.

Actually what happens is that I have packed drops/high latency when transfers over VPN are getting very slow, not fast. Then VPN server can easily reach half of the speed of my download DSL link (i.e 300Mbit/2=150Mbit) and then everything is OK. There are no issues when VPN is not used at all either. Problem is when the remote end behind VPN (=torrent sources) isn't that fast and download speed drops to say 10Mbit. Then torrent transfers are causing high latency/high packet drop on my link.
This is very similar case to this one (unresolved issue): https://forum.netgate.com/topic/125639/lots-of-packet-loss-and-high-ping-when-torrenting-through-pia-vpn
But it's not PIA VPN that I'm using (it's NordVPN).

What is surprising to me that, as said before, I had no such issues when Asus RT-AC68U was my router.

The interface used by the firewall to originate this OpenVPN client connection
so typically this would be WAN.
In my case for some Sites it is not directly WAN but some Gateway Group containing different WANs.
I've never thought about switching it to any internal Interface like LAN or OPT...why did you do that? Just leave it as default.

-Rico

@Rico sadly doesn't seem to solve the issue.

I deployed the OpenVPN on ubuntu behind the firewall and forwarded the port, now I got it working.
I am not sure why it's not working, to be honest, but the fact that it worked for a while and that its very slow without using any resources makes me believe something is unstable there, possibly with how my hosting solution manages VM's.

Anyway thank you for all the help.

@Rico
word! i do not need to unserstand why i would do this ;)
CSO local networks but here in ausrtia a lot of things are possible ;)

Yes the netmasks are all /24. For now it is 1 peer for testing. But in the future i would like to have the possibility to add more clients. The following is what I'm trying to accomplish:

test.png

@Derelict, thanks so much by your answer.

I have saw the information of link and I don't see it clearly. I am not a expert programmer.

I only want show by Console, or via SSH, in text mode, the same information thar appears in the OpenVPN Status GUI page and be able to capture the output text.

Do you know where can I found examples to do something similar to this?

Regards,

Ramsés

Leí todo tu caso y que genial que lo has resuelto.

@Aba

Никогда не использовать сети 192.168.(0|1).x в продакшене. Меняйте адресацию на 10.10.10.0, например. Это первое, что говорит об "уровне" админа.

Не пользовать DNS Forwarder на пф. Разрабы по умолчанию его откл., задействовав DNS Resolver. Но нет, все еще есть люди, не ищущие легких путей.

Выдавать DNS по ОВПН можно прямо в настройках ОВПН. Возможно, настройки появляются при смене типа овпн.

Зы. Смотрю в связи с #самизнаетечем на пф и аналогичные продукты спрос вырос (удаленный доступ etc).

@mohkhalifa said in access public SIP via remote with openvpn:

VPN and SIP both must be configured with the same protocol.

????

While the VPN normally uses UDP, but can use TCP, SIP is usually TCP and RTP uses UDP. The VPN should be passing both UDP and TCP, as would any other IP path.

@kiokoman thanks for the tip, I have configured a bridge with linux tools (brctl) and I'm using virt-io and I thought that would be enough but it is in fact very reasonable that it would actually introduce limitations and weird behaviors like what I'm seeing, I will dig further the issue

The OpenVPN option text should probably be renamed. The engine command in OpenVPN isn't required. When it's unset then it automatically selects a device which supports accelerating whatever cipher it's trying to use.

When it's set to a specific engine, it's supposed to prefer that engine but I don't believe it's restricted to only using that engine. Since most things only have 0-1 available usable engine types, that's not so easy to test.

So really the No Hardware Crypto Acceleration line should be Use any available cryptographic hardware device or something along those lines.

Ok, if you only have a firewall rule with the OpenVPN gateway set it will force all traffic out that way which will break connectivity to the LAN.
Add a rule on the new interface above any rules with a gateway set to pass ping traffic to the LAN.

Otherwise check the firewall logs. Check the state table while you're pinging.

Steve

@Bob-Dig
thanks for the interesting hint, tagging looks like a great feature!
So basically I am tagging all (!) my current rules in the LAN section where I define which traffic is allowed and that it goes through the OpenVPN gateway.
And the I setup a rule which rejects all traffic which is tagged and goes to WAN, correct?

How do I make sure that the only connection the pfsense can do itself will be to VPN Providers DNS and OpenVPN Servers?

As far as I understand this can also be done via "floating rules":

Floating Rules can:
Filter traffic from the firewall itself
Filter traffic in the outbound direction (all other tabs are Inbound processing only)
https://docs.netgate.com/pfsense/en/latest/firewall/floating-rules.html
[...]

-Tom

Which VPN service are you using? Almost all mainstream providers offer a split tunneling feature that allows you to choose which data to send through the VPN and which not. I use PureVPN but many others like ExpressVPN offer the same with their apps.

@ddbnj said in Cannot access beyond router via OpenVPN:

10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0

Yeah that would dick it up ;)

Glad you got it sorted! Told you it wasn't pfsense ;) hehehehe

The trick is getting the person to clearly see that themselves... Which is why the sniff proves to the user, hey pfsense is doing what its suppose to be doing... Have to look elsewhere..

@JeGr said in Question on OpenVPN restricting IPs:

Actually that's one point why I'm propagating the use of FreeRadius together with pfSense' OpenVPN in RAS scenarios, as it's much easier to handle than creating CSOs based on the CN of certificates. Also it minimizes the probability to make configuration errors that would allow VPN users to access pfSense WebUI with their only-for-VPN user when using internal authorization.

Yeah it's just a bit of a pain adding the users by hand, I did pop a redmine in for a copy function in the Freeradius package a couple of years ago.

https://redmine.pfsense.org/issues/8031

@Druplex said in OpenVPN unable to contact daemon pfsense 2.4.4_3:

What would be the issue?

The OpenVPN setup, the file with parameters that makes de service == daemon run correctly, contains errors. In this case, it's the place where you setup the OpenVPN settings.
So the daemon (== service) starts, and fails to work correctly, so it stops.
The GUI, let's say 'pfSense', can't contact the daemon, so it tells you what happens.

Btw : to have the OpenVPN server logs telling you what's right and what's wrong, think about putting the "Verbosity level" to 3 or 4.

Then go here :

9f1f9c6e-1512-44d7-a1d8-b844f75561a4-image.png

@JKnott
To be really honest...
A cosmic thing. Apparently not all VPN servers I've added (as client) are handing out ULA's. So on my dashboard it just looked sh*t.
Plus my OCD was hyping over this. ;-)

I just want one standard. So all three should give me an ULA or not.
Not just one.

In order for your roadwarrior clients to access resources @ site B, two things need to happen:

Site A's road warrior clients need to know that site B's LAN subnet should be routed down the tunnel Site B needs to know where to send the return traffic for site A's road warrior clients

Based on the above, the following adjustments should be made to the configs:

Site A:

Road Warrior config should have "192.168.20.0/24, 192.168.10.0/24" on the IPv4 Local network(s) line. (Remove 10.0.20.0/24).

Site B:

Re-verify the site-to-site config has "192.168.20.0/24, 10.0.20.0/24" on the IPv4 Remote network(s) line

Once the site-to-site tunnel is re-established and the clients re-connect, you should be good to go.

A brief update on the issue:
I did a several tcpdumps to see how traffic traveled through the machine.
pings from the Raspberry Pi 10.0.1.253 to 172.17.20.130 are sent to the ipsec interface and receive replies:
tcpdump -i lagg0.100 icmp

14:22:27.875175 IP 10.0.1.253 > 172.17.20.130: ICMP echo request, id 8761, seq 14, length 64 14:22:27.899031 IP 172.17.20.130 > 10.0.1.253: ICMP echo reply, id 8761, seq 14, length 64

These in turn are encapsulated:
tcpdump -i enc0 icmp

14:23:23.969153 (authentic,confidential): SPI 0x82bee771: IP 10.0.1.253 > 172.17.20.130: ICMP echo request, id 8761, seq 70, length 64 14:23:23.992999 (authentic,confidential): SPI 0xc030c198: IP 172.17.20.130 > 10.0.1.254: ICMP echo reply, id 21640, seq 70, length 64

We see the requests going out as 10.0.1.253 and replies coming in for 10.0.1.254, which are then translated back to finally be delivered to the Pi.

Now, when repeating this check with an OpenVPN client, we see different behavior:
tcpdump -i ovpns7 icmp

14:27:13.375762 IP 192.168.248.2 > 172.17.20.130: ICMP echo request, id 13598, seq 1, length 64 14:27:14.383797 IP 192.168.248.2 > 172.17.20.130: ICMP echo request, id 13598, seq 2, length 64

Requests go out, but nothing returns. Let's see where the requests go:
tcpdump -i enc0 icmp yields nothing, so let's try WAN:
tcpdump -i lagg0.4090 icmp

14:30:10.318176 IP 192.168.248.2 > 172.17.20.130: ICMP echo request, id 30820, seq 3, length 64 14:30:11.326380 IP 192.168.248.2 > 172.17.20.130: ICMP echo request, id 30820, seq 4, length 64

Now it's getting interesting: the pings from OpenVPN clients are sent to the default route (WAN). If I change the NAT rule's interface from IPsec to WAN, the translation also shows up in the tcpdump output:

interface: WAN address family: ipv4 protocol: any source: 192.168.248.0/24 destination: 172.17.0.0/16 NAT address: INT_IP (10.0.1.254) Pool options: default

Let's try the tcpdump again:
tcpdump -i lagg0.4090 icmp

14:33:12.248168 IP 10.0.1.254 > 172.17.20.130: ICMP echo request, id 15552, seq 1, length 64 14:33:13.251668 IP 10.0.1.254 > 172.17.20.130: ICMP echo request, id 15552, seq 2, length 64

So the firewall is correctly performing outbound NAT translation for 192.168.248.0/24->172.17.0.0/16 as 10.0.1.254, but the traffic is routed from the OpenVPN interface to the default gateway (WAN interface / lagg0.4090) rather than to the IPsec tunnel for encapsulation.

The whole point of wanting to use outbound NAT for traffic to 172.17.0.0/16 is so either side only needs to define one P2 entry, but we can set up multiple OpenVPN tunnels (with each a different subnet) that can all reach that remote network.

Would anybody know a trick / way to force traffic from 192.168.248.0 to 172.17.0.0/16 to go via the IPsec interface (enc0) rather than the default gateway (WAN/lagg0.4090)? I've tried creating a bogus gateway under System/Routing/Gateways and creating a static route under System/Routing/Static Routes for 172.17.0.0/16 via this bogus gateway, but this only resulted in all traffic from ovpns7 meant for this subnet to get put through a loop until the TTL expired.