Messages

It should, you just assign an IP (alias if need be) on its "WAN" side, but as I said, your setup will break incoming connections if it flaps all over the place with regards to your external IP.

What the first rule of your NAT does: Take any packet from .100.0/24 (in which your cable modem is included) and translate it to .100.(OPNSense WAN IP). That's what's breaking it.

First rule on my list  ;)

Switch NAT to automatic, you don't need any manual rules. No you don't. Still don't need them  ;)

Problems and why it will not work:
1) Your subnets are messed up. Different subnets on different interfaces. Rule, set in stone.
2) Don't use any other subnet other than /24. Ever.


that being said:
There are two scenarios you could follow:
1) OPNSense in filtering bridge: No IPs are needed internally (the bridge doesn't "exist" on the network), no subnets.
2) OPNSense in routing: double NAT, which depending on what you are trying to do could involve the ISP's modem cooperation to work.

How is the ISP's "external" IP being handled? Does your ISP route your external IP over both connections in a round robin fashion, or is it more like a failover, ie. DSL goes down, everything switches to LTE?

In "round robin": Your ISP is handling everything, you shouldn't have any issues. This includes a special failover scenario where the DSL goes down, your ISP automatically routes packages over LTE, without your external IP changing (BGP style)
in "pure failover": Your external IP changes when links flap, which will break any VPN tunnels you are trying to use (except wireguard (=client side on OPNSense only), but I wouldn't recommend it in production use yet). Your established tunnels have no way to know that your ABC IP changed, so they can't find you since now your external IP is XYZ.

Double NAT isn't an issue, assuming everything else is handled correctly (I doubt the ISP's modem is smart enough to know that states apply to both connections, so everything *isn't* handled correctly, guaranteed, I can offer a signed contract in my blood for this). Even if everything is set up as it should on your ISP's side (up to the modem), then the modem itself will break your tunnels since it will not be able to figure out that states for "incoming connections to port 1194 apply to both connections, so this packet that suddenly showed up on LTE is actually an answer for a packet on DSL".

TL;DR: What you are trying to do isn't going to work. It *may* work for a day or two, but will eventually blow up. What I would recommend is (if you **actually** need failover) is to get your ISP to add you to their "BGP style" routing, with you being able to push updates to them (and use a bat to convince them that you should only push updates for *your* IPs, not mine). This usually comes with a mandatory couple of zeros after the montly price, so back to square one: Set everything up as you normally would (see first paragraph for my comments) and don't worry about the link going down. Or set up two VPN instances and tell your users when A isn't working, disconnect and connect with B.

Unless the modem is configured in a "bridged" scenario (ie PPPoE on OPNSense), no other configuration is needed on OPNSense to access it.

If it's a double NAT scenario (which contrary to popular belief doesn't break *any* service, PAT does), and OPNSense has an IP in the modem's LAN subnet (ie gets it's IP directly from the modem/you have manually assigned an IP to OPNSense's WAN in the modem's LAN subnet), then it's routing 101: You are looking for the modem's IP, OPNsense answers "I see that IP, let me handle your packets for you" (=what a router does), you get connected, everything works.

Why it will not work:
1) you mess up with the outbound NAT rules.
2) you are blocking private/invalid on OPNSense's WAN
3) there isn't any rule that allows it (there should be, the default allow LAN to any, assuming you are connecting from OPNSense's LAN interface)
4) your modem is bridged, possibly using a specific port for the bridge, while leaving the rest as a "local tech support" access. ie port 1 is bridged, port 2+3 are not, port 4 is for a VOIP setup.

Works with cable, DSL, dialup, postal pidgeons, star trek communicators  ;)

Had to login just to post this reply:
I've been here since the very beginning (that's *days* after the project was started). I've used OPNsense in every imaginable configuration, from PPPoE connections to routed connections, to load balancing connections, to E-V-E-R-Y---S-I-N-G-L-E configuration that there is out there. LANs, WANs, Guest networks, DMZs, satellite, carrier pidgeon links, EVERYTHING. That's why my post count is so low, I literally have zero problems with the product, using it over the span of a few years since its initial creation, in multiple installations, both for myself and clients.

I always set up unbound as a full resolver (I have to get my DNSEC fix (not the bug kind, the snort-up-the-nose kind of fix)): zero problems, never seen unbound fail, even when pushed by (literally) hundreds of clients.

