Messages

So does anyone have any idea on how to make this dinosaur work now?

Or is this just another piece of e-waste that's eventually going to end up in a third world country for supposed "recycling"?

Does it have a proprietary protocol that allows it to work in Linux or *GASP* Windows?

Well it seems all this work has been for nothing. AT&T has discontinued PPP support for its "Broadband" APN, so now unless someone has a better idea, I've got another paperweight.

Where the heck were you two weeks ago? Well, if they ever update their system, I'll give it a shot. Thank you.

SOLVED:

You'd think they would occasionally force the users to re-login after a certain amount of time, but NO! Once the MAC address is in their approved DB (by logging in), it never needs to be re-approved.

So the solution? Use my phone with a randomized MAC to login, jotting down the MAC I used to login. Then cloning the MAC into the wifi adapter. It's just that simple. Stupid and simple.

Your mileage may vary.

I certainly didn't expect this to be easy. And I do possess the skills and knowledge you mentioned. I just need some help integrating that into OPNsense.

So no one is able, or willing to help me with this?

That is EXACTLY correct. The only part I'm having trouble with is automating the captive portal login.

I think y'alls are missing the point. I'm not looking to solve the VPN issue. I'm looking to automate logging into a captive portal.

Plus some of her devices are embedded (TV, etc) and can't use WireGuard or any VPN.

So back to my original question: Is it possible to log into a captive portal in OPNsense?

The purpose is to have the firewall use WireGuard to connect to home, transparently. And their IT department is clueless about the captive portal. I'm pretty sure they're playing dumb just because they don't want to have devices like this on their network.

Greetings folks!

So here's the situation:
My daughter is at school and they provide free wifi access for the entire school population, controlled through captive portal logins, using their school ID and password. For devices like phones, tablets, and most PCs, joining the wifi access point is pretty darned simple.

I'd like to give my daughter her own OPNsense box, using the school's wifi as the WAN. Testing at home was pretty straight forward, as the USB wifi card connected to my home wifi, using WPA2.

I don't have a captive portal at home, but could easily set one up for testing.

I'm not sure how to go about automating the wifi connection to a captive portal. Can this be done through a plug-in, or a scripting language? Heck, I'd be happy to write a plug-in to do this, with the proper guidance from experienced BSD folks holding my hand a little.

Anyone got any ideas?

I would like to personally thank everyone who made my problem their priority. I'm really happy everything works now. If you need me for any kind of beta testing or hardware information, do not hesitate to reach out.

OPNSense and their support is the best!

At this point, we're getting into personal preference, so let's do the simple thing and leave well enough alone. If it's always been this way, then leave it this way.

But there still is a bug in the editing of the Interfaces once a ppp assignment has been made. I'd be happy to make a cinematic masterpiece and post it, if you'd like, showing you what I mean.

Now that the effects of excessive alcohol abuse have worn off and the caffeine has kicked in, I can understand a lot more about how the Service Provider stuff is merely a form filler, for convenience. With that being said, how it's presented in the UI is pretty lousy. There's no indication whatsoever that tells the user that. The entire section should be hidden UNLESS the user hits a button that says something like "fill in the boring technical stuff with stuff I already know" or something like that. That way the user won't expect it to be saved, like I did in my drunken stupor.

That also means that the Point-to-Point config stuff should NOT appear in the Interfaces configuration screen at all. Maybe something that shows the data already configured in the Point-to-Point screen, but there's no need to have editing duplicated. It makes configuration all the more confusing.

Now with all that out of the way, the Interface configuration screen with a Point-to-Point assignment still doesn't work.

If remote access is needed to show you this, I'd be happy to set it up.

Also, please note that my ranting and negative energy is really just nitpicking at this point since I was able to get it working, so I'm still really happy.

Do you think there's any chance in H-E-double hockey sticks that I could get a tagline for testing the card after Franco pushes the changes to FreeBSD? I'd love to be able to tell people I contributed to FreeBSD in a meaningful way.

OK, so let's get this party started! I'm a little inebriated, so forgive my ramblings.

First of all, AT&T came up with the brilliant idea of allocating an IP address to the card in the 10.x.x.x range. That caused routing problems, as you can imagine. More on this later.

The biggest issue I found is in the Point to Point configuration screens.

• Click on "Interfaces->Point-to-Point->Devices->+"
• The link type is set to PPP
• The link interface is set to /dev/cuau0.1
• Description is left blank (I tried filling this in, but it didn't matter)
• Here's the meat of the problem. Service Provider information is set as Country: USA, Provider: AT&T, Plan: Laptop Connect.
• Everything else is left as default.
• Hit Save

All great, right? NO! If you hit edit on the device screen, guess what? Service Provider information is lost. Gone. Not remembered. Poof!

But, for s**ts and giggles, skip editing the device after saving. Y'alls gotta fix that...

• Click on "Interfaces->[WAN]"
• Make sure Block Private Networks is UNCHECKED
• Make sure Block BOGON Networks is UNCHECKED
• Set IPv6 Configuration Type to None. (Not sure if this is really necessary, but it works for me)
• Hit Save and Apply (if necessary)
• Click on "Interfaces->Assignments"
• Change the [WAN] interface to ppp0 (or whatever you created in the previous list)
• Hit Save and Apply (if necessary)

Voila! Aircard 340U now works as expected!

There is a slight delay, but I'm guessing that's due to the Aircard itself or AT&T's service, but it does indeed work! Now here's the bigger issue, with a 10.x.x.x address, things like WireGuard won't work. I guess AT&T put their own NAT in front of their cellular network. T-Mobile does the same stupid thing, but paying for a static IP changes your APN and then you get a real IP address. I can only imagine AT&T does that as well.

By following the instructions in the manual, the setup for the Aircard fails BECAUSE the provider information is lost in the ppp setup, and if you assign the Aircard to the WAN interface before setting up the WAN interface, it's impossible to enable the interface because the save function stops working due to the Provider information being lost, as well as the /dev/cuau0.1 interface info.

So it seems the Aircard 340U (for AT&T) does work with your kernel patch, but the php code needs a little work.

Thanks a lot. All your help saved me THOUSANDS of dollars. And now, more drink, please...

I GOT IT TO WORK!

A lot more details to follow in the next post.