Messages

works now - thanks a lot :)

Not sure if this is still relevant so shortly before 17.x, but I just noticed that the OpenVPN Client Export feature does not un-escape strings from the "additional config options" box.
I tried to put in the "reneg-sec 0" option there, which ended up in the ovpn file as "reneg-sec%200" with the space still web-encoded.

[might]

Just out of pure chance, I noticed something in the (i) help for the OpenVPN server settings, specifically the Renegotiation Time: "Renegotiate data channel key after n seconds (default=3600).
When using a one time password, be advised that your connection will automatically drop because your password is not valid anymore."
Now if THAT isn't the reason for my dropped connections, I don't know what else is.
This side effect might need being made a little more public, don't you think? It de facto means that key renegotiation and OTP are mutually exclusive, which will certainly be an interesting decision for business users.

This may come from using TOTP if you are using it.

yeah, as I wrote two posts further up.. I know that the automatic restart fails due to the OTP. This was clear to me from the beginning, and expected.
I do NOT know, why the connection drops at all, as long as there is active traffic, and the keepalive ping settings are reasonably short (10 seconds in my case). Even less do I know why the connection drops at such regular intervals. My users are working remotely via RDP, so there is always a constant stream of data, since RDP regularly sends "nothing changed" update packets if the screen is idle.
I am trying to find out, whether that's a result of some settings that OPNsense are using for their OpenVPN implementation, or whether I'm lacking certain settings on my clients, or anything that I'm missing which prevents me from actually using OpenVPN@OPNsense in our production environment.

I've now run some statistics on the logs and the reports from my users.. and there's a weird accumulation in certain connection durations. Most users get disconnected either roughly around 33 minutes or 63 minutes..
I don't have any information about the OSes those users run (commonly Windows 7, 8 or 10), but could there be any reasons that TLS sessions expire/fail to rekey after certain times?

No change.. still getting the same errors with the vmxnet as well.
(and I drowned in other projects for the last few weeks, so couldn't investigate this any further).
I'm still having the impression that the keepalive packets are getting lost somewhere, triggering the session restart. (which of course has to fail as the OTP has changed in the meantime, so the cached credentials are useless).
I'll create a second server instance without OTP to see whether at least the automatic session restart works around this problem, that'll buy me some time to get at the original cause.
My "keepalive packets lost" feeling is also reinforced by the problem _seeming_ not to occur for users which have the "redirect gateway" option pushed to their client.. or those users just don't complain.
Kinda annoys me having to debug in production... and lacking the time to do that properly.

I've now switched the e1000 card for a vmxnet card, but I don't see any difference. Will keep an eye on it for the next few days..

My host is 5.5 on most current patch level. I'm using whatever vmtools came with the OPNsense iso, which looks like the official ones. Not much a fan of switching interface type now.. I'm semi in production with that box already, and that idea smells of downtime.

yeah, the OPNsense is currently the only VM on our new ESXi 5.5 host. I'm using the Intel E1000 emulated network device, via the 'em' driver, which is what VMware recommends for FreeBSD.
Generally, networking works fine on that box.. no troubles with throughput or packet loss or anything at all, just these weird VPN disconnects.

I was just going to post "But I didn't create any NAT rules recently!" - but then I went to double-check.. and it seems that OPNsense auto-created a set of NAT rules when I set up an IPSEC Mobile service last week to test something, and did not remove them when I deleted that IPSEC service again.
Even weirder - I can't seem to get rid of those rules without switching to full-manual mode, which I would actually like to avoid.
The rules don't even make sense to me.. "Auto created rule for ISAKMP - OpenVPN server -> LAN" - when did OpenVPN start to use ISAKMP?!
There's something going wrong here with the automatic rule creation...

The behaviour is the same, whether it's 3 people logged in, or 50.
CPU load is below 20%, using crypto offloading on a current-gen Xeon.
I'm pretty sure that some handshake packets are dropped somewhere, but I don't know where, or how to sniff it out without digging through all crypted packets..

Hi again,
I've stumbled upon some other confusing issue with my OPNsense-as-VPN-concentrator project...
for some reason, there seems to have been a change in routing behaviour recently that I can't find the reason for.
When I started with the setup, I saw all connections from dialled-in users as coming from their virtual IP addresses (configured via ifconfig-push in the CSCs), and I set up the firewall rules accordingly (users' VPN IP allow RDP to their workstation IP). For some reason, recently I only see connections in the log seeming to originate from the OPNsense LAN IP, even though they clearly are initiated by VPN-connected users.
I don't recall changing anything to the setup except adding more users..
Can anyone provide a hint on what could cause this behaviour? It kinda messes up my whole security concept..

Nobody got any idea how I could dig into that issue further?

Hi all,
(this is not directly related to OPNsense code itself, just a service provided by an OPNsense box, but here are people who know OpenVPN and can probably help me, I'm sure..)
I've now got about 50 regular users on my OPNsense OpenVPN concentrator, and I keep getting complaints that connections are dropping out, mostly around the 1 hour mark.
The log always shows the same picture.. a slew of messages "openvpn[78997]: hans/191.19.25.210:63081 TLS Error: local/remote TLS keys are out of sync: [AF_INET]191.19.25.210:63081 [1]", followed by one "openvpn[78997]: hans/191.19.25.210:63081 [hans] Inactivity timeout (--ping-restart), restarting"

All web research I've done points to this message relating to firewall config issues, but then the connection shouldn't even be able to be established in the first place.
To me, it looks like some part of the keepalive packets either can not be sent or do not arrive.. but I failed to find any details of what the keepalive actually consists of, and which firewall rules I might need to permit it.
Also, it does not seem to match up from a time perspective.. my server has "keepalive 10 30" set, which should kill the session much sooner than one hour, if it really was keepalive related.

I've switched users from UDP to TCP connection mode, with no difference. I've played with the numbers in the keepalive settings, also no change. I can't really just sniff packets on all interfaces for hours, hoping to catch the one that makes trouble, either...

I'm running out of ideas how to debug this further.. so if anyone can provide enlightenment, I'd be really grateful.

Regards
~woo

Thanks, that works! :)