Placing an UI EdgeMax Gateway between ISP and IPFire (to use UISP better)

sec-con · 10 November 2023 09:50

I must be stupid stubborn but I can’t let this idea just drop dead. Yet.

Been trying to get this to work via this thread before, but now I try something different and would like your opinion on it being a good or a bad idea. It is just an idea so far.

All my network equipment, except for the IPFire box, is UI EdgeMAX. I like UISP, it is a great application to monitor devices, modern interface, no code, no cli, and easy to manage. It is one of the few web based apps running in docker I manage to keep updated and always install again and again after remaking my network. UISP can handle the networks topology, firmware updates for my other UI devices, downtime, uptime, ping, etc… IPFire can of course do some of this as well, but not specifically for my EdgeMAX devices.

However, it has a requirement: in order to be able to monitor everything and use it to its full advantage it must have an Ubiquiti device somewhere routing. I have my EdgeMax Router 6P in a box collecting dust.

My network :

So what do you think about it?
I guess a passthrough with zero routing would be the least impact but it should still be able to access all devices… B/W and performance is probably not a concern.

/Edited thread title to better reflect desired accomplishment…

sec-con · 10 November 2023 11:18

A slight correction. I must, as it seems, configure the EdgeMAX Router as Gateway, if that is possible.

sec-con · 11 November 2023 11:06

Reading up I see that historically gateways were indeed separate devices before being integrated in routers. Not sure when I will be able to test this, but if I configure the edgerouter to have a fixed ip of, say, 10.1.1.1 and connect it between isp and ipfire, I should only need to tell ipfire to use 10.1.1.1 as gateway and test that… not sure if this will be as simple as that, but I will make a connectivity test.

hvacguy · 11 November 2023 11:58

Where is IPfire?
What is it’s role?

sec-con · 11 November 2023 18:47

In the schematic above it is the mostly red square symbol, almost on top, labelled Firewall+Router.

Do you not see that?

sec-con · 16 November 2023 18:52

So managed to give the EdgeMAX router box a fixed IP of 10.1.1.1 but it insists on not accepting it as such and wants me to give it 10.1.1.1/24 for some reason. To all effects that should probably have the same result. Can actually connect to it directly via lan cable and will sort out the cabling between it and ipfire and fibre later today.

/ Later today/

When placing the configured EdgeMAX between my fibre box and IPFire box internet connection went out.

It would probably be due to having the wrong gateway in IPFire, and the only place related to this I can see relates to setting a gateway in IPFire is in the setup process:

Here:

Those entries in that interface should, AFAIK works with my provider be DHCP, as it is now.

I don’t know wat to put in the the IP Address if I put 10.1.1.1. in the gateway address. Can they be the same?

Mask should be 255.255.255.0. never used any other.

Stuff is currently disconnected.

tphz · 16 November 2023 19:55

This may be the case in some devices
e.g. Mikrotik
obraz

sec-con · 16 November 2023 20:38

Yeah, had those as well and stopped using, way to complex, but I understand why so I guess my original take is not wrong.

What do you think about the setup > gateway…?

sec-con · 19 November 2023 18:04

Would connecting to a device acting as gateway, as I explain above, be considered a static connection?

wiki.ipfire.org - Static .

What if I have no IP but the IP to the Gateway, as mentioned above 10.1.1.1 ? Should I use that in both IP entries?

sec-con · 22 November 2023 19:13

So attempt 1 did not work.

First I checked connectivity to the EdgeMax by just hooking it up to a random port and my Switch (also EdgeMax) could detect it with MAC addresses and IP 10.1.1.1, but I was not able to connect to it via any computer, probably, well obviously, because there was no path through to it. That did not matter a lot, just seeing it has a conn.

Then I hooked it up as intended, taking the cable from the ISP box and putting it in to the WAN/ETH0 port of the EdgeMax and ETH1 from the EdgeMax to the RED port of IPFire.

