So, I SEEM to have my WireGuard setup... sort of correct. In that, I appear to be able to connect to it from my Mac (tethered to my iPhone), and I can see via the `wg` command that I'm getting regular handshakes. I can ping to devices on our internal LAN, but I cannot resolve their hostnames (e.g. intranet.example.com)... UNLESS I disable firewalld via a # systemctl stop firewalld. Then, things SEEM to work fine. This is suboptimal from a security perspective, obviously.
That said, I just ran a tcpdump on my wg0 interface on the server, and they very much DO NOT appear to be working fine, since my Mac appears to be trying to route... uhm, everything over WireGuard, despite having very clear rules in the client config. I should only be routing traffic that corresponds to our internal LAN IPs over WireGuard, and everything else should be left alone. Yet, I'm seeing everything from YouTube to Zoom requests being forwarded to our internal DNS servers.
Sanitized, here are my configs:
Server: (located on the DMZ subnet at 172.20.20.12, NATed to from its public IP, 1.2.3.4)
Code: Select all
[Interface]
Address = 192.168.21.1/24
ListenPort = 51820
PrivateKey = server_private_key
[Peer]
PublicKey = peer_1_public_key
AllowedIPs = 192.168.21.2/32
[Peer]
PublicKey = peer_2_public_key
AllowedIPs = 192.168.21.3/32
[Peer]
PublicKey = peer_3_public_key
AllowedIPs = 192.168.21.4/32
Code: Select all
[Interface]
Address = 192.168.21.3/24
PrivateKey = peer_2_private_key
DNS = 192.168.20.10, 192.168.20.11
[Peer]
PublicKey = server_public_key
# I do not know why my Mac is sending all traffic given the line below in my config.
AllowedIPs = 192.168.20.0/24, 192.168.21.0/24, 218.219.220.37/32
Endpoint = wireguard.example.com:51820
# This is recommended by WireGuard docs for people behind NAT, so I figured I'd enable it
PersistentKeepalive = 25
Code: Select all
# firewall-cmd --list-all-zones # (but with irrelevant zones omitted)
dmz (active)
target: default
icmp-block-inversion: no
interfaces: ens160
sources:
services: https ssh wireguard
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
work (active)
target: default
icmp-block-inversion: no
interfaces:
sources: 192.168.21.0/24
services: ssh wireguard
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Code: Select all
Feb 5 12:00:00 wgu kernel: FINAL_REJECT: IN=ens160 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:b7:c0:d6:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=311 TOS=0x00 PREC=0xC0 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=291
Feb 5 12:00:09 wgu kernel: FINAL_REJECT: IN=ens160 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:b7:c0:d6:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=311 TOS=0x00 PREC=0xC0 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=291
Feb 5 12:00:18 wgu kernel: FINAL_REJECT: IN=ens160 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:b7:c0:d6:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=311 TOS=0x00 PREC=0xC0 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=291
1. Regardless of whether or not firewalld is running, I am able to connect to the WireGuard peer acting as the site server.
2. Regardless of whether or not firewalld is running, I am able to ping the server at 192.168.21.1 from my Mac, and I am able to ping my Mac at 192.168.21.3 from the server. I am also able to ping hosts on the company's internal network, at 192.168.20.0/24. I can ping the DNS servers, and I can ping other servers running HTTPS servers - but that is ALL I can do.
3. With the firewalld service stopped, I am able to reach HTTPS services running on our internal network by hostname. This is why I am convinced that my primary issue lies with my firewalld configuration, specifically something that takes place when that WireGuard packet gets to the server, and must go on to the real network.
As far as why my Mac is sending all traffic over the VPN? I couldn't tell you. Absolutely baffled at that. Don't expressly care, it's out of scope of this question, I'll figure that out once I've got the server config stable and good to go.
As far as why I cannot get to other internal services, I feel like there's some kind of fancy iptables forwarding rule that I'm just not sure how to translate into firewalld-speak.