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

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

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

@johnpoz said in Same ip subnet for two VPN: Some other advice 192.168.1 is not a good choice to be honest.. This is very very common - say your at a starbucks or something needing to vpn in to your site and they are using 192.168.1 locally.. Now you have a problem.. Client thinks that your server 192.168.1.100 for example is just local - and won't send it down the tunnel to get to it. Yep, I had that problem years ago when I was staying at hotels. That's why I moved my LAN to 172.16.0.0. I have only seen that used elsewhere once.

the routing table now is the same ? maybe it was something else on the configuration

Why do you use a /24 net for a site-2-site. A /30 will be the better choice here. @Cricco95 said in OpenVPN site2site not working: Trying to ping VPN server interface on 10.8.0.1: You did the ping from WAN IP. Don't know what your WAN is, but you may miss the route. What it you do a ping from LAN? If it works, try a ping from LAN to the remote LAN IP of the server.

Added to what @NogBadTheBad said : Start up a new OpenVPN server on - example - port 1195. Assign this user - his credentials - to this VPN. Assign the OpenVPN interface of this instance to an Interface. Now you can use this firewall for this interface to fine-grain the access on IP "destination". When a user comes in using a VPN, he can access - typically - your LAN(s). But all devices on these LANs have their own access codes. The server your user should access has it's own user privileges set up, right ? Btw : put your server on a DMZ ....

@EFP-TechTeam said in pfSense OpenVPN site-to-site client dies every day or two.: The logs don't give a lot of clues. What do they say?

Thoughts anyone?

2nd vote for an SG-5100.

Show your OpenVPN Config and Firewall Rules (Screenshots). -Rico

This is one of many reasons I dropped pia and nord. Either way I suggest reading up on the remote host command https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

@mlohr said in Possible bug: Newline stripped on saving: Yeah, this way it works. But why are some newlines stripped and some not? It doesn't matter, because newlines are not supported in that box. Use semicolons to separate entries and you'll never have to worry about it again. As to the why, it's probably a difference in browsers and UNIX/Windows newline styles, or who knows what. They're unreliable, hence the semicolon requirement.

For the record: I neglected to include this: OpenVPN 2.4.7 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on May 22 2019 2019-05-26 20:02:35.129809 library versions: OpenSSL 1.0.2r 26 Feb 2019, LZO 2.10 Tunnelblick: macOS 10.14.5; Tunnelblick 3.7.9 (build 5320)