No TCP for connected VPN clients (just ICMP)

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 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.


  • Flint (GL AX1800, f/w 4.2.1-release4)
  • LAN IP
  • 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
    inet brd 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 brd scope global wgserver
root@GL-AX1800:~# wg show
interface: wgserver
  public key: [redacted]=
  private key: (hidden)
  listening port: 51820
  fwmark: 0x80000

peer: [redacted]=
  allowed ips:
  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 ''
        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 ''
        option persistent_keepalive '25'
        option public_key '[redacted]='
        option private_key '[redacted]='
        option client_ip ''
        option deprecated '0'
        option allowed_ips ', ::/0'
        option mtu '1320'

NOTE: DNS 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.


  • Certa (GL AR750, f/w 3.216)
  • Downstream from Flint (ie: Flint LAN → Certa WAN)
  • WAN IP
  • LAN IP
  • 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
    inet scope global wg0
       valid_lft forever preferred_lft forever
root@GL-AR750:~# ping -c3
PING ( 56 data bytes
64 bytes from seq=0 ttl=64 time=1.960 ms
64 bytes from seq=1 ttl=64 time=1.850 ms
64 bytes from seq=2 ttl=64 time=3.316 ms

--- 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]=
  allowed ips:, ::/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 ''

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

NOTE: Again DNS 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:
Client WAN IP:
WG-Server IP:
WG-Client IP:

So you have nothing in between as it seems.

I have rather complicated setting here:

  • WG-Server runs on
    -WG-Client runs on

  • Brume2 (LAN connected via LAN to the DMZ of the IPfire (

  • FWrouting from to the whole external network ( with source NAT of the IPfire (

  • IPfire ( connected to the ISP router (

  • PORTforwarding (WG) from ISP router to the IPfire (
    -PORTforwarding (WG) from the whole external network ( to the Brume2 in the DMZ ( with destination NAT of the IPfire (

-DNS is set to just to test and be sure


  • 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 (Brume2 in the DMZ) to (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 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.”