Prevent LAN attached devices from using the Conduits Cellular PPP Network

[Chris Friedel]

Hello all,

We are trying to solve a major problem causing expensive cellular overages.

When the conduit has its Ethernet port set as a LAN, and the conduit assigns IPs via DHCP to connected devices over Ethernet, that attached PC gets a default route of the conduit for network traffic.

The Conduit will then forward that traffic over its PPP connection. Since the connection is wired, we’ve noticed most connected PCs will typically have a higher preference for that route over their own wireless networks and such (or out in the field when the conduit is the only network present). We’ve seen conduits rack up gigabytes of cellular data, even though they are on small 10MB M2M plans. Yikes.

We are looking for a way, on the conduit itself without changes to the connecting PCs, to prevent the conduit from allowing a machine connected over the Ethernet LAN, from using the conduits cellular network. However, the conduit itself must be able to continue to use the cellular network as needed.

We’ve tried to enforce this using the “firewall” section on the admin console (IP tables), but so far have been able to lock out a connected PC without also locking out the conduit itself from using its own cellular ppp.

Guidance or advice for this would be appreciated!

Thank you very much,
Chris

[Jeff Hatch]

Chris,

In the Web UI, if you go to Setup->DHCP, there should be a list of server entries (maybe only one). In the server entry you can modify what Gateway you want it to give out. If you set it to something that you want the PCs to use instead of the Conduit, this may solve your problem. Let me know. Otherwise, there are ways to do it with Firewall rules, but that is more complicated as you have already figured out.

Jeff

[Chris Friedel]

Hi Jeff,

Thanks for the reply.

We went through the DHCP setup as per your suggestion, but I don’t believe the control we are looking for is there.

Essentially, the current issue is that while a contractor / installer (or really anyone with physical access to the conduit) is connected to the conduit, then that person will start using the conduit’s cell data for internet traffic (assuming A, that the cell sim provides a public address, and B, that the Conduit is acting as the DHCP server, as it will tell all of its connected clients to use itself as their default gateway).

I believe you are correct that only the firewall rules will correctly enforce this. But I think this would be a worthwhile thing for the community to figure out how to enforce, because as it stands right now I believe this will be a common issue for anyone with a conduit acting as a DHCP server, with a public IP address. Unfortunately, my Linux networking skills are weak and I’ve made little progress with the correct settings over the last months.

Any further guidance you or anyone can provide would really be appreciated.

Thanks!
Chris

[Jeff Hatch]

Chris,

Probably the first thing to consider before making firewall rules is to determine what you want to block, and then the best way to block it. In the AEP Conduit Web UI, you will probably want to use the “advanced settings” and create what are called “Forward Filter Rules”. Those are the base rules that allow or block traffic going through the Conduit, ie. in Ethernet interface and out the Cellular interface.

You can block specific source IPs or a source subnet or IP range. You can also block anything matching certain ports, or different combinations. Give me an example of what you want to do, and I should be able to help you fashion a rule or two that can allow and block what you need to.

Jeff

[Chris Friedel]

Hi Jeff,

Here is a pasteboard of what we’d like to do
http://pasteboard.co/ajW31Efgt.png
(on old IE, you might need to use http://cdn.pbrd.co/images/ajW31Efgt.png)

Forward Filter Rules have been what we’ve been trying to use to accomplish this.

We created a rule:
Source ANY, Destination ANY (CELLULAR interface only), Chain FORWARD, Target DROP

And while this did block forwarding, it also prevented the laptop from accessing anything on the conduit, and it also prevented the conduit from accessing the internet (such as checking into Device HQ, or calling our IoT platform). We ended up having to restore to factory defaults to gain access to the conduit again.

Our assumption was that this filter would only be checked when packets were forwarded from one interface (like ETH0) to the cellular (PPP) interface. But it looks like that is not how IPTABLES works on the conduit 🙂 .

• This reply was modified 7 years, 9 months ago by Chris Friedel.

[Jeff Hatch]

Chris,

I have a couple of things that you can look into. First, on the PC, is there a way for you to configure it to DHCP with addresses only? If you can this should prevent the PC from getting a gateway setting that overrides the gateway pointing to the WiFi interface.

Also, so far I have played around with using the same rule that you describe, but also blocking by specifying a port value. This seems to be working as expected. I will see if I can get any time tomorrow to play with this.

Jeff

[Jeff Hatch]

Chris,

I have been away on vacation for a little while and things got really hectic after I got back. Have you made any progress on this?

Jeff

[Chris Friedel]

Hi Jeff,

Sorry, things got a little hectic here as well 🙂 I hadn’t been back on the board for a couple of weeks. My apologies.

You’re correct that we can fix this on the user’s PC. However, we were looking more for a solution that was enforced on the Conduit’s side so that someone (either maliciously or accidentally) couldn’t bypass the behavior.

We really haven’t made too much progress with this. If there isn’t anything jumping out to anyone here, I guess it is something that for now we will just put on the back burner.

Cheers,
Chris

[Jeff Hatch]

Chris,

Your best bet would be to create a forward rule with a source interface of Ethernet, protocol TCP/UDP, chain FORWARD, and target REJECT. This will cause the AEP to block any traffic going from the Ethernet interface side to anywhere else. This still would allow connectivity to the device on the WEB UI. I’ve tested this a little bit, and it seems to be doing what you want. I tried blocking with a subnet, but that didn’t seem to work, so I just blocked everything from the Ethernet interface and it works.

Jeff

[Author]

Posts