Messages

1

22.1 Legacy Series / Re: After update, problems with LAN/WAN Interfaces

« on: November 16, 2022, 07:05:29 pm »

Have you ever figured this out? Exact same scenario is happening here. Sporadic outage with LAN and all devices lose access to the network. Interestingly, in my case I have LAN1 and LAN2 interfaces. This is only happening with LAN1. LAN2 stays active and those devices connected to LAN2 continue connecting. I am not sure if it is related at all but the only difference between LAN1 and LAN2 setup in my case is that some LAN1 traffic is routed to a site-to-site Wireguard VPN bridge to the IPs in my other home. This is done via LAN1 firewall rules.

Reboot of the OPNsense fixes it for about 24 hours. 

2

General Discussion / Question on "This Firewall"

« on: March 04, 2022, 08:24:16 pm »

I have a four-port OPNSense box. two WANs and two LANs. LAN1 should access everything, LAN2 should only access LAN2 and both WANs but not LAN1.

LAN2 interface has the following rules:
1. Allow all inbound if destination is NOT "This Firewall" (meant to allow WAN traffic)
2. Allow all inbound if destination is LAN2

Yet, a PC attached to the LAN2 port can ping another PC attached to LAN1. Why is that?

3

General Discussion / Re: UDP Broadcast Relay

« on: October 15, 2021, 09:34:03 pm »

First, THANK YOU!

I have two homes, both running OPNSense. Site-to-Site WireGuard VPN. Both sites have their own respective LAN and WG interfaces set up. Both sites have gateways set up for the WireGuard traffic (GWs are required and must be designated as "Far Gateways" for selective routing). FW rules on both sides allow all from their respective WG interfaces. Both sites have "Disable Routes" enabled in the Local Configuration; all routing is selectively handled via firewall rules based on either source or destination IPs. Outbound NAT is set up on both sides to assign the WG interface IP to outgoing packets. Endpoint Allowed IPs on both sides have 0.0.0.0/0.

So far, all the discussions in this forum pertain to relaying UDP broadcasts across multiple VLANs. Is there any reason why this wonderful plugin would not work when one of the interfaces is a VPN interface, and specifically WireGuard? Is there any specific configuration needed to make it work? 

Also, why do some relay setup lines appear in yellow (vs. Green) in OPNSense? Yellow ones show their services inactive on the dashboard. I assume incorrect configuration of some sort but can't tell what is wrong with them.

4

Virtual private networks / WireGuard Site-to-Site selective routing setup changed after the recent upgrade

« on: September 01, 2021, 02:09:06 pm »

I have two sites (Site A and Site B) both of which are running OPNSense with a site-to-site WireGuard tunnel. Site A has selective routing set up to route all traffic from a subset of LAN clients to use the WG gateway. Site B doesn't need selective routing; WG is only needed to access LAN clients at Site A and all other outbound traffic uses WAN. The setup is done per these instructions https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html (with some trial and error modifications) and it works.

In order to make this work, the instructions above state you have to "Disable Routes" in Site A's local peer. For Site B, it is not needed because WG creates its own routes for the allowed IPs stated in its Endpoints setup.

I did all this and everything works. However, after I upgraded both firewalls to 21.7.1, I noticed the upgrade activated the "Disable Routes" setting at Site B. Puzzled, when I tried to uncheck and save, OPNSense said "You have to enable Disable Routes option". Yet, when I look under Site B's Routes -> Status, I see the appropriate routes set up, possibly remnants of the routes that were previously created when the option was set to no.

Why would that happen?

5

Virtual private networks / Re: Route DNS queries over WG VPN client connection

« on: September 01, 2021, 01:46:08 pm »

I have the same selective routing setup on OPNSense using WireGuard. I have two sites. Selective routing is happening at Site A. Site B has another OPNSense server that I own. So, it is a site-to-site setup. But Site B could have been a commercial VPN service provider and it should work the same way. Here is what I recommend:

1. Set up a port forward rule (Firewall -> NAT -> Port Forward) that redirects all packets sourced from your LAN clients that should be using WG (you created an alias for those) with a destination port of DNS (port 53) to the target IP of your VPN service provider's tunnel IP. This isn't the tunnel IP you set up on your OPNSense VPN -> WireGuard -> Local; it is the tunnel IP they have on their side. If you don't have it, ask them.   

2. Set up an outbound NAT rule that translates your source IP to the interface address of your WG interface. When the traffic (including DNS) originating from your LAN clients that should be routed to the WG gateway pass through your WG tunnel, this outbound NAT rule will override the source IP to the IP address of your WG tunnel IP so that when your VPN provider responds to your packets, OPNSense knows which client to route it back to.

3. Add your VPN server provider's public DNS server IP to System -> Settings -> General -> DNS Servers (select your WG Gateway under "Use gateway" (your VPN service may be requiring inbound DNS requests coming to their DNS server to be encrypted via WG; not sure but it would explain the behavior you are seeing). Also on this page, "Allow DNS server list to be overridden by DHCP/PPP on WAN" may or may not need to be unchecked depending on your circumstances.

4. Set up a static route (System -> Routes -> Configuration) and add a rule that forces traffic to the specific IP address of the DNS server you want to use for your WG clients to the WG Gateway.

5. Set up (which you probably already have) a quick LAN pass rule that sends all traffic originating from those LAN clients that are supposed to go through WG to use the WG Gateway. 

This configuration works in my case.

6

General Discussion / OPNSense with downstream Google Nest

« on: February 26, 2021, 12:57:16 am »

For some reason, the (or some) inbound traffic at my OPT1 port is blocked by the firewall "Default deny rule".  OPT1 is connected to a Google Nest Wifi Router. This router is handing out its own LAN subnet IPs to connected wireless clients.

Firewall log for OPT1 shows many blocked entries from the IPs that are on the LAN side of the Google Router, which I would expect to be invisible to OPNSense. But they are not.

SETUP:


AT&T GW -> OPNSense WAN

OPNSense LAN -> Dumb Switch -> A bunch of wired devices & an Orbi in AP mode
All devices here have 192.168.10.0/24 served by the OPNSense LAN DHCP - This piece works fine.

OPNSense OPT1 -> Google Nest Router
192.168.15.10 is the IP OPNSense gives to the Google router
192.168.86.0/24 is the subnet Google passes out to its LAN clients

I have allow-all-inbound-OPT1 FW rules set up in both on the Floating and OPT1 tabs (did that also for LAN)

Still, I see a bunch of the following block entries in the FW log:
Interface: OPT1
Direction: In
Source: 192.168.86.n or 192.168.15.10
Destination: Various WAN IPs
Proto: TCP
Label: Default deny rule

Not sure if it is related, but I see some blocks on the LAN port too but far fewer. I have the same allow-all-inbound rule on LAN. 

Thank you for taking the time.