No TCP for connected VPN clients (just ICMP)

wg show:
interface and peer are running.
Peer allowed IPs 10.0.0.3/32

netstat -natp:
several listen (10.1.1.2:53, 10.0.0.2:53)
established connection from this laptop to 10.1.1.2:22

traceroute:
works from the IP of the DMZ in the ipfire to the ISP router to the internet

route -ne:
destination gateway genmask flags
0.0.0.0 10.1.1.1 (DMZ) 0.0.0.0 UG
10.1.1.0 (?) 0.0.0.0 255.255.255.0 U

logread:
don’t really know, what should I look for

  • curl http://ipecho.net/plain && echo:
    gives me some IP address

By the way, I can not ping the smartphone client connected to the wireguard via ssh in the Brume2

That’d be your public facing IP. It should be the same as seen @ ipleak.net .

The device may reject all incoming packets by default. I’d try pinging another computer/laptop on your LAN instead. You should be able to disable any firewall on it easily… as one less thing to get in the way of troubleshooting

It’s a good way to check everything logged but yeah, it can be a bit verbose. You can filter msgs. Eg: I use the GL GUI’s DNS over HTTPS (DOH) feature. It is provided by dnscrypt-proxy2. So logread -e "dnscrypt-proxy" gives me the output I’m looking for.

Can you post your wg show output, in full? Here’s what my VPN Client on a Slate AX shows connected to Surfshark:

root@GL-AXT1800:~# wg show
interface: wgclient
  public key: [redacted]=
  private key: (hidden)
  listening port: 32

peer: [redacted]=
  endpoint: 37.19.211.7:51820
  allowed ips: 0.0.0.0/0
  latest handshake: 1 minute, 49 seconds ago
  transfer: 1.69 GiB received, 503.36 MiB sent
  persistent keepalive: every 25 seconds

(I would point out that, in WG, it is a misnomer to call it a ‘client/server’ architecture. It really is all just peer-to-peer but I agree w/ GL that it’s easier for people to understand client/server as if it was similar to OpenVPN.)

yes, it is.

I can ping the firewall interface in the internal network, which serves as DNS

I can not copy between the VMs I use now using the terminal. I type just the things that differ in relevant way.
wg show:
interace: wgserver
fwmark: 0x80000

peer:
endpoint: IP of the client
allowed IPS: 10.0.0.3/32
latests handshake 1 hour ago (I tested it in that time).

So maybe the problem is “aloowed IPs”. The IP of the client is 10.0.0.3, but it should connect to another subnets.

#Edit: but if I look to the settings of the client, So I see allowed IPs 0.0.0.0/0. So that’s strange. 10.0.0.3/32 is set as the IP of the client. Allowed IPs is set to 0.0.0.0/0. But wg show shows 10.0.0.3/32 as allowed IPs

But if I connect with the smartphone now, I can not see “connected client” in the VPN dashboard. I just see “1 connected client (0 online)”

No, it’s not. That’d be the default setting to route on the device everything through WG.

I’d really be tempted to just strip down/delete the existing WG Server/Client setup & follow along from GL’s GUI based defaults. We know it works.

I can not copy between the VMs I use now using the terminal.

Off topic but if you use Windows, MobaXterm Home Edition is excellent for that ability (< ctrl > + < shift > + < c/v > ). It has integrated SCP/SFTP support, too. It’s freeware.

I mean that the client settings show 0.0.0.0/0 and wg show 10.0.0.3/32 as allowed IPs. Thats strange for me.

nope, I use QubesOS with xterm

what are the defaults for the server? For I can not just delete it or go to defaults.

Crap; I point out I’m using currently using ‘WG Client’ on my Slate AX. I intend to setup a WG ‘Client/Server’ later today on a Flint & Certa… or I’d just post those default confs for you now.

Nice; I’ve never used it so I don’t know the limitations.

IDK as I’d just use whatever GL sets up… but perhaps it would be a good time to make a backup of your GL device before proceeding. See below.

The wg confs are @ /etc/config/wireguard & /etc/config/wireguard_server assuming a v. 4.2.1-r4 f/w. That HOW-TO describes getting it all in ‘Note’ section.

I have nothing really important on the Brume2. Just wanted to install wireguard on it, nothing else.
Yes, as it seems you use it as a client with some other WGserver. I want just to use it as a server within the network.

Why don’t we put a pin in all this for today if not the next few hours? I need to grab some lunch… & caffeine… then I’ll get to setting up a Flint & Certa as I described.

