Wireguard not working but open VPN does. BerylAX client to Brume2 server

so, I’ve quickly tried Ning on LAN, and on the main router/modem it says the following ports are open: 80 HTTP, 53 DNS, 443 HTTPS.
On the Brume, the following: 80 HTTP, 22 SFTP/SSH, 53 DNS, 443 HTTPS.

Okay, because we can’t ‘hardline’ fr the Public Internet/Modem/WAN to the GL devices ATM, I’m just going to jump ahead to give you my thought process:

  • WG Server requires an open port of 51820, as we know.
  • We don’t know if port is open/accessible fr the Modem/WAN Side, hence nmap.
  • OpenVPN may use other ports/TCP/whatever; I don’t know, I don’t use it, won’t use it.
  • You could be faced with a case of CG-NAT but that’s speculation & I hope not as
    • You’ll (most likely) have no control over opening ports being behind this ‘ISP’s middleware router before your ISP’s router’.
    • You’d have to contact the ISP to confirm if that’s the case.
    • If so the whole approach to using WG like this would need to be scrapped in favor of something like Tailscale.
      • TS introduces a whole new series of bothersome hurdles to jump over as GL’s support for it is still “in beta” (GL GUI → Applications → Tailscale).

@2992

@admon brings up a good point: nmap fr the GL/LAN-connected devices may cause ‘false positives’ due to how its NAT would just loop back the connection right back to the GL device. As you presumably have mobile data, I’d keep to using Ning to port scanning your Public IP from your Mobile ISP just to rule GL NAT loopback out of the equation.

1 Like

Thanks much for the hint @bring.fringe18!
I did a quick search about my ISP and CG-NAT, and there are people saying my ISP might be using it. So, that might indeed be the case. If that really turns out to be the case (I’ll call them next week), then I’ll have to start learning how to use tailscale - as I really need when I am on the go to connect back home and use my home IP to go out on internet…
Meanwhile, until I’ll get comfortable with Tailscale, I’ll have to rely on OpenVPN…

If CG-NAT is in effect, this thread is dead if the ISP won’t open the port(s) on their end.

Tailscale will require a whole new thread; I’m a few months behind on its status… & I’ve never used it but (well, used to, anyways) know how to hack around GL’s “beta” support to get most of the expected feature set operational.

Until then.

I’ll call them and ask whether they use CG-NAT, and if yes, then whether they can open a port (51820, right?) on my IP/Router/Modem.

Slight correction: on their side, their CG-NAT; think of CG-NAT as yet another goddman router your ISP uses in the middle (‘middleware’) between the 'net proper & your physical ISP modem… that you have no direct control over.

Otherwise yeah, you got it:

root@flint~#: 2023-12-15-152950
interface: wgserver
  public key: [redacted]]=
  private key: (hidden)
  ***listening port: 51820***
  fwmark: 0x80000

peer: [redacted]=
  preshared key: (hidden)
  endpoint: 192.168.8.173:54485
  allowed ips: 10.0.0.3/32
  latest handshake: 1 minute, 40 seconds ago
  transfer: 54.23 MiB received, 16.00 MiB sent
  persistent keepalive: every 25 seconds

alright, I’ve got it now.

1 Like

@bring.fringe18 But why should OVPN work if CG-NAT is active? Something is fishy here.

Damned if I know. Maybe $ISP blocks all non :53/UDP. Maybe they’re all about the “OVPN or GTFO”.

Never assume anything when it comes to these corpo b@stards. To do otherwise is to set yourself up for a bad time. /rant

But we agree that if CG-NAT is active OVPN can’t work, right? Because they could open the port if course, but it would be just one port for all people behind this „real“ IP - so it’s not really something that would happen.

We’re speculating, of course. The only way to check that I can think of is to blast OP’s $WANIP w/ nmap but I’m pretty sure that’ll trip some IDS somewhere in the link so it won’t be me doing it, thanks.

Hell, we don’t even know if OP’s OVPN is UDP or TCP. Maybe $ISP only supports OVPN; it’s not like their DPI can’t be set to know the difference between OVPN/TCP & regular TCP:

