Messages

Can you share your config?

# pluginctl -g dnsmasq

and the error?

# opnsense-log | grep returned.exit.code


Cheers,
Franco

Got it resolved.
The domains tab had one entry where instead of IP address, exclamation character was listed. Replaced it with IP address and Dnsmasq now starts properly.

I encountered the same error. In the previous versions, one could enter ! As a valid character, but during import on 25.1.2, dnsmasq fails to load.

However, the GUI in 25.1.2 still supports entering the character ! (Instead of leaving it blank), but does not show the ! Character after saving. It is a bit confusing...

I think the help text on dnsmasq domain GUI page could be modified to reflect this new behaviour.

Hi. I hit this pretty crippling bug after upgrading

I concur with user gspannu. The solution for me was to edit every line of the domains tab that included the exclamation mark, and save it without any change. That removed the ! character from the domains tab and allowed dnsmasq to start

When editing, removing ! does not work bc an empty field is not allowed. Replacing ! with a blank allows saving but I did not check if dnsmasq would work in this case

The help tips are not in line with what's required of the user

Thanks to all!

Instructions still directionally correct in OPNsense 23.7.8-amd64 :)
Not using the new "Instances" facility to create the openvpn service, though. Perhaps that new GUI changes things?

EDIT. Actually a quick glance at "Interfaces" tells me neither bridged mode nor site-to-site shared key seem to be supported for now. Hoping the new GUI will improve.

First off I want to say I enjoy OPNsense 22.7 on PCEngines APU2 tremendously. Thank you, all.

I have recently setup OpenVPN on a gateway (found your howto mostly fine) for the usual remote admin use-case. Works a treat.

I am now setting up another VPN instance for peer to peer collaboration between road-warriors. In this case I only rely on certificate-based authentication as I don't really care for creating an unprivileged user in the router for each roadwarrior device.

I would have liked to be able to define in addition an OTP seed for each certificate and use it as password; akin to creating a local user with an empty password+its OTP seed, but bypassing the worrying passwordless user account aspect.
I remember having done that on Linux with the right PAM options.
I believe, requiring an OTP code is manageable even in almost batch setup (nowadays I tend to put VPN clients in containers if I can), and nicely enhances security in case of laptop theft, for example.

Do you think this makes sense? Any takers for this kind of setup besides me?

[add/modifiy on firewall rules (on server side) for _LAN IPv4 any to any]

Hi there.
I think this semi-recent addition to the old how-to might be of importance (emphasis mine):

still ok on 20.7.1
just add/modifiy on firewall rules (on server side) for _LAN IPv4 any to any because default rules are with : Source _LAN net, and _LAN has no address  ;)

I haven't setup a bridged VPN on OPNsense 21, so perhaps something else needs to be done?

I was playing w/ CARP yesterday and saw just that on a VLAN interface, except in my case both router instances thought they were master.

That was using an iffy virtualbox network, I thought VLAN was not supported somehow, but apparently the problem might not be with VB.

The interface itself worked ok and the sync link as well, no issue with other  "native" interfaces.

Hi all.
I've been asked to look into an IPS for a small Lan.

The need is for an active type of thing that would block traffic. I imagine the platform needs to to be installed behind the router, running the IPS process over an anonymous bridge, correct?

Do you think a gen-9 Poweredge running OVPN, with 2xDual Core 51xx Xenon, and the dual broadcom NetxtremeII Gigabit ethernet interface can be a good (transparent) platform?

Thanks in advance for your advice.

I can't say much, I don't understand what's going on.
I have raised a topic on this, Franco had a look and it has gone quiet. I hope the OPNsense guys have an interest in testing such a config and will sometime confirm/infirm the bug.

What does not work:
- assign a vlan, say igb0.66
- assign any other interface, say tap0
- assign a bridge with igb0.66 and tap0
What happens: machines on igb.66 get an IP address and then cannot communicate with tap0 and beyond. They can communicate with each other IIRC.

What does work:
- Replace igb0.66 with a native interface, say igb2
What happens: machines on igb2 get an IP address and can communicate with tap0 and beyond.

