OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: Noctur on January 30, 2018, 07:26:38 pm
-
Updated yesterday, tried to enable several prior OpenVPN clients and while they would indicate connected, no data comes through. Every attempted website returns not found. Note that connecting with TOR browser is successful.
Anyone else seen this?
How can I safely downgrade to the 17.7.12_1 version I was on until this gets sorted out? TIA.
-
I'm using OpenVPN and it seems to work fine.
Are you passing any traffic through once you connect? Can you ping your DNS that you have setup?
-
Thanks for the prompt reply,...
With a client profile enabled and from SSH to the console - yes pinged with 3 responses and 0 loss.
But, I had to disable the profile to respond to this question via Firefox browser. Browser was updated to 58.0.1 very recently.
-
Attempting to downgrade with
# opnsense-revert -r 17.7.12 opnsense
or
# opnsense-revert -r 17.7.12_1 opnsense
results in
Fetching opnsense.txz: .. failed
Recommendations? TIA
-
I'm having the same issue. I did a clean install of OPNsense 18.1 last night. In client mode, I could connect to PIA's VPN server (AES-256-CBC & SHA256), but could not route traffic. I troubleshot for about 10 minutes, then ran out of time. I'll do more troubleshooting tonight when I get home.
-
Similar... Nord VPN here, tried several profiles that worked prior to the upgrade, checked server status, created 2 new profiles to new servers. All the same - get connection up indication, can't make browser connection with Firefox or IE.
Don't have time to troubleshoot more atm. So was trying to revert but that's not working.
Anyone have recommendations on how to downgrade back to 17.7.12? TIA
-
I use PIA and mine is working, but I'm not sure what difference with your network setup compared to mine is I'm afraid.
-
I use OpenVPN to connect it to my home network and ExpressVPN as well for outbound traffic. Both are working without issue.
-
Thanks for the comments, all. Looks like its something intermittent.
Any recommendations on how to downgrade? the command
# opnsense-revert
isn't working. Is there a different command between major revs? TIA
-
Just updated mine to 8.1, I run a full network OpenVPN tunnel with alias bypasses for platforms like Netflix and Amazon Video. Upon updating I'm unable to connect to a number of sites like opnsense.org, privateinternetaccess.com, stackoverflow.com, Reddit, the list goes on but there's also a ton of sites that work too...I ended up restoring from backup with no positive outcome. Attributing this to OpenVPN as well because once disabled the network connects perfectly fine.
-
Last one sounds like an MTU issue?
opnsense-revert isn't working because you can't cross major version borders easily. It's dangerous to downgrade, in fact I tried but pkg is refusing to downgrade in the sequence we try to upgrade after changing the version back to 17.7. FreeBSD likes to keep pkg incompatible between 11.x releases. Sorry.
Your best bet is to do a 17.7.5 image configuration import + guided install to replace your system inline while retaining the configuration.
Cheers,
Franco
-
Thank you for confirming the major rev downgrade restriction. I had pretty much boiled it down to 2 choices - install 17.7.5 (the last available on download) and restore settings or clean install 18.1 and restore settings. I'll try the 18.1/restore first, and if it doesn't resolve I'll go with the 17.7.5/restore.
-
Quick update... reinstalled 17.7.5, updated to 17.7.12_1, restored settings file. Everything working as expected. One note, I performed a factory reset on 18.1_1 and then restored setting file - same issue with OpenVPN. Went the reinstall route.
-
That's such a bummer. I wonder what's causing the issue...Should have know not to upgrade so close to the release date. Hoping a hotfix comes around so I can retain my OpenVPN functionality because not using one skeeves me out a bit...
-
Could you please post, for bot working and non working the generated config file for openvpn?
That way we could determine if there is a difference in settings causing this. Thx!
-
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: 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
-
I'll definitely give it a try! And for the individual asking for the OpenVPN configuration, it is as follows...
<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!
-
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
-
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.
-
Be sure the DNS is configured properly too.
https://imgur.com/a/Bi4Wp
Thank you! Will check this. Might be the issue.
-
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.
-
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!
-
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.
-
Mine is perfectly fine, strange. I can communicate with clients from whatever direction, from wherever, however...
-
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.
-
Maybe that's the key element? That we are coming from 18.1.rc1 > rc2 > release?
-
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.
-
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
-
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.
-
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?
-
OpenVPN Wizard created default OpenVPN Interface rule which is:
Action = Pass
Interface = OPENVPN
TCP Version = IPV4
Source = Any
Destination = Any
Dest.Port Range = Any
Gateway = default.
OpenVPN Wizard created default WAN Interface rule which is:
Action = Pass
TCP Version = IPv4
Protocol = UDP
Source = ANY
Destimation = WAN Address
Destination_Port_Range = OpenVPN
Gateway = Default
-
OpenVPN Wizard created default OpenVPN Interface rule which is:
Action = Pass
Interface = OPENVPN
TCP Version = IPV4
Source = Any
Destination = Any
Dest.Port Range = Any
Gateway = default.
OpenVPN Wizard created default WAN Interface rule which is:
Action = Pass
TCP Version = IPv4
Protocol = UDP
Source = ANY
Destimation = WAN Address
Destination_Port_Range = OpenVPN
Gateway = Default
Those look like OpenVPN server rules. Does anyone have a working OpenVPN client?
-
There are my firewall rules for LAN, NAT outbound, and the relevant routing entries. Can anyone see why I can't ping the remote network from LAN? I can ping from the router device but not from a LAN device. These rules worked on 17.7 but this doesn't work with 18.1. Thanks.
-
OpenVPN Wizard created default OpenVPN Interface rule which is:
Action = Pass
Interface = OPENVPN
TCP Version = IPV4
Source = Any
Destination = Any
Dest.Port Range = Any
Gateway = default.
OpenVPN Wizard created default WAN Interface rule which is:
Action = Pass
TCP Version = IPv4
Protocol = UDP
Source = ANY
Destimation = WAN Address
Destination_Port_Range = OpenVPN
Gateway = Default
Those look like OpenVPN server rules. Does anyone have a working OpenVPN client?
i just use the client export wizard and import that config into openvpn. It works.
-
My outbound NAT rules aren't being implemented on the router, see below. What command line can I use to force my rules? Thanks,
-
Looking in /tmp/rules.debug I can see that my NAT rules are commented out like they're disabled. See image. So that is the problem. How do I fix this? Thanks,
-
Ok I found a temporary work around for me. In the /tmp/rules.debug file there was this:
# nat on openvpn inet from 192.168.6.0/24 to any port 1024:65535 # WIFI to OpenVPN
# nat on openvpn inet from 192.168.7.0/24 to any port 1024:65535 # LAN to OpenVPN
I changed that to this:
nat on openvpn inet from 192.168.6.0/24 to any -> openvpn port 1024:65535 # WIFI to OpenVPN
nat on openvpn inet from 192.168.7.0/24 to any -> openvpn port 1024:65535 # LAN to OpenVPN
And issued this command:
pfctl -f /tmp/rules.debug
And now my openvpn works. So there is an error in the Outbound NAT code that generates that part of the rules file.
-
I seem to recall the NAT Outbound NAT Address was something else than Interface Address. Wasn't it OpenVPN address and the WAN was WAN address? Now they are both Interface Address, which makes sense.
I have something similar in /tmp/rules.debug
nat on igb1 from 192.168.1.0/24 to any port 500 -> igb1 static-port # Auto created rule for ISAKMP - OPT1 -> WAN
# nat on openvpn inet from 192.168.1.0/24 to any port 500 static-port # ISAKMP - OPT1 -> WAN_VPN4
nat on igb1 from 192.168.1.0/24 to any -> igb1 port 1024:65535 # Auto created rule - OPT1 -> WAN
# nat on openvpn inet from 192.168.1.0/24 to any port 1024:65535 # OPT1 -> WAN_VPN4
-
I'm trying to setup a VPN client, and I'm seeing a strange issue when trying to set the Outbound NAT.
I can't select the WAN as the Translation / target, when I do i receive the error:
The following input errors were detected:
A valid target IP address must be specified.
However if I pick any other network it seems to be OK. Unfortunately I need to configure the NAT for the WAN interface.
Seems to be a similar problem as others in the thread.
-
Ok I found a temporary work around for me. In the /tmp/rules.debug file there was this:
# nat on openvpn inet from 192.168.6.0/24 to any port 1024:65535 # WIFI to OpenVPN
# nat on openvpn inet from 192.168.7.0/24 to any port 1024:65535 # LAN to OpenVPN
I changed that to this:
nat on openvpn inet from 192.168.6.0/24 to any -> openvpn port 1024:65535 # WIFI to OpenVPN
nat on openvpn inet from 192.168.7.0/24 to any -> openvpn port 1024:65535 # LAN to OpenVPN
And issued this command:
pfctl -f /tmp/rules.debug
And now my openvpn works. So there is an error in the Outbound NAT code that generates that part of the rules file.
Kanstin has hit the nail on the head. I am also using OpenVPN in client mode to redir all my egress traffic to a VPN provider. I troubleshot this for hours and tracked it down to NAT rules. Kanstin's fix worked for me for a few minutes, but anything that triggers the rulebase to reload will rewrite the /tmp/rules.debug file with the bad syntax and comment it back out.
In response I deleted all my OpenVPN NAT rules and re-created them, but that did not have any effect.
It seems this is affecting anyone who went to Firewall: NAT: Outbound and changed it from Automatic to Manual in order to add their own NAT rules.
-
FYI, I run PIA at home, and shunt all my default traffic out to PIA.
My default NAT rule goes out of PIA then I have an Alias with hosts configured that should by pass PIA.
With that said, IT turns out I needed to have another rule in my Outbound NAT that set my PIA interface with my bypass PIA alias list as the source, and tell it NOT to NAT.
Once I did that, things started working proper again after I flushed all of the state tables.
Not sure if this helps or not, but figured I'd add in my two cents.
-
So here is a patch:
https://github.com/opnsense/core/commit/bad6be2
Removing edge cases in the outbound NAT generation for 18.1 made the newly written rules fail with OpenVPN in pf.conf as there seems to be an ambiguity in the way that "(something)" vs. "something" is validated. The edge cases were identified and excluded while the general usage flipped from parenthesis-less usage to using them almost exclusively.
Patch apply and test via:
# opnsense-patch bad6be2
# /usr/local/etc/rc.filter_configure
All feedback is highly appreciated for a quick 18.1.2 inclusion path. :)
Cheers,
Franco
-
Patch applied, no errors so far... at least nothing obvious
-
The patch resolved the issue for me. Here's what I did:
On 17.7.12_1
Saved Config 1 with OpenVPN disabled
Saved Config 2 with OpenVPN enabled
Fresh install 18.1 over 17.7.12_1
Restored Config 1
Firmware Update, installed 18.1.1
Ran Patch above
Reboot
Restored Config 2
Checked ipLeak, other sites, installation performing as expected.
Thank you! Will continue to monitor as it has only been running about 15 minutes.
-
My VPN was all good before the patch, but I can confirm that everything works fine even after the patch :)
-
Well done. Patch works. Defined static addresses for VPN traffic on VLANS.
-
Okay, I am marking this solved, planning 18.1.2 for Thursday.
Thank you everyone!
Cheers,
Franco
-
Yeah patch works for me as well. Awesome. Thank you, Franco.
-
Thanks all, 18.1.2 is tested and ready for release tomorrow around noon UTC.
-
Awesome, thank you Franco!