UDMP as Client

[kashalls]

Has anyone confirmed that you can use the UDMP as a wireguard client? Not by running all routes through the VPN tunnel. More or less running a wireguard tunnel from the UDMP to a pfSense box running wireguard and only routing the internal network of the pfsense box and making it accessible on the UDMP. I got a small link to work, however the UDMP refused to route any traffic from wireguard to the LAN.

[peacey]

Hi @Kashalls,

It works fine for me as a client. Can you show your server and client wireguard configs without the keys? And what exactly doesn't work? Pinging from the server-side or from the client-side?

[kashalls]

On my pfSense side, this is acting as the server:

# Description: Home VPN
[Interface]
PrivateKey = 
ListenPort = 51821

# Peer: UDMP
[Peer]
PublicKey = 
AllowedIPs = 10.10.0.0/24,169.254.1.2/31
PersistentKeepalive = 560

Here on my UDMP's side:

[Interface]
Address = 169.254.1.3/31
PrivateKey = 

[Peer]
PublicKey = 
PersistentKeepalive = 560
Endpoint = some public ip:51821
AllowedIPs = 10.10.0.0/24,169.254.1.2/31

WG Show on my UDMP shows:

interface: wg1
  public key: 
  private key: (hidden)
  listening port: 37643

peer: 
  endpoint: some_public_ip:51821
  allowed ips: 10.10.0.0/24, 169.254.1.2/31
  latest handshake: 39 seconds ago
  transfer: 9.09 MiB received, 9.15 MiB sent
  persistent keepalive: every 9 minutes, 20 seconds

(51821 is intentional)

tcpdump -i wg1 shows that .3is replying to .2 but when implementing routes such as 10.10.0.0/24 -> 169.254.1.3, nothing is sent.

[kashalls]

I can see the routes under ip r s

10.10.0.0/24 dev wg1 scope link
169.254.1.2/31 dev wg1 proto kernel scope link src 169.254.1.3

[kashalls]

tcpdump -i wg1 also says that the interface sees the icmp replys but the ping client doesnt get anything back

# tcpdump -i wg1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg1, link-type RAW (Raw IP), capture size 262144 bytes
19:06:29.550717 IP 169.254.1.3.50937 > 233.89.188.1.10001: UDP, length 4
19:06:29.550858 IP 169.254.1.3.50937 > 255.255.255.255.10001: UDP, length 4
19:06:29.551214 IP 169.254.1.3.10001 > 233.89.188.1.10001: UDP, length 4
19:06:29.551315 IP 169.254.1.3.10001 > 255.255.255.255.10001: UDP, length 4
19:06:29.619088 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 23055, seq 25422, length 9
19:06:29.619113 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 23055, seq 25422, length 9
19:06:30.163147 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 23055, seq 25423, length 9
19:06:30.163187 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 23055, seq 25423, length 9
19:06:30.691171 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 23055, seq 25424, length 9
19:06:30.691201 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 23055, seq 25424, length 9
19:06:31.217169 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 23055, seq 25425, length 9
19:06:31.217203 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 23055, seq 25425, length 9
19:06:31.729100 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 23055, seq 25426, length 9
19:06:31.729142 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 23055, seq 25426, length 9
19:06:32.271403 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 23055, seq 25427, length 9

[peacey]

Thanks @Kashalls. I used your exact same config and it's working for me, except I think you were missing a Address = 169.254.1.2/31 on the server config (probably a typo since I can see from your tcpdump the IP of the server).

If tcpdump on the UDMP is showing the packets are travelling back on the wireguard interface, then your pfsense box should be getting them unless there is a firewall blocking those packets on the pfsense network. Can you do a tcpdump on the pfsense to see if the ping packets are being received on the wireguard interface?

[kashalls]

Thanks @Kashalls. I used your exact same config and it's working for me, except I think you were missing a Address = 169.254.1.2/31 on the server config (probably a typo since I can see from your tcpdump the IP of the server).

If tcpdump on the UDMP is showing the packets are travelling back on the wireguard interface, then your pfsense box should be getting them unless there is a firewall blocking those packets on the pfsense network. Can you do a tcpdump on the pfsense to see if the ping packets are being received on the wireguard interface?

The server config was autogenerated from their addon/plugin thing. I was getting pings through and I was getting the response on the interface. I wonder if I am missing some portforwarding rule or firewall rule that is not allowing traffic to route?

[peacey]

Did you do a tcpdump on the pfsense wireguard interface to check if you are receiving incoming pings?

[kashalls]

pfSense Packet Capture:

15:00:56.309277 IP 169.254.1.3 > 169.254.1.2: ICMP echo request, id 52770, seq 9, length 64
15:00:56.400982 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 35415, seq 6825, length 9
15:00:56.440589 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 35415, seq 6825, length 9
15:00:56.913752 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 35415, seq 6826, length 9
15:00:56.954015 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 35415, seq 6826, length 9
15:00:57.312454 IP 169.254.1.3 > 169.254.1.2: ICMP echo request, id 52770, seq 10, length 64
15:00:57.454986 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 35415, seq 6827, length 9
15:00:57.494514 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 35415, seq 6827, length 9
15:00:57.996427 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 35415, seq 6828, length 9
15:00:58.041512 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 35415, seq 6828, length 9
15:00:58.312470 IP 169.254.1.3 > 169.254.1.2: ICMP echo request, id 52770, seq 11, length 64
15:00:58.513856 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 35415, seq 6829, length 9
15:00:58.553025 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 35415, seq 6829, length 9
15:00:59.055013 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 35415, seq 6830, length 9
15:00:59.095355 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 35415, seq 6830, length 9
15:00:59.309118 IP 169.254.1.3 > 169.254.1.2: ICMP echo request, id 52770, seq 12, length 64
15:00:59.583928 IP 169.254.1.2 > 169.254.1.3: ICMP echo request, id 35415, seq 6831, length 9
15:00:59.622894 IP 169.254.1.3 > 169.254.1.2: ICMP echo reply, id 35415, seq 6831, length 9

The higher sequence is the gateway keepalive for pfsense. The lower sequence is from the UDMP pinging 169.254.1.2 from 169.254.1.3

# ping 169.254.1.2 -I 169.254.1.3
PING 169.254.1.2 (169.254.1.2) from 169.254.1.3: 56 data bytes
^C
--- 169.254.1.2 ping statistics ---
105 packets transmitted, 0 packets received, 100% packet loss
#

[kashalls]

Might I add, I can successfully ping the UDMP Client from the pfSense box with default settings:

PING 169.254.1.3 (169.254.1.3): 56 data bytes
64 bytes from 169.254.1.3: icmp_seq=0 ttl=64 time=38.962 ms
64 bytes from 169.254.1.3: icmp_seq=1 ttl=64 time=39.500 ms
64 bytes from 169.254.1.3: icmp_seq=2 ttl=64 time=39.341 ms

--- 169.254.1.3 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 38.962/39.268/39.500/0.226 ms

However, when the UDMP pings, it gets the reply on wg1 interface, but it doesnt reach the ping client?

[peacey]

I would check the firewall on the pfsense. Also, did you try to run the client from your computer instead of the UDMP, so you can see whether this problem is with the UDMP or the server?

[kashalls]

I would check the firewall on the pfsense. Also, did you try to run the client from your computer instead of the UDMP, so you can see whether this problem is with the UDMP or the server?

I've used wireguard on my PC plenty of times and it works. What firewall settings do you have for your UDMP as a Client? I have everything wide open for the firewall on the pfsense. I'm almost 100% something is not getting through the firewall.

[peacey]

Okay, so you're saying when you ping from UDMP -> pfsense, the reply packet is arriving on wg1 (on the UDMP) when checking with tcpdump, but then the packet is not reaching the ping client (on the UDMP). In that case, it indeed does seem like a firewall issue on the UDMP side since the NIC is seeing the reply packet.

Just to confirm, are you pinging from the UDMP in SSH, or from a client connected to the UDMP? And is your WG endpoint IPv4 or IPv6?

FYI, I just tried this and I was able to ping fine from the UDMP (in SSH) -> WG server. I don't have any special firewall rules.

Perhaps you can try to add an explicit ACCEPT rule for wg1 packets for testing and see if it helps? Try to run this in SSH on the UDMP, then try the ping:

iptables -I INPUT 1 -i wg1 -j ACCEPT
iptables -I FORWARD 1 -i wg1 -j ACCEPT
iptables -I OUTPUT 1 -o wg1 -j ACCEPT

(Technically you should only need the INPUT one, but just opening it all up for testing).

[kashalls]

Just to confirm, are you pinging from the UDMP in SSH, or from a client connected to the UDMP? And is your WG endpoint IPv4 or IPv6?

I am ssh'd into the UDMP, using the UDMP to ping 169.254.1.2

[kashalls]

Okay, so you're saying when you ping from UDMP -> pfsense, the reply packet is arriving on wg1 (on the UDMP) when checking with tcpdump, but then the packet is not reaching the ping client (on the UDMP). In that case, it indeed does seem like a firewall issue on the UDMP side since the NIC is seeing the reply packet.

Just to confirm, are you pinging from the UDMP in SSH, or from a client connected to the UDMP? And is your WG endpoint IPv4 or IPv6?

FYI, I just tried this and I was able to ping fine from the UDMP (in SSH) -> WG server. I don't have any special firewall rules.

Perhaps you can try to add an explicit ACCEPT rule for wg1 packets for testing and see if it helps? Try to run this in SSH on the UDMP, then try the ping:

iptables -I INPUT 1 -i wg1 -j ACCEPT
iptables -I FORWARD 1 -i wg1 -j ACCEPT
iptables -I OUTPUT 1 -o wg1 -j ACCEPT

(Technically you should only need the INPUT one, but just opening it all up for testing).

Alright, I did exactly as stated and made it wide open. I still didnt get any response on the UDMP.

Is there a chance @peacey we could get into a Discord call later one of these days and take a look this as a whole?

[kashalls]

Looks like the issue was not with my UDMP, but my pfsense box. Apparently you cannot use link-local addresses (169.254.x.x) at all and they actively discourage using them for next-hop routing. Who knew?