OpenVPN server connection and tunneling back out
-
I have the OpenVPN server on my 4100 as well as tunneling out (NordVPN). If I remotely connect to my router, I can get to all the local resources, but can't browse the internet. If I disable the tunneling, I can browse the internet.
From inside the network, the tunneling works just fine.
What setting(s) and/or firewall rule(s) (on which port) do I need to set in order to make this work? I'm running 22.05.
Thanks
-
@davidstoll
Did you add an outbound NAT rule for the access server tunnel IP pool? -
@viragomann Probably not. Which port (LAN, WAN, virtual openvpn port) would it go on and what would that rule look like?
-
@davidstoll
Firewall > NAT > Outbound.
The hybrid mode might be already activated. Otherwise switch over and save it. Then add a new rule:Interface: NordVPN
source: <OpenVPN tunnel network>
destination: any
translation: interface address -
@viragomann Thank you so much! That was it! I am so grateful!
-
This post is deleted! -
@davidstoll
But this has presumably nothing to do with the suggested settings above.I have exported the configs using the openvpn export plugin,
Hmmm. It looks like as there would be something wrong in client settings though.
Can you post server and client settings, please?Which OpenVPN version are you running on both?
-
On Windows, 11.9.0.0.
On Android, v3.3.0.(8367)I have 2 completely different servers (not pfsense) that I connect to with these clients without issue.
Below is the ovpn for windows that the export plugin gave to me. I did have to edit it due to errors, but I have commented out the original lines that HAD to be replaced or it wouldn't connect. I also added a line due to a warning about caching passwords. Lastly, I blanked out the ip and port.
dev tun
persist-tun
persist-key
#data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
#data-ciphers-fallback AES-256-CBC
#auth SHA1
auth SHA256
tls-client
client
resolv-retry infinite
remote XXX.XXX.XXX.XXX YYYY tcp4
nobind
auth-user-pass
remote-cert-tls server
cipher AES-256-CBC
#cipher AES-256-GCM
dev tun4
auth-nocache
#link-mtu 1551
tun-mtu 1500
auth-nocache -
I hope that was enough info....? Thank you again for helping me with this.
-
@davidstoll said in OpenVPN server connection and tunneling back out:
On Windows, 11.9.0.0.
On Android, v3.3.0.(8367)I was requesting the OpenVPN version.
The resent is 2.5.7. There could possibly be issues if you ran an older 2.4.x on a client, while the server is 2.5.x or the other way round.Below is the ovpn for windows that the export plugin gave to me. I did have to edit it due to errors
That's maybe due to different OpenVPN versions.
What were the errors before?
Maybe the issue you have now is due to the changes you made. But since you removed the log, I don't know.#cipher AES-256-GCM
This should work fine in recent versions, as well in 2.4.x.
Also data encryption should work properly.The client settings have to match to the server settings. When you export the config file, there shouldn't be a need to do changes at all.
But as I see only one, I cannot evaluate. -
On the versions, the android/windows versions are just what I see in the "about". So, maybe that is the GUI version, but I don't see the underlying "version" of OpenVPN in either situation.
See attached.
and
-
@davidstoll
The OpenVPN versions are mentioned in the clients log files. -
Actually, there is more than one change in the config file. Anywhere there is a #, I had to remove it or, in that a couple cases, make a correction.
In any case, I just searched through the log file on my android and there was no mention of the version or 2.4 or 2.5.
In the Windows client, the log file shows 2.4.4.
-
Sorry, deleted the log file because there was something in there that I didn't edit....anyway, here it is again...
Thu Sep 08 16:37:51 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.xxx.xxx.xxx:yyyy
Thu Sep 08 16:37:51 2022 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.xxx:yyyy [nonblock]
Thu Sep 08 16:37:52 2022 TCP connection established with [AF_INET]xxx.xxx.xxx.xxx:yyyy
Thu Sep 08 16:37:52 2022 TCPv4_CLIENT link local: (not bound)
Thu Sep 08 16:37:52 2022 TCPv4_CLIENT link remote: [AF_INET]xxx.xxx.xxx.xxx:yyyy
Thu Sep 08 16:37:52 2022 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1551', remote='link-mtu 1571'
Thu Sep 08 16:37:52 2022 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-GCM', remote='cipher AES-256-CBC'
Thu Sep 08 16:37:52 2022 WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA256'
Thu Sep 08 16:37:52 2022 [openvpn] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:yyyy
Thu Sep 08 16:37:53 2022 Preserving previous TUN/TAP instance: Ethernet 2
Thu Sep 08 16:37:53 2022 Blocking outside dns using service succeeded.
Thu Sep 08 16:37:53 2022 Initialization Sequence Completed
Thu Sep 08 16:37:59 2022 Connection reset, restarting [0]
Thu Sep 08 16:37:59 2022 Unblocking outside dns using service succeeded.
Thu Sep 08 16:37:59 2022 SIGUSR1[soft,connection-reset] received, process restarting -
If I uncomment out the lines from my auto generated config and remove my replacement items, I get the following short info from the log...
Options error: Unrecognized option or missing or extra parameter(s) in pfSense-TCP4-config.ovpn:4: data-ciphers (2.4.3)
Use --help for more information. -
@davidstoll
Since you're running an 2.4.x client, check "Legacy Client" in the client export utility and export a new config file. -
@viragomann I don't have any options. I can only click on the OS that I am trying to export for. Is there a better export plugin maybe? I'm using "Openvpn-client-export v1.6_4, which seems to be the latest as far as I can tell.
-
@davidstoll
Try this one:
-
Ok, thanks. I did that and it only gave me one warning about password caching, so that did help with the config compatibility.
However, every 3 hours it disconnects.
...
Fri Sep 16 08:33:38 2022 Initialization Sequence Completed
...
Fri Sep 16 11:33:26 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 16 11:33:26 2022 TLS Error: TLS handshake failed
Fri Sep 16 11:33:26 2022 Fatal TLS error (check_tls_errors_co), restarting
Fri Sep 16 11:33:35 2022 Initialization Sequence Completed
...
Fri Sep 16 14:29:24 2022 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Sep 16 14:29:24 2022 TLS Error: TLS handshake failed
Fri Sep 16 14:29:24 2022 Fatal TLS error (check_tls_errors_co), restarting -
@davidstoll Any other suggestions? I would really appreciate it. I think we have made it a little better, but it just doesn't wan to stay connected and it disconnects on a scheduled basis (not randomly).