I logged on IPFire Console via IPMI, ran setup and modified the RED network to be Static with the current address 192.168.1.1 and Gateway to the EdgeMax at 10.1.1.1 and Network mask 255.255.255.0. Reboot. (However, I am not sure about the Network mask, perhaps it should have been 255.0.0.0, which would have been a huge network, but I am just not sure about these things.)
I was not able to establish any Internet connection, but while pinging 10.1.1.1 it gave me three timeouts and one successful lookup to my ISP’s website IP, which I found rather strange.

Next attempt I will put it at 10.10.10.1 with 255.255.255.0.

These trials take a bit of time and I can only do one and document what happen before I try next with any considered changes.

I am trying to diagnose what happened and while not being sure what might have gone wrong aside from the potential Network mask issue I started to look at logs.

The RED log from relevant time span:

Time	Section	 
15:30:33	dhcpcd[4101]	: red0: carrier lost
15:30:33	dhcpcd[4101]	: red0: deleting route to 158.174.120.192/26
15:30:33	dhcpcd[4101]	: red0: deleting default route via 158.174.120.193
15:31:01	dhcpcd[4101]	: red0: carrier acquired
15:31:01	dhcpcd[4101]	: red0: IAID 7a:6a:d1:a1
15:31:01	dhcpcd[4101]	: red0: rebinding lease of 158.174.120.223
15:31:06	dhcpcd[4101]	: red0: DHCP lease expired
15:31:35	dhcpcd[4101]	: red0: soliciting a DHCP lease
15:31:35	dhcpcd[4101]	: dhcpcd_handlelink: unexpected event 0x0101
15:31:35	dhcpcd[4101]	: route socket overflowed (rcvbuflen 106496) - learning interface state
15:31:35	dhcpcd[4101]	: drained 279 messages
15:32:17	dhcpcd[803]	: sending signal ALRM to pid 4100
15:32:17	dhcpcd[803]	: waiting for pid 4100 to exit
15:32:17	dhcpcd[4101]	: received SIGALRM, releasing
15:32:17	dhcpcd[4101]	: red0: removing interface
15:32:27	dhcpcd[803]	: pid 4100 failed to exit
15:32:28	dhcpcd[1383]	: sending signal ALRM to pid 4100
15:32:28	dhcpcd[1383]	: waiting for pid 4100 to exit
15:32:38	dhcpcd[1383]	: pid 4100 failed to exit
15:32:39	dhcpcd[1748]	: sending signal ALRM to pid 4100
15:32:39	dhcpcd[1748]	: waiting for pid 4100 to exit
15:32:45	dhcpcd[4101]	: received SIGALRM, releasing
15:32:45	dhcpcd[4101]	: red0: removing interface
15:32:45	dhcpcd[4101]	: received SIGALRM, releasing
15:32:45	dhcpcd[4101]	: red0: removing interface
15:32:45	dhcpcd[4101]	: dhcpcd exited
15:32:47	dhcpcd[2358]	: dhcpcd-10.0.2 starting
15:32:47	dhcpcd[2362]	: DUID 00:01:00:01:2a:f8:f3:a2:0c:c4:7a:6a:d1:a1
15:32:47	dhcpcd[2362]	: red0: waiting for carrier
15:32:50	dhcpcd[2362]	: red0: carrier acquired
15:32:50	dhcpcd[2362]	: red0: IAID 7a:6a:d1:a1
15:32:51	dhcpcd[2362]	: red0: soliciting a DHCP lease
15:33:47	dhcpcd[2362]	: timed out
15:33:47	dhcpcd[2362]	: main: control_stop: No such file or directory
15:33:47	dhcpcd[2362]	: dhcpcd exited
15:49:01	dhcpcd[6940]	: dhcpcd-10.0.2 starting
15:49:01	dhcpcd[6943]	: DUID 00:01:00:01:2a:f8:f3:a2:0c:c4:7a:6a:d1:a1
15:49:02	dhcpcd[6943]	: red0: IAID 7a:6a:d1:a1
15:49:03	dhcpcd[6943]	: red0: soliciting a DHCP lease
15:49:26	dhcpcd[6943]	: red0: carrier lost
15:49:54	dhcpcd[6943]	: red0: carrier acquired
15:49:54	dhcpcd[6943]	: red0: IAID 7a:6a:d1:a1
15:49:56	dhcpcd[6943]	: red0: soliciting a DHCP lease
15:49:56	dhcpcd[6943]	: red0: offered 158.174.120.223 from 81.170.145.33
15:49:56	dhcpcd[6943]	: red0: probing address 158.174.120.223/26
15:50:02	dhcpcd[6943]	: timed out
15:50:02	dhcpcd[6943]	: main: control_stop: No such file or directory
15:50:02	dhcpcd[6943]	: dhcpcd exited
15:53:20	dhcpcd[4108]	: dhcpcd-10.0.2 starting
15:53:20	dhcpcd[4111]	: DUID 00:01:00:01:2a:f8:f3:a2:0c:c4:7a:6a:d1:a1
15:53:21	dhcpcd[4111]	: red0: waiting for carrier
15:53:23	dhcpcd[4111]	: red0: carrier acquired
15:53:23	dhcpcd[4111]	: red0: IAID 7a:6a:d1:a1
15:53:23	dhcpcd[4111]	: red0: soliciting a DHCP lease
15:53:27	dhcpcd[4111]	: red0: offered 158.174.120.223 from 81.170.145.33
15:53:27	dhcpcd[4111]	: red0: probing address 158.174.120.223/26
15:53:32	dhcpcd[4111]	: red0: leased 158.174.120.223 for 1200 seconds
15:53:32	dhcpcd[4111]	: red0: adding route to 158.174.120.192/26
15:53:32	dhcpcd[4111]	: red0: adding default route via 158.174.120.193

