Revisiting: Accessing a Modem through a Ubiquiti USG

Revisiting: Accessing a Modem through a Ubiquiti USG

It's been nearly a year since I posted this guide on how to access a DrayTek Vigor 130 modem from the LAN side of a Ubiquiti USG. I had originally prefaced that post with a sentence saying how I thought it'd be of interest to few people - I have never been so wrong. That post makes up for over 50% of the visits to my blog and I've been contacted by many people regarding it. Recently, I've been having some problems with my broadband and for various reasons I decided to try using the ISP supplied router (in bridge mode) in the place of my DrayTek modem. Unfortunately, it becomes incredibly limited in configurability once you flip the bridge mode switch, and it meant that I needed a new solution.

The solution I found for the DrayTek was to add a virtual interface that sits on the WAN port of the USG. This is the same thing I did for my previous solution and it results in what is effectively a mini-bubble LAN on the WAN port. Now, this "bubble" LAN allows the Modem and USG to talk to each other directly as their IP's are also in the same subnet.

Fortunately, the router for our actual LAN just happens to be the USG (Woah! What a coincidence!). As it is connected to both the Modem bubble LAN and our actual LAN, it knows how to route traffic between the two. There's only one thing missing, and that is the modem doesn't know how to talk back to the LAN, it knows how to talk to the USG, and the USG knows how to talk to the LAN, but the Modem doesn't know how to bridge the gap - and that's the final piece to the puzzle. The DrayTek allowed me to solve this by giving it a static route saying "Hey! You can find the LAN (x.x.x.x/xx) by going through the router at x.x.x.x" - unfortunately, the BT Hub doesn't let you do this (and I suspect this is the same for quite a few other modems).

The Pseudo Interface

Important stuff:

I used the IP address 192.168.1.100 (and a subnet mask of 255.255.255.0 or /24) for the USG's virtual interface because the BT Hub (the modem I'm using) uses 192.168.1.254 by default and I didn't feel like changing it. You need to find out what the default IP address is for your modem and then pick a IP for the USG which is the same subnet. If the modem's IP (or subnet) conflicts with your LAN then you will need to change it to avoid routing conflicts (which really aren't fun to deal with) - for example, if my LAN also used 192.168.1.x/24 or if thought I might want to VPN into my network from a network that uses 192.168.1.x/24. Whichever subnet you end up using, you need to make sure that both the modem and USG are set to use the same one.

"eth0" is the name for the primary WAN port on the USG, if you're using WAN2 or the USG Pro then it will likely be different. The primary WAN port on the USG Pro is eth2 - in any case, you can run the command "show interfaces" on the USG to see which you are using and then edit the config accordingly (I.E. eth2 instead of eth0 in the commands and config file).

All of the solutions I tried started out with this step, creating the virtual (pseudo) interface on the USG. In my case, I will assign it the IP address 192.168.1.100 and a 255.255.255.0 subnet (represented using CIDR notation, /24). You can configure one by connecting to the USG via SSH and running the following commands:

configure
set interfaces pseudo-ethernet peth0 link eth0
set interfaces pseudo-ethernet peth0 address 192.168.1.100/24
set interfaces pseudo-ethernet peth0 description "Access to modem"
commit
save
exit

Those commands will persist until the USG is re-provisioned (I.E. any config change on the controller or restarts/upgrades). You can configure the "config.gateway.json" file on the controller to make the config permanent - here's Ubiquiti's "how to" for this and here's the JSON version of the above config that you'll want to put into the file (adjusting the IP address if necessary):

{
	"interfaces": {
		"pseudo-ethernet": {
			"peth0": {
				"address": ["192.168.1.100/24"],
				"description": "Access to Modem",
				"link": ["eth0"]
			}
		}
	}
}

The last piece of the puzzle

Now, on the DrayTek we could configure a static route to let it know how to talk back to the LAN. Sadly, the BT Hub won't let us do this when it's in bridge mode, so we need a different solution. Let's take a step back, the problem we face is that the modem doesn't know the route to get to the LAN and we have no way to tell it how to. Bit of a problem, eh? Wait a second... what if we make it so it doesn't need to know anything about the LAN? That'd be a rather novel solution, but how do we do it?

I remembered a reply I read on a forum post ages ago, you know, one of those posts you think "Oh, that looks interesting, I'll give it a closer look later" and then never do... Anyway, it didn't quite make sense to me at the time but after some googling I managed to piece it together. You can tell the USG to masquerade packets so that they appear to come from a network interface on the USG rather than an IP address from the LAN. This negates any need for the modem to know about the LAN at all. As far as it is concerned it's directly communicating to the USG. I actually prefer this solution over the previous one as it consolidates the config to one place - and it's rather more elegant.

These are the commands for the USG that you can run via SSH (ideal for testing as they're applied immediately unlike the config.gateway.json which has to be provisioned). You'll want to adjust 192.168.1.254 for the IP address of your modem.

configure
set service nat rule 5000 type masquerade
set service nat rule 5000 destination address 192.168.1.254
set service nat rule 5000 outbound-interface peth0
commit
save
exit

The full config.gateway.json (with both parts combined for convenience). Please adjust the IP addresses as necessary.

{
    "interfaces": {
        "pseudo-ethernet": {
            "peth0": {
                "address": ["192.168.1.100/24"],
                "description": "Access to Modem",
                "link": ["eth0"]
            }
        }
    },
    "service": {
        "nat": {
            "rule": {
                "5000": {
                    "destination": {
                        "address": ["192.168.1.254"]
                    },
                    "outbound-interface": ["peth0"],
                    "type": "masquerade"
                }
            }
        }
    }
}

Final Thoughts

For my circumstances this solution works perfectly, I can access the modem's web interface and if it allowed SSH or anything else, they should also work. I haven't tested this solution in any other environment, though I see no reason why it shouldn't work. Please let me know how you get on and if there's any problems you encounter or improvements you think I could make to this post.

Small side note: I believe the above config may well also work on Ubiquiti's Edgerouter line. If anyone tries this, I'd love to hear how you get on.

Short Link: on-te.ch/mtu

Owen Nelson

Owen Nelson

https://owennelson.co.uk

IT Systems Administrator from Northamptonshire, UK. Always on the lookout for ways to make things faster and more secure - and I enjoy getting through a fair bit of Tea along the way.

View Comments