[SOLVED] OpenVPN Broken

[jschellevis]

I just tested it on my setup also upgraded for 17.7.12 to 18.1 and I can not confirm or reproduce the issue.

In general I would check the following:

1) Packet capture on OpenVPN and WAN and see if the packets are visible on both. If you see them on both OpenVPN and WAN interface, then make sure the IP on WAN is correctly NAT-ted.

2) If packets flow but some website are not reachable, then make sure if isn't an MRU issue.
    Add the following to the advanced section of your configuration:

Code Select Expand

mssfix 1200

Hope this helps if not try to make a complete assessment of what is different between 17.7 and 18.1 including config files and make sure NAT/MTU is not the issue.

Cheers,

Jos

[k1ll3ry0]

I'll definitely give it a try! And for the individual asking for the OpenVPN configuration, it is as follows...

Code Select Expand

<openvpn>
<openvpn-client>
<auth_user>-_-</auth_user>
<auth_pass>-_-</auth_pass>
<protocol>UDP</protocol>
<dev_mode>tun</dev_mode>
<server_addr>us-east.privateinternetaccess.com</server_addr>
<server_port>1194</server_port>
<resolve_retry>yes</resolve_retry>
<proxy_authtype>none</proxy_authtype>
<mode>p2p_tls</mode>
<crypto>BF-CBC</crypto>
<digest>SHA1</digest>
<engine>none</engine>
<verbosity_level>1</verbosity_level>
<interface>wan</interface>
<vpnid>1</vpnid>
<custom_options>
persist-key persist-tun tls-client remote-cert-tls server comp-lzo reneg-sec 0
</custom_options>
<caref>57c8e024416d2</caref>
<certref/>
</openvpn-client>
</openvpn>


Obviously the user info is different. I have bypass routing through a manual NAT configuration that allows traffic through WAN instead of the tunnel for certain specified IPs within aliases. Just frustrated because it's worked flawlessly for so long on older versions of pfSense and OPNsense(which I obviously switched to) when I made the switch I made some edits to the config file so it would import but if others are having similar issues I'm pegging it more on OpenVPNs issues and not so much the config but who knows!

[guest15389]

Be sure the DNS is configured properly too. I had the issue when I setup initially on 17 series and just noticed after the upgrade, my access list in Unbound was not there causing my DNS resolution to fail once I was VPN'ed in.

The default rule was a /32 subnet which didn't allow the clients to use it so I made another access rule for the /24.

https://imgur.com/a/Bi4Wp

[Noctur]

Hi Jos,
Thanks for your comments and willingness to look at this.

The config files are identical between the two - absolutely no changes. The mssfix on my current config is:

mssfix 1450

This is what is recommended in the providers config dl file.

To try the mssfix 1200 I would have to reinstall 18.1. I don't have time to do this right now, but I'll try the mssfix 1200 on my current setup with 17.7.12 to see if it still works, then maybe run the upgrade to 18.1 - over the weekend.

[Noctur]

Be sure the DNS is configured properly too.
https://imgur.com/a/Bi4Wp

Thank you! Will check this. Might be the issue. 

[k1ll3ry0]

The activity and help within this thread is very much appreciated, I will check the Unbound DNS when I get home tonight. I plan on maybe a fresh install later to try and figure this out.

[k1ll3ry0]

Fresh install of 17.7.12_1, working like a charm with no errors and no glitches...such a shame to see such issues with a major stable release but I'll upgrade some day when I have more time! Tried all remedies from within this thread as well as a fresh install and reconfiguration but it simply wouldn't work. Very pleased with my current setup and it gives me the piece of mind I need when surfing the web and streaming. Hopefully OpenVPN or OPNsense releases a fix for the issue!

[kanstin]

I am also having issues with my OpenVPN connection. I can ping the remote network from the router but it doesn't seem to be routing packets from machines on my local network. I have an outbound NAT to translate LAN network (192.168.7.0/24) packets with destination of the remote network (172.31.22.0/24) to Openvpn address but that doesn't seem to be happening.

[elektroinside]

Mine is perfectly fine, strange. I can communicate with clients from whatever direction, from wherever, however...

[marjohn56]

Mine is perfectly fine, strange. I can communicate with clients from whatever direction, from wherever, however...

As I said in another thread, you're obviously doing the same 'wrong' thing as I am, mine is working perfectly too.  8)

The only commonality with us is that we came to 18.1 via RC.

[elektroinside]

Maybe that's the key element? That we are coming from 18.1.rc1 > rc2 > release?

[marjohn56]

It's a possibility, I did check 'some' of the patches that were used in 18.2 RC against 18.1, and they were in place, namely the final two that Franco issued for the Alias issues I had suffered. The thing against that idea is that my 18.1 install was a clean install. The only difference was that I also did a new config apart from the VPN stuff which I imported from the old config.

[franco]

I don't think so.

Key factors are 17.7 vs 18.1, robustness in fundamental setup, additional side effects we don't know about.

It is hard to unpack all of this, especially keeping in mind the beta (testing FreeBSD 11.1) and release candidate (our NAT changes on top) being out for longer periods than usual, getting fair exposure. The RC1 -> RC2 change log reflects that:

https://github.com/opnsense/changelog/blob/master/doc/18.1/18.1.r2

18.1.1 will be out soon, but I expect that "weird issues" will prevail due to said key factors.

In any case... We've always had issues with initial releases and we are doing what we can to inspect and address those. All it takes is time to get there.

To everyone updating: thank you.

To everyone reporting: thank you.

:)


Cheers,
Franco

[Lutz3D]

I have a similar problem with my openvpn server on 18.1.

I had to do a reset of my configuration. Because of that, i had to reconfigure my openvpn server. I used the openvpn wizard for this. Everything went fine, but if i want to connect from my devices i get the error "NO Route to Host".

So it looks like the wizard did not create the firewall rule andd I had to add the rules manualy.

Just for your information.

I don't if its a generel problem with version 18.1, but in 17.7 it worked perfect.

[kanstin]

Mine is perfectly fine, strange. I can communicate with clients from whatever direction, from wherever, however...

As I said in another thread, you're obviously doing the same 'wrong' thing as I am, mine is working perfectly too.  8)

The only commonality with us is that we came to 18.1 via RC.

Would you mine sharing the relevant firewall and NAT rules?