If you have a leftover physical interface on the router, try to dedicate it to the telephone network.
Otherwise, let me know how to make a VLAN work in this configuration!

Cheers

[NB: not a VLAN it does not work AFAIK]

A quick follow-up, here is the recipe for a site-to-site bridged config.
The idea is to let the router on site A manage site B completely, esp. via its DHCP server. This is why none of the special OpenVPN options related to client management are used (IP pool, Bridge settings...)

The motions you'll have to go through will be more accurately described in the FP, but basically this is the workflow for both sites:

• Create a bridge, assign an interface,— NB: not a VLAN it does not work AFAIK
• Create your OVPN client or server config, select tap and your options,
• Activate the created ovpn<s|c><number> interface and assign it to the bridge, (ovpncX = client tap #X, ovpnsY = server tap #Y)
• (Re)Start the OVPN instance,
• Check your filtering rules.

Make sure your IP setup does not conflict across sites, you're on a single network.
In this example you just need to configure the DHCP server on site A, but in general using a 172.16/12 or 10/8 network for your sites can make management easier.

Now the OVPN settings for a site-to-site static key setup.
The following setup should work as-is with net.link.bridge.pfil_member=0 and net.link.bridge.pfil_bridge=1 set in System>Settings>Tunables
If you don't set these, you'll need to define filtering rules per bridge member interface. This was not tested, you're on your own.

• Server side
  On site A router, go to VPN>OpenVPN>Servers, click on "Add server".
  Here are the main options you want to set:


• General info:
  Server Mode: Peer to Peer (Shared Key)
  Device mode: tap
  Interface: <your WAN interface>
  
• Crypto settings:
  Shared Key, select "Automatically generate a shared key."
  Encryption, Auth, Hw crypto: YMMV, I suggest you start with the defaults.
  
• Tunnel Settings:
  Everything empty, except:
  Compression: Select "Enabled w/ Adaptive Compression" (whatever you choose, make sure both sides match)
  Type-of-Service: selected. Both options mildly useful but they don't hurt AFAIK.
  Yes, bridge interface is set to "none". The DHCP server on site A manages the network.
  
• Client settings:
  All empty. Uncheck Address Pool.
  
• Advanced:
  dev tap
  persist-tun
  ifconfig-nowarn
  ping-timer-rem
  
Now Save, assign the ovpnsX interface to the bridge, restart the OVPN server. It should go green.
Check your incoming filtering rule on the WAN interface to allow the client to connect. BTW, prefer udp rather than tcp for the tunnel, tcp-over-tcp can cause more issues than it solves.
Go back to the server configuration and copy the generated key. You'll need to paste it in the client config.

• Client side
  On site B router, make sure the DHCP server is deactivated on the bridged interface.
  Then go to VPN>OpenVPN>Clients, click on "Add client".
  Here are the main options you want to set:


• General info:
  Server Mode: Peer to Peer (Shared Key)
  Device mode: tap
  Interface: <your WAN interface>
  Remote Server: <public IP or name of site A>
  Retry DNS resolution: check "Infinitely resolve remote server"
  
• User Authentication Settings: leave empty
• Crypto settings:
  Uncheck "Automatically generate a shared key.", then paste the key that was generated on the server side. (or your secret won't match)
  Encryption, Auth, Hw crypto: if you changed anything to the default, check you match settings on the other side.
  
• Tunnel Settings:
  Everything empty, except:
  Compression: Select "Enabled w/ Adaptive Compression" (whatever you choose, make sure both sides match)
  Type-of-Service: selected. Both options mildly useful but they don't hurt AFAIK.
  
• Advanced:
  dev tap
  persist-tun
  ifconfig-nowarn
  
Now Save, assign the ovpncX interface to the bridge, restart the OVPN client. It should go green.
Check your filtering rule on the bridged interface. You can open IPv4 any to any and set the gateway for that rule to the automatically generated <ovpncX_name>_VPNV4 gateway.
If you create a schedule (Firewall>Settings>Schedules) you can activate/deactivate the rule according to time-of-day.

You now have a single LAN spanning over 2 sites, congratulations.

Yes I think it's broken in BSD. I've had the same issue in 17.17.12 and 18.1.6?, a tagged interface doesn't really work in a bridge. Non-IP traffic works (eg a DHCP lease) but L3 is dead.
Doesn't look like a new problem, and doesn't look like it's OPNsense-specific.

I'd like to be wrong, though.

What part of the linked tutorial is unclear?

About the post in the how-to section about tap, at the beginning it is written that "this works for peer-to-peer mode as well" So in that case, I have to do the same bridge on the distant server no ? And the mode server is useless ?

I suggest you stick to the how-to and then derive your own config. "server mode" is fine even for site-to-site.
EDIT: I've  added a recipe for site-to-site in the howto thread.

The other day I used a pair of 17.7 (also works on 18.1) to setup a bridged site-to-site link. This one uses a shared static key, no problem with expiry dates and time-of-day. There is a server bridged as in the howto, there is a client bridged in the same way on the other side. (in ovpn parlance this is p2p mode, "server" is the side that listens passively, "client" is the side that actively calls)
In the "Advanced" field, choosing the right options is a little bit tricky, because your GUI settings generate options/values, and what you want to add in Advanced is options that complement or override, but not clash with the generated ones. OTOH you want to have "dev tap" and "preserve-tun" in the Advanced field on both sides.

BTW If not said before: I don't see the need for a DHCP relay since with bridging you're on a single subnet... If the link is too poor for DHCP leases req/offers to reach the intended targets, filter out the eventual incoming responses from the remote server (you can't filter out outgoing queries I think) and start another authoritative server on the local router. Make sure your IP lease pool does not clash with the one on the other side. It's all the same network.

And no, bridge member interfaces do not have an IP config. Only the bridge has an IP config (or none if you want a transparent bridge.)

FYI, still ok on 18.1.

DHCP uses 67/udp and 68/udp.
If a server receives a request (on 67/udp) you should see it in its logs.
If the local firewall blocks the server response (on 68/udp) you should see it in OPNsense logs.
Perhaps that traffic is classified as bogon, enable logging on anti-bogons rules.

I really think it's hosed.

Bridge 1 on IGB1, no VLAN: DHCP and ping works for clients (192.168.1.0/24)
+ add VLAN 20 on IGB1, give it an IP: DHCP and ping works for clients (192.168.5.0/24) -> switch config is ok.
- unconfigure IGB1.20
+ make IGB1.20 a member of Bridge 2, give the former IP config to Bridge 2: DHCP works for clients (192.168.5.0/24), clients can't ping or communicate with the router. Router can't ping client.

I ran a tcpdump and IGB1.20 does receive traffic. There is never a reply so I suppose the traffic vanishes past IGB1.20
Unlike linux it's not possible it seems to attach a VLAN ID to the bridge itself, so I couldn't try that.

Hiya Franco,
Agreed those pesky PVIDs and tags can cause problems... I think I will check again but I'm pretty sure it's not a switch setup issue.
The thread I wanted to refer to is not so old in fact: https://forum.opnsense.org/index.php?topic=3753.msg13804#msg13804
Unlike the OP I did not take the time to tcpdump the traffic.
There isn't heaps of bridge/vlan bugs opened in FreeBSD, but I'm not sure my case relates to one.

Anyways, if I check again and find my switch setup was faulty, I will post an update here.
Thanks!

As an aside to my previous question, I have noticed on both 17.7.12 and 18.1.6 that a strange gateway is created by OPNsense when using a client tap OpenVPN deamon bridged to an anonymous (no IP) bridge.

The thing is called "OVPN_VPNV4 Gateway" (or VPNV4 Gateway?) and I have no idea which purpose it serves.
I tried deleting it and it comes back stubbornly in the list of gateways. Since it is created, renaming it is not possible either.
However it is possible to disable it, which hides it from the Dashboard. That's what I elected to do.