At least you’d have some ‘known good’ conf files to template from. Sound good?

the problem is, that I want to use (or use) Brume2 in the DMZ of my ipfire. So I think, I will stole a lot of time from you, but maybe still have problems within the network. And I have no idea what is “Flint & Certa” :smiley:

ah, ok… we can try it, but as I said, the complications could come within my network in ipfire

< ahem > Excuse me; you’re interrupting my lunch. (heh!)

True but you’d be able to edit the confs to suit whatever are your subnetting specifics. I assume you’re familiar w/ the Nano editor? It’s easier to use than VI/VIM.

opkg update && opkg install nano

yes, I hate VIM :smiley:
We’ll see, if I understand what these configs are about

I will fite you. VIM is awesome… if you’re doing extreme amounts of conf editing/sysadmin/programming work & spend hours/days/week/months setting it up properly. Nano is my goto for the ‘quick & dirty’.

Now excuse me; you’re interrupting my coffee/smoke break. :wink:

I go for a walk :smiley:
nano is installed

Well there certainly was a hurdle to overcome: after enabling the VPN WG Server GL GUI’s defaults for generating WG Client confs automatically set the endpoint to the public IP. I wanted the WG Client device to connect to the WG Server directly within the LAN, not over the WAN/Internet, so of course I changed that to the WG Server’s IP 192.168.10.1 from the perspective of the Client device.

My Client device, the Certa, is known to preform with VPN providers using a MTU of 1320. YMMV.


Server

  • Flint (GL AX1800, f/w 4.2.1-release4)
  • LAN IP 192.168.10.1
  • Server options enabled: GL GUI → VPN → VPN Dashboard → VPN Server → WireGuard → [ gear icon ] → WireGuard Server Options → Allow Remote Access LAN on, MTU 1320
root@GL-AX1800:~# ip a
[...]
19: wgserver: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1
    link/none
    inet 10.0.0.1/24 brd 10.0.0.255 scope global wgserver
       valid_lft forever preferred_lft forever
    inet6 fd00:db8:0:abc::1/64 scope global
       valid_lft forever preferred_lft forever
root@GL-AX1800:~# ip a | grep wgserver
19: wgserver: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1
    inet 10.0.0.1/24 brd 10.0.0.255 scope global wgserver
root@GL-AX1800:~# wg show
interface: wgserver
  public key: [redacted]=
  private key: (hidden)
  listening port: 51820
  fwmark: 0x80000

peer: [redacted]=
  endpoint: 192.168.10.235:42986
  allowed ips: 10.0.0.2/32
  latest handshake: 43 seconds ago
  transfer: 531.82 KiB received, 7.21 MiB sent
  persistent keepalive: every 25 seconds
root@GL-AX1800:~# cat /etc/config/wireguard_server

config servers 'main_server'
        option address_v4 '10.0.0.1/24'
        option address_v6 '[redacted]1/64'
        option port '51820'
        option fwmark '0x80000'
        option ipv6_enable '0'
        option private_key '[redacted]='
        option public_key '[redacted]='
        option masq '0'
        option mtu '1320'
        option access 'ACCEPT'

config peers 'peer_145'
        option name 'Certa-00'
        option peer_id '145'
        option presharedkey_enable '0'
        option dns '64.6.64.6'
        option persistent_keepalive '25'
        option public_key '[redacted]='
        option private_key '[redacted]='
        option client_ip '10.0.0.2/24'
        option deprecated '0'
        option allowed_ips '0.0.0.0/0, ::/0'
        option mtu '1320'

NOTE: DNS 64.6.64.6 was automatically assigned by the GL GUI setup. It is a Verisign Public DNS that supposedly ‘respects your privacy.’ You may want to change that.

Client

  • Certa (GL AR750, f/w 3.216)
  • Downstream from Flint (ie: Flint LAN → Certa WAN)
  • WAN IP 192.168.10.235
  • LAN IP 192.168.8.1
  • Internet Kill Switch enabled
  • VPN Policy enabled; based on MAC Address only allowed to use VPN
root@GL-AR750:~# ip a
33: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1320 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.2/24 scope global wg0
       valid_lft forever preferred_lft forever
root@GL-AR750:~# ping -c3 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=1.960 ms
64 bytes from 10.0.0.1: seq=1 ttl=64 time=1.850 ms
64 bytes from 10.0.0.1: seq=2 ttl=64 time=3.316 ms

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.850/2.375/3.316 ms

