Messages

1

24.7 Production Series / Re: Is my WAN IPv6 different from my /48 fixed prefix?

« on: Today at 01:57:01 pm »

Interesting. So I could use any interface IPv6? Probably then have to adjust the "Allow all UDP on Port 51820 to WAN address" rule, since the destination isn't WAN address anymore. Since I wg Interfaces are not allowed to have IP settings, I probably need to create a fake Interface which is ok, but not very sleek in my opinion.

The incoming interface would still be WAN. The destination address could be "This Firewall", which could cover any routable address.

The /128 on your WAN interface is probably from DHCPv6, and the /64 one from SLAAC, I'd guess....

That was my guess too.
Do you think both are publicly routable?
I tried both of them, but was not able to establish a connection. Maybe some other config error on my part.

Assuming they're from a routable prefix, I would expect so. Maybe try to get ping working before WG? https://tools.keycdn.com/ipv6-ping can be quite handy....

2

24.7 Production Series / Re: Is my WAN IPv6 different from my /48 fixed prefix?

« on: Today at 10:41:07 am »

It's normal for your WAN interface to get an IPv6 address outside your delegated prefix. The delegated prefix is inteded for your router (firewall) to use for internal networks behind it. Is the /128 address on your WAN interface not static too? If it's not, you could use the address of one of your other interfaces as the destination for WG instead. The /128 on your WAN interface is probably from DHCPv6, and the /64 one from SLAAC, I'd guess....

3

General Discussion / Re: How to Resolve Local Client Names with opnSense

« on: December 02, 2024, 06:05:05 pm »

If you want it to be predictable, the usual practice would be to use DHCP reservations for your important hosts, and configure OPNsense to register those reservations with the Unbound DNS service, then you can use names like "mypc.localdomain" (or whatever you choose "localdomain" to be  - "lan" is fairly common). Dynamic DHCP leases can be registered with Unbound too, but you're dependent on the client requesting a meaningful hostname....

4

24.7 Production Series / Re: State tracking issue with OPNsense in single-interface public IP setup

« on: December 02, 2024, 04:37:56 pm »

There's a state tracking mode called "sloppy", which https://man.freebsd.org/cgi/man.cgi?pf.conf(5) describes as:

"       sloppy
        Uses a sloppy TCP connection tracker that does not   check sequence
        numbers  at  all, which makes insertion and ICMP teardown attacks
        way easier.  This is intended to be used in situations where  one
        does  not   see  all  packets  of a   connection, e.g. in asymmetric
        routing situations.  Cannot be used  with   modulate  or  synproxy
        state."

TL;DR the conversation above, so not sure if it fits for you, but it is an option for rules in OPNsense.....

5

General Discussion / Re: Transparent Bridge - How to get Internet Access On Additional OPT Port?

« on: December 02, 2024, 01:39:45 pm »

OPNsense can do Wireguard with policy-based routing (allowing you to control what goes through the VPN) - https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html

It can also do DHCP host reservations - https://docs.opnsense.org/manual/dhcp.html#reservations

I understand you're frustrated right now, though. Maybe revisit it after cooling off a bit?

The double-NAT method using your management interface should work, I think, asuming the work hosts only need to connect outbound, but it's a bit convoluted IMO.

6

General Discussion / Re: Transparent Bridge - How to get Internet Access On Additional OPT Port?

« on: December 02, 2024, 10:43:13 am »

The transparent filtering bridge model that you've implemented is for one network. You're trying to add a second network ("work"), but your Asus router (which is currently handling all routing) is not setup to route that second network. If you want to keep the transparent filtering bridge model, you'd have to add the second network to the Asus router, and somehow deliver it to OPNsense (perhaps VLANs) and then build a second transparent filtering bridge on OPNsense for it.

I suppose you could do some sort of combined approach, where you keep your transparent filtering bridge for LAN, but add a routed "work" network. If you do that, you'll have to route to the internet through your management interface, and you'll also have to enable your Asus router to route back to your "work" network. That means either a static route on the Asus router (pointing to your management interface's IP address), or you could do outbound NAT on OPNsense for the "work" network, which means double-NAT (because the Asus is doing NAT too). That may be OK in your situation. If you're not doing NAT on OPNsense, the Asus router would need to do it (for the extra routed subnet) - I don't know off-hand if it would do that.

What is your motivation for keeping the Asus router, as opposed to having OPNsense handle routing, DHCP, etc?

7

General Discussion / Re: spokes can't reach to each other through opnsense in the hub

« on: December 01, 2024, 02:53:35 pm »

It's not really clear what you're trying to accomplish - e.g. is there an actual WAN here, or are you using the WAN interface as an additional LAN? I'm not familiar with Azure, and don't know what a "VNet Peering" entails, but your network design doesn't look right. You have a host on subnet 10.13.1.0/24 and a route supposedly pointing to 10.1.1.250, but that's on a different subnet, so what's in between? You have the same next hop (10.1.1.250) on the other side, but that side of your hub is 10.1.0.250 ...

8

General Discussion / Re: spokes can't reach to each other through opnsense in the hub

« on: December 01, 2024, 01:20:02 pm »

10.13.1.4 is not part of 10.1.1.0/24, so it will take the default route, which is the gateway associated with your WAN interface. You'll need an additional "LAN" interface for "spoke3"

9

General Discussion / Re: spokes can't reach to each other through opnsense in the hub

« on: December 01, 2024, 12:42:09 pm »

Your LAN interface can't be both 10.11.1.0/24 and 10.13.1.0/24. You'll need two separate interfaces. You haven't shared any information at all about how OPNsense is configured, so we could only guess...........

10

24.7 Production Series / Re: [Solved]Floating Rules Missing under Firewall / Floating

« on: December 01, 2024, 11:22:01 am »

Yes - I still believe it's related to you having so many interfaces that the popup menu can't fit on the screen (the scrollable part of the web page, excluding the banner at the top). I can reproduce it by creating some fake interfaces, and making the browser window small...

11

24.7 Production Series / Re: Floating Rules Missing under Firewall / Floating

« on: November 28, 2024, 06:44:33 pm »

Unless the screenshot is cropped, it appears that you have so many interfaces that the menu can't fit on your screen? Can you get to https://<your_ip>/firewall_rules.php?if=FloatingRules ?

12

24.7 Production Series / Re: multiple wireguard instances not routing

« on: November 28, 2024, 05:11:51 pm »

If your intent is to have each LAN use a different VPN, you probably want to use the "Disable routes" option for your WireGuard instances, and use policy-based routing. https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html for the general direction....

13

24.7 Production Series / Re: Floating Rules Missing under Firewall / Floating

« on: November 28, 2024, 04:56:31 pm »

I don't see any picture? Don't know why it would be missing, though - anything in System ->? Log Files -> Web GUI ?

14

24.7 Production Series / Re: Floating Rules Missing under Firewall / Floating

« on: November 28, 2024, 04:18:57 pm »

If you're looking for Firewall -> Floating, you won't find it - it's Firewall -> *Rules* -> Floating ...

15

24.7 Production Series / Re: I botched my Certificate (self made outside of opnsense)

« on: November 28, 2024, 01:49:18 pm »

I suppose you could try editting /conf/config.xml , but at your own risk!

The cert is referenced at opnsense -> system -> webgui -> ssl-certref, and you should find the actual cert (and its private key) in the config too (search for that reference). If you still have the original "Web GUI TLS certificate", you probably could plug in its reference, then "Reload all services" from the login menu, or reboot. Alternatively maybe you could temporarily set opensense -> system -> webgui -> protocol to "http", then repair via the web UI on port 80....