Messages

I had only one OpenVPN server, when I posted in April I was working on a second.  now I have three -- one for site-to-site, one for road-warriors (split tunnel), and the third is road-warriors with default route (tunnel everything).

Since I was creating a new one, I did it as an "instance" -- and it's easy enough, so I deleted the original "server" and re-created it as an "instance".

DHCP will be another matter, but again it shouldn't be that complicated to re-create.

But I do wish they would provide a tool.  After update, wizard pops up "Hey, ISC DHCP is being deprecated, click here to migrate"...  Script runs, maybe you can see what it does before accepting.  It shuts down ISC, and starts Kea.  "OK, all done!"

[the two settings are named exactly the same.]

I fiddled with it for a while, but the upshot is, you're correct.  I listed the entire /24 I intend for remote these remote sites under "Remote Network" on the Instance config, while leaving the original /27 under "Remote Network" on the CSO.  This works.  The /24 shows up on OPNsense's route table, and IP's on the /27 are reachable from the HQ network.  I thought this might create a duplicate route, so I powered on a second box which should get a different /27 out of the same /24.  I don't know if this is recommended or not (/24 on Instance page, /27 on CSO), but it appears to work as intended.

I think this is very confusing -- and I don't think it's how stock OpenVPN works, although I've been using it on appliances (as opposed to setting it up myself from scratch) for so long the config syntax may have changed.  But regardless, the two settings are named exactly the same.  It's logical to assume that a Client Specific Override would override a setting of the same name from the Instance config, so leaving "Remote Network" blank on the Instance, and specifying it as an Override, would make sense.

I updated my bug report to instead be a documentation improvement.

Yeah, that's exactly, what it needs.
As mentioned, the further routing is done inside OpenVPN.

Right.  But OpenVPN enters a route into the OS, which isn't happen.  A Client-Specific-Override is basically appended to the server config when a matched client connects.  So the main server config doesn't have a "remote network" defined, but when a client-config is matched, that config is effectively part of the server config.

client-config-dir /var/etc/openvpn-csc/1
As far as I know, the client files are stored in a subdirectory named <guid>, the same as the instance, they belong to.

The OpenVPN process is reading the instance<guid>.conf file, you can see that by running "ps -aux |grep openvpn".  In my case, that config file is specifying  /var/etc/openvpn-csc/1/ for client specific overrides, and that directory exists.  I have those configured in the GUI, but they don't exist in that directory.

[That directory exists, but its empty.]

UPDATE:  I looked at the server config file, /var/etc/openvpn/instance-<guid>.conf -- I see the following line:

client-config-dir /var/etc/openvpn-csc/1