https://www.usenix.org/conference/usenixsecurity22/presentation/xue-diwen

it’s default config for OVPN, namely UDP 1194.

Instead of running nmap from Brume, I’ve connected my MacBook directly to the main router/modem and ran the nmap with my public IP without $ in front of it (as with $ it fails to resolve).

sudo nmap -sU -p 51820 -v xx.xx.xx.xx
Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-16 08:41 EET
Initiating Ping Scan at 08:41
Scanning xx.xx.xx.xx [4 ports]
Completed Ping Scan at 08:41, 0.01s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 08:41
Completed Parallel DNS resolution of 1 host. at 08:41, 0.01s elapsed
Initiating UDP Scan at 08:41
Scanning adslxx-xx-xx-xx.ISP.net (xx.xx.xx.xx) [1 port]
Completed UDP Scan at 08:41, 0.43s elapsed (1 total ports)
Nmap scan report for adslxx-xx-xx-xx.ISP.net (xx.xx.xx.xx)
Host is up (0.0047s latency).

PORT STATE SERVICE
51820/udp open|filtered unknown

Read data files from: /usr/local/bin/…/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.57 seconds
Raw packets sent: 6 (288B) | Rcvd: 1 (40B)

Is there an option on the Modem to set it to ‘bridged mode’ & just set it as a modem & not one of these goddamn ‘all in one’ modem/AP/router POS most ISPs dump on unsuspecting customers?

If not, see if you can put the Burme2 on the DMZ if it has that option in the modem’s settings.

(Port scanning fr a different ISP/WAN would be recommended; your ‘modem’ could be looping back the NAT, as previously mentioned.)

… I absolutely hate AiO ‘modems.’

I have the Brume’s IP already in the DMZ of main router/modem. Also, I’ve set Brume as drop-in gateway. (I’ve tried WG with Brume in both cases, normal LAN client and as drop-in gateway. Now it’s in drop-in gateway mode)

Sorry; I should point out that $ is just a variable name convention in (bash) shell scripting. I’m just indicating we don’t know your ISP’s name.

(The GL firmware runs OpenWrt Linux ‘under the hood’ which uses the ash command line/shell which is similar enough to bash that I can hack up scripts for certain use cases. @admon works IT, he’s see this sorta concept before, I’m sure.)

I also, can change s#it on them… I have an ONT Sagemcom F@st 5655v2 AC RF, and I cannot even change its DNS from GUI, let alone having it in bridge mode or anything else more serious than bounding a MAC or hostname to a fixed local LAN IP. No SSH on it, obviously.

Fcuk; I can’t recall if GL is still doing ARP poisoning or if they switched to a new method for that feature. Can you kill it? That’s a variable that doesn’t need to exist ATM.

Here’s my current thought process:

  • You state OVPN via UDP/1194 works as suspected, without issue.
  • You’ve successfully used WG Server/Client when both [Endpoint]s are all within the same LAN.
  • LAN WG endpoints use the standard WG port 51820.
  • Hypothesis: Claim that OVPN port for WG. Spin up a new set of WG Profiles but when setting the WG Client via the .conf, change out the port fr 51820 to 1194 & use your Public Internet/WAN IP (per IP Leak). WG Sever’s Listen Port should also be 1194.

This is just for testing purposes. Kick OVPN aside for the moment & use its ‘known good’ UDP port.

I know that frustration. Excuse me, I ordered a burger, just a burger; not a goddamn Happy Meal!

exactly.

same results, doesn’t work. WG Read from Beryl as following. Shall I do a wg read on Brume as well? (WG Server is set on 1194)

root@GL-MT3000:~# wg show
interface: wgclient
public key: 8BDxxxxxx…xxxxxxxxxEM=
private key: (hidden)
listening port: 34729
fwmark: 0x80000

peer: MIfxxxxxxxx…xxxxxV8=
endpoint: xx.xx.xx.xx:1194
allowed ips: 0.0.0.0/0, ::/0
transfer: 0 B received, 296 B sent
persistent keepalive: every 25 seconds