Messages

Sorry for the necro, just wondering if anyone has been successful booting OPNsense via iPXE?

Same thing happened to me just now on two separate OPNsense instances, upgrading from 22.1.10_4 -> 22.7_4.

https://github.com/opnsense/plugins/issues/2759

Hi there,

Looks like there is a cap on the amount of WG local configurations you can create in the UI (20).
The following error is reported if you attempt to create any more:
Maximum number of instances reached

It appears this limit is enforced here:
https://github.com/opnsense/plugins/blob/f8f3975e00560425bd1de3136320d181a83e4f84/net/wireguard/src/opnsense/mvc/app/models/OPNsense/Wireguard/Server.xml#L20

Just wondering why this limit is so small or fixed at all?

OPNsense 21.7.7
os-wireguard 1.9

Regards,
Adam

Thank you very much Obeng for putting that together, it is working like a dream now.
The issue I had was having the "generic" WireGuard interface with an allow all rule, a WG tutorial I read mentioned that the rules only work on this generic interface, not the individually assigned interface per WG tunnel.

Once I swapped the rules over everything worked.

Thanks again for your help.

Looks like FRR was broken.  An update was just released, upgrading to 21.1.6 has fixed the issue.

https://github.com/opnsense/plugins/issues/2314#issuecomment-851009622

Check the firewall rules for the generic interface called "WireGuard", this needs to allow traffic, will drop traffic running over the tunnel by default.

Hi Mantis314,

I have p2p links set up with IPSEC, currently on 21.1.5.
Make sure you have "Install policy" unchecked in Phase 1 setup, it should create a virtual interface for you.
Then under Interfaces -> Assignments you should be able to provision it as a proper interface then, and after that the interface should appear in the list when creating the gateway.
Note, you may need to restart the IPSEC service after assigning the interface as I find with OpenVPN and Wireguard links, the interface assignment clobbers the already running IP address allocation that the vpn service configured on the interface.

If this isn't the source of your issue, I can share some of my config for you do compare with if you like.

Regards,
Adam

Sorry if this is obtuse (me not understanding fully) - would it not be easier to use a block policy for all DNS with logging enabled, and whitelist the correct servers (also logged)?  Or if you must let the traffic pass log everything DNS with a inverted destination maybe of not your good DNS servers (via alias) or something similar.  NAT seems to be complicating it a bit from what I can tell.

(sorry if it is obvious) - do your clients support option 33?

Definitely agree with @kya.
You need to use something like VirtualBox / VMWare / KVM / Parallels etc to create an image. You need to configure everything perfectly, WAN interface, serial console output etc, be ready for 1:1 NAT that AWS puts on you with the public addresses / EIP.  Create an EC2 instance with the same disk size, use dd with ssh to copy your image over to clobber another EBS volume to boot off.  Horribly painful to get everything lined up without days of effort.  I ended up paying for the AMI from Deciso which saved me a lot of grief, well worth the cost.

If you aren't required to use AWS, look at Vultr or Linode or most other VPS providers which allow you to use a graphical console, so you can just install away as if it was local and get it running without fuss.

Have you tried policy routing, a firewall rule to match the source address, and then select the gateway to use down the bottom of the form?

An outbound NAT rule on the LAN interface when the destination is the graphite server, to replace the source address with the interface address.

This looks like an asymmetrical routing issue.
As the VPN client source address is in a different subnet to 192.168.1.0/24, the response packet of the ping will need to use it's assigned gateway, which is 192.168.1.1, which won't know what to do with the source address of 10.10.0.1.

I guess the mask must put it back to 10.204.0.0, but takes precedence because it is still more specific than the original 10.204.0.0.