That's where I would expect to see the Client-Specific Override files.  That directory exists, but its empty.  Obviously that's my issue -- the OpenVPN configuration isn't picking up the client config at all.  In fact I have 3 separate Client Specific Overrides configured in the GUI, none of them show up in any of the client-config-dir's, meaning /var/etc/openvpn-csc/*/ -- there's no files in any of those.

I think this might be a bug?

Oh?  So you're saying at the Instance I need to enter, eg, 10.0.249.0/24, and then a client-specific override of 10.0.249.64/27 ?

Normally that "remote network" option will cause the OpenVPN server process to enter a route in the OS routing table, and then route the block to the client -- which in the above case would mean I'd get two routes, 10.0.249.0/24 and 10.0.249.64/27 both routed to the client.  What I want is /27's routed to each of several clients, as I have several of these boxes out there.

I'll give it a try -- nothing to lose at this point LOL.

Currently on 25.1.12.  I have an OpenVPN instance used by a couple remote devices (console server devices) -- my issue is the clients each get a subnet routed to them via Remote Network, but that isn't working.  Setup info below:

Instance:
Server: 10.0.3.192/27 -- IP's used for clients to connect
Topology: Subnet
Local network: 10.0.250.0/24 -- Route pushed to clients
Remote network:  Blank

Client Specific Overrides:
Common name: consolevpn3
Remote Network: 10.0.249.64/27

The client connects fine.  From the main 250 network, I can get to the client VPN IP in 10.0.3.x and manage the device.  The remote device has the route to the Local Network, the main 250 subnet, and it can get to other stuff in the main 250 network.  The remote network shows up under Connection Status -> Routes, but it doesn't work -- it's not in the route table under System->Routes->Status (and doesn't show up in 'netstat -rn' either) -- and the main network NOT get to the remote LAN devices (including the LAN IP of the device itself).  In fact, I can prove using tcpdump on the Opnsense that it is sending that Remote Network out the default route -- so this seems like an OpenVPN and/or routing issue, not a firewall/filter issue.

I'm sure I'm missing something obvious, but I haven't found it yet.

Hi,

Once 26.1 comes out, legacy OpenVPN configs will be deprecated will there be a migration tool or script to move those configs to the new Instances section?  Or should I work on migrating that myself before that?

Same question for ISC DHCP over to Kea DHCP, but that might be more complicated -- OpenVPN is still OpenVPN, whereas ISC and Kea are totally separate.  Also, in the GUI at least, ISC doesn't say anything about going away.

Thanks all!  :-)

FWIW, I just noticed the box I ran the backup *from* is still on 23.1.11.  The purpose of the backup is actually to test out my config on newer hardware (Sophos XG105 instead of UTM220) -- but I'd like the historical vnstat data to come over as well.

If it's not included in the backup, obviously I can just stop vnstat and copy over /var/lib/vnstat/vnstat.db -- no biggie.

Hi, I have the VnStat plug-in -- great for monitoring usage against provider caps...

I ran a backup from System -> Configuration -> Backups, including the RRD's.  I'm not positive, but it doesn't *appear* that the VnStat data is included in the XML backup.  (* yes, I realize VnStat has its own data, not associated with RRD's -- I said "including RRD's" thinking that might change the behavior).

Can anyone confirm if that is the case?  If not, could that be a feature request?

Sensei policies are not that granular since you are limited to 3 policies on the paid home model. So basically allowing Facebook for 1 kid and blocking it for another you already wasted 2 of 3 policies.

It's the biggest flaw of sensei really and I'm forced to use one and the same policy for all my kids.

3 is probably not enough, unless I can enable it only for a specific interface...  I have a separate VLAN for kids, ostensibly because I don't want MY stuff going through the Circle.  :-)

OP, you dont give much information about whats wrong with the "it's not working". What exactly isnt working?
I'll take a wild guess and say that the mycircle isnt blocking the traffic like it is supposed to?

Have you done any troubleshooting? I would start to check the ARP table from a device on the kids vlan to see if the mycircle is doing it's MITM as it's supposed to. If it is you should see the mac of mycircle on the default gateway.

After factory reset of the device and the management app and repeating initial setup.  It gets as far as connecting the device to WIFI, and then the app can't find it, which has to happen before it can actually do anything.  The AP shows it connected, and DHCP is giving it an IP.  But the app can't find it.

Their support says it must be because the firewall is preventing arp spoofing.  I don't know how that could even happen, the firewall can't block arp packets at Layer-2...  The AP or switch potentially could, but those haven't changed in literally years (both are long-since out of support).  They said the product is designed for "simple home network", and won't work with "enterprise firewall".

They also say the device is old and support isn't guaranteed.  To which I replied, either support it or call it end-of-life and tell me to buy a new one!  And I received back pre-canned instructions to factory reset the device and the app, reboot my modem, and try again...  Which I've done several times...   :o

I'd be good with a replacement solution, but haven't found one I like.  I need easy app control over time limits (including extensions / rewards) on a per kid basis.  That's the most important at this point...

OPNsense already does child protection perfectly here, using Sensei. You can even pay for it (which I did because it's worth it).

Unless there's something I don't understand, and that very well may be the case, Sensei is security and threat-prevention, which is great, and brings OPNsense up to part with the big commercial players.  But it's not parental controls.  I need to enforce off-time for specific users (which I can pre-define by MAC address), with an easy way to grant additional time.  I need to enforce basic content filters, again for specific users (so one kid can use facebook, but the other can't).  The Circle device accomplishes both of these and more, beautifully -- until it quit working  >:(

Since ARP spoofing is an attack in L2, OPNsense would behave correctly perfectly by preventing it (if it does).

That should imho not be supported. If you want to filter the client traffic, you can do so on OPNsense itself.

I get it.  Generally you don't want arp spoofing happening on the network.  But it's a fact of life in a public WI-FI -- someone at a Starbucks should assume their packets are being intercepted, and must rely on universal end-to-end encryption.  There's really no other option.

In my case, this is arp spoofing by design.

Hi--

I have a Mycircle device.  It's a parental controls device -- it connects to WIFI, and then uses arp spoofing to "become" the default route so it can see who's talking to who.  Based on client MAC (which can be grouped up under profiles -- in our case per kid, so the teenager has different filters than the 9 year old), it can filter access to specific sites, or block all access, and it's controlled by a simple app.   ((as an aside, I absolutely hate this device -- I would love it if OPNsense did this, I'd even pay for it))  I have a separate "Kids" VLAN that has the Circle, the regular VLAN doesn't...

The device hasn't been working, and support is saying it isn't their fault, it must be the firewall preventing arp spoofing.  They say it's designed to work with a normal network, not an enterprise network (their words).

I haven't changed anything on the firewall in a long time, but I *HAVE* kept up on firmware updates.  In fact I just upgraded to 21.7.2.

My question is...  Did something change in the last, lets say, 6 months, that would affect this?  Is OPNsense now able to detect an arp spoofing / IP takeover, and somehow prevent it?  Can I disable that on a per interface basis?

Many thanks,

-msturtz-

Sweet, thank you! 8)

Hi, I found something about this in a very old (2017) pfsense forum post, but I'm not finding it here.  I wanted to find a way to keep track of how much bandwidth *transfer* has occurred, month by month -- my provider has a data cap, and it would be nice to know how close I am to it, and how closely my statistics match theirs, along with some historical data to compare with.

Is there an easy way to run a report that shows transfer, rather than throughput?  Seems like this would be a popular feature.