I always set up suricata in IPS mode: absolutely zero problems with suricata, except one single occasion where an Exchange server was corrupting PDFs (it's a Microsoft product: what, do you expect it to work? Have you heard the other one about the chicken crossing the street?). Not really an OPNsense issue, is it?

Never had a problem connecting with openvpn. If you are using any kind of other vpn, you are holding it wrong. When I click that mouse button, the tunnel is set up and I start working. Every single time.

I use two different DDNS providers, never had a refreshed connection fail to update to either one. As a reminder: over a combined number of multiple installations at clients' offices.

Having an IP conflict and complaining that the product is "ZOMG!!!11oneeleven BROKEN" is like driving your car off a cliff and expecting your ABS to save you on the way down  ;-)

Life may seem difficult and every piece of software you are using may seem as if it was specifically written to make your life a living hell. Both of those statements could not be further from the truth. When things aren't working, always start troubleshooting from the beginning and work your way towards the problem's solution.

To the er...guy that mentioned every day problems: I've been here long enough to remember a product that fits that exact description. Installations failing to boot up after a regular update (not even major updates), the firewall deciding in the middle of the day to stop routing packets because why not, etc... The other "oldtimers" remember it as well, do you? ;-) Hint: it rhimes with OPNsense, but I can assure you it most definitely isn't OPNsense.

Το χρησιμοποιώ από τις πρώτες μέρες που έγινε OPNsense ;) (ναι, είμαι από τους παλαιότερους εδώ)

Με τι χρειάζεσαι βοήθεια;

@franco The fact that I don't post doesn't mean I'm not here, it means the product has been rock solid for my use cases :-). This is the first "serious" issue that I have seen, and it did not even apply to our entire fleet of appliances. Only appliances that were behind bridged modems were actually affected by this, because PPPoE is handled by opnsense, instead of PPPoE being handled by the modem if it is in routing mode.

Tried the 17.1.x to 17.7 upgrade, upgraded smoothly, although it did take a while to come back and gave me a slight scare there :-). It then found the 17.7.1 upgrade and sailed through that as well  ;D

@JDtheHutt every software has bugs, and this bug as far as I understand it wasn't in opnsense, but upstream. I've been running opnsense since day 0. I actually had to reconfigure one of our routers because it was upgraded from a 32bit machine to a 64bit machine and wanted to "start fresh" with it. I had to skim through the old configuration, it was *that* long that I had to fiddle with it that I forgot how it was configured (subnets/interfaces). So far, since day 0, it was always use>update>use, didn't notice anything serious. By the time I updated, the serious issues had already been pulled from the mirrors (eg VLANs). And no, I'm not one of those "IT experts" that never update, I try to update everything (from servers down to clients' access points) every week. YMMV of course, because there is always that one person that will say "but I upgraded and now everything is broken! how did you miss that?"  :o

Updating from 17.1 still wants to go to 17.7 first. Is this fix included in 17.7? If not, then the firewall will crash and will not be able to update. How to work around this so that 17.1 machines can be updated?

Setup:
2 node CARP cluster.
Each member is connected to 2 procurves using a failover LAGG (2 interface) connection. (that's 2xLAGGs each with 2 physical interfaces assigned).

No breakage there. LAGGs come online after reboot and respond correctly when a cable is pulled. What ever is broken, it's specific to the VPN.

That's what I used: The VGA image for a VGA boot. But I suspect that something is wrong with the VGA image, it might be mixed with the serial image, meaning even though the image I downloaded was for VGA output, it was in fact outputting to the serial console instead, that's why it was appearing to be stuck after loading the kernel and trying to boot from it. If memory serves right (been a few years since I last had to use a serial image) that's the behavior seen when booting using a serial image.

As I said, 15.1.8 VGA image works fine. Haven't tested 15.1.9 VGA. 15.1.10 VGA is problematic.

No serial cable attached, VGA all the time. That's what I suspected, that maybe the -serial and -vga images might be reversed in the new version.

15.1.8 booted up fine, installed fine, upgraded fine. I haven't tested 15.1.9 yet, maybe in the next box that gets converted  ;). For now, something is wrong with the 15.1.10 i386 VGA image for sure.

Tried a 15.1.8 VGA image and that boots fine. Will try updating to the latest version through that.

Hi all,

I'm having a hard time getting 15.1.10 i386 VGA installed on a p4. Image verified to be downloaded OK (checksums match).

When inserting the USB stick and booting off it, trying to proceed to the installation gets stuck just after the blue "Booting..." text (where it's supposed to have loaded the kernel and it's trying to boot off it).

Tried with ACPI disabled through the BIOS, tried it with it being disabled from boot options as well.

Any ideas?

TIA

Been testing the past couple of libressl versions and I can't find anything to be broken. What's the actual holdup for shifting over to it? Any programs that depend on openssl and need patches to work?

Sounds perfect  ;D