I tried to look through other logs, ALL of them as a matter of fact, but could not really identify any relevant information aside from above.

Potential issues:

Network mask as mentioned above.
Physical connections, the EdgeMAX has a dedicated WAN port. Normally it would be obvious to use that, and the ETH1 to IPFire, but perhaps that is wrong in this case.
EdgeMax do also have an inbuilt, rather rudimentary, firewall, that is active, maybe I should deactivate it.
I have not considered any kind of bridging or pass through.

Anyone has ideas about this little experiment of mine…? Any more information I can give?

//
I almost forgot, I need to check logs on the EdgeMax as well.

sec-con · 23 November 2023 10:52

Another approach might be abandoning IPFire as Router and use it only as Firewall, but that is a different story. Not sure I want to do that.

sec-con · 11 December 2023 08:23

Slowly advancing on this. It is slow because I can not test diff configs as I want, allotted network downtime is very limited …

I also try to gather as much information as possible before testing, so I have everything documented and know exactly what I am testing as much as possible.

Got some feedback suggesting I go with these settings on the EdgeMax Router:

Masquerading to forward the ISP connection

IP address on the device itself

Below based on this: https://help.ui.com/hc/en-us/articles/204952134 and would suggest the settings I need for the IPFire box to get conn.

I am still a bit puzzled over tying eth0 to eth1 but maybe it just works.

sec-con · 20 December 2023 10:14

So this did not really turned out as I expected.

I did not get anything posted above working so I just cancelled all thoughts about Gateway and bridging and forwarding and other überkomplex stuff that may or may not have been relevant and took the simplest possible approach.

What can go wrong, right?

Give the WAN (eth0) DHCP, hook it up to my Switch. Full stop. Nothing else.

My UISP server scanned and found the EdgeMAX Router.
My UISP server was able to “adopt” the EdgeMAX Router.
My UISP server allowed me to assign the EdgeMAX Router the role as “Gateway”.

From there I could configure adoption of the rest of my UI devices, some more not visible here,:

Everything works as I wanted. It was as simple as that.

Now, how this affects anything else is yet to see, but I am happy for now.

Lesson learned, sometimes things can be a lot easier than expected.