Messages

Had the same issue so really grateful for this. However, bash doesn't seem to be installed by default and I didn't want to install it specifically for this so implemented the same capability but slightly differently (more inline with the example in the docs looking back).

Monit:
1. Service settings:
Add test:
- Condition: failed ping4 count 3 with timeout 3 seconds for 2 cycles
- Action: Restart

2. Add a service:
- Type: "Remote Host"
- Address: <the WireGuard server's IP address>.
- Tests: <the defined ping test>
- Start: /usr/local/opnsense/scripts/Wireguard/wg-service-control.php start <wireguard instance uuid>
- Stop: /usr/local/opnsense/scripts/Wireguard/wg-service-control.php stop <wireguard instance uuid>

Achieves the same result but without installing bash - keeping my fingers crossed it works! But thanks again, your post was a real help.

Could also be worth looking at your bufferbloat scores; mine were Ds until I modified the pipes: https://maltechx.de/en/2021/03/opnsense-setup-traffic-shaping-and-reduce-bufferbloat/

I reckon I cracked it. My MacBook was picking up a DHCP address when in bridge mode so I wiresharked it and copied the DHCP option 55 request options over to opnsense and it worked. What it needed, this is Vodafone LTE UK, is:

option subnet-mask,static-routes,routers,domain-name-servers,domain-name,domain-search,netbios-node-type,netbios-name-servers

Just in case it's of help to anyone else in future

@Greg_E would you mind setting up a packet capture on that interface, forcing a reconnect and posting the results so I can compare with what I'm getting? I'm wondering if it's a nuance of the modem that opnsense isn't happy with.

First time poster, long time lurker!

I've got an LTE modem that can operate as a router or as a bridge. As a router it works on the 192.168.5.0/24 subnet and I can hook it up to opnsense no probs to get a WAN interface (but it's double NATing which is messy).

Put it in bridge mode and it connects to my MacBook fine and they DHCP negotiate a Vodafone class A address for the machine in the 10.0.0.0/8 range which I can use to hit the internet (public IP becomes a generic 148.x.x.x address that Vodafone has when I hit ipify).

Connect it to opnsense in bridge mode and it just will not pick up a DHCP address. Wiresharking the traffic the modem/cell network is ARPing that it is 10.65.147.1 and is asking who-has 10.65.147.X, for example.

Opnsense ignores this and puts out a DHCP Discover message asking for an IP address of 192.168.5.X which is rejected by the modem/cell network as being on the wrong network, which makes sense.

The snag is that opnsense seems to completely ignore the modem/cell net ARPs and can't get itself out of the 192.168.5.0 range to even think about issuing a DHCP Discover in that range and so never successfully negotiates an address....the two just chirp away at each other endlessly, opnsense issuing DHCP discover messages, initially in the wrong range and then subsequently just MAC based, and the modem just throws out ARP who-has messages that get ignored.

I can't work out why opnsense is so stuck in that range....private networks on the WAN interface aren't blocked, I've flushed the ARP cache and even tried it on a separate ethernet port but it has the same behaviour. I don't think it's firewall rules as I can see ARP traffic and DHCP traffic and have searched my config XML for anything that might tie my WAN interfaces to the `192.168.5` range, all to no success.

Is this something I need to force via DHCP lease options or is there a glaringly obvious something that I've missed?!