root@GL-AR750:~# wg show
interface: wg0
  public key: [redacted]=
  private key: (hidden)
  listening port: 42986

peer: [redacted]=
  endpoint: 192.168.10.1:51820
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 1 minute, 41 seconds ago
  transfer: 3.44 MiB received, 1.32 MiB sent
  persistent keepalive: every 25 seconds
root@GL-AR750:~# cat /etc/config/wireguard

config proxy
        option access 'DROP'
        option main_server 'Flint-01'
        option enable '1'
        option host '192.168.10.1'

config peers 'wg_peer_762'
        option name 'Flint-01'
        option address '10.0.0.2/24'
        option private_key '[redacted]='
        option dns '64.6.64.6'
        option public_key '[redacted]='
        option allowed_ips '0.0.0.0/0,::/0'
        option persistent_keepalive '25'
        option mtu '1320'
        option end_point '192.168.10.1:51820'
        option listen_port '42986'

NOTE: Again DNS 64.6.64.6 was automatically assigned by the GL GUI setup. It is a Verisign Public DNS that supposedly ‘respects your privacy.’ You may want to change that.

HTTP Traffic


(Works just fine w/ HTTPS, too)

1 Like

woooow :smiley: thanks!
I will try to understand it a bit later and try to translate it into my network.

#Edit: as I understand, you connect your Client (GL-AR750) via the WAN port to the Servers LAN port (GL-AX1800)

Server LAN IP: 192.168.10.1
Client WAN IP: 192.168.10.235
WG-Server IP: 10.0.0.1
WG-Client IP: 10.0.0.2

So you have nothing in between as it seems.

I have rather complicated setting here:

  • WG-Server runs on 10.0.0.2/32
    -WG-Client runs on 10.0.0.3

  • Brume2 (LAN 10.1.1.2) connected via LAN to the DMZ of the IPfire (10.1.1.1)

  • FWrouting from 10.1.1.2 to the whole external network (192.168.178.0/32) with source NAT of the IPfire (192.168.178.2)

  • IPfire (192.168.178.2) connected to the ISP router (192.168.178.1)

  • PORTforwarding (WG) from ISP router to the IPfire (192.168.178.2)
    -PORTforwarding (WG) from the whole external network (192.168.178.0./32) to the Brume2 in the DMZ (10.1.1.2) with destination NAT of the IPfire (192.168.178.2)

-DNS is set to 1.1.1.1 just to test and be sure

Result:

  • I see the Client in the VPN dashboard with 1 Client (1 Online), but I get no connection to the internet. I tried different MTU (1320, 1380, 1420).
    - logs of IPfire show DROP_CTINVALID from 10.1.1.2 (Brume2 in the DMZ) to 10.0.0.3 (Smartphone Client connected via WG) with sourcePORT 53 and ICMP protocol.

As it seems some DNS problem?

1 Like

We’re dealing in IP is this case so it certainly shouldn’t be DNS related.

Correct. It’s as if I’m setting up my entire LAN to be WG encrypted, communicating to the Flint as the LAN’s WG Server for outgoing Internet access. The Internet still sees my public IP as assigned by my ISP. By default the GL GUI uses the WG Server’s public IP for that endpoint… which makes sense as most people want to connect to a WG Server regardless where they are (eg: coffee shop Wi-Fi).

Correct again; this is as simple as I can conceive of a setup operating.

Mine runs as 10.0.0.1/24 per its conf’s option address

In your case I’d suggest trying another computer to be set as DMZ’d in IPFire; see if you can establish connectivity that way then replicating my setup as if it is completely physically disconnected from your IPFire server before integrating it into the DMZ.

You’re looking to remove as many possible variables before introducing the DMZ question. I suspect I’m nearing the end of any advice I can give 'ya, though. I don’t have the capability to run a IPFire install/machine at my location… I don’t have a lab these days. :frowning:

ok, I got it so far. Thanks a lot! I will try to implement something different into DMZ and see if it works with that. Just wondering about, because my configuration seem to be ok and as I understood yours, it’s similar (just without the extras). But sure, these extras could be (and possibly are… the pain in the a…).

1 Like

My pleasure.

Yeah, I think it’d be very helpful to get something/anything else working in a simplified fashion into the DMZ first just so you know.

“Better to have it & not need it than need